So you have decided to start a free software consultancy(ariadne.space)
ariadne.space
So you have decided to start a free software consultancy
https://ariadne.space/2022/08/11/so-youve-decided-to-start-a-free-software-consultancy.../
42 comments
This. This is a full time job. Trying to get leads via LinkedIn? Twitter? Ain’t going to work - preaching to the choir. One needs to reach outside of their network. This is all about meeting people in real world and talking to them. Events, conferences, paid introductions.
Alternatively, one does contracting sourced through headhunters but that’s not really consulting.
It’s all about talking to people, building rapport, establishing trust. Often talks lead nowhere for months or years. Talk to people about their problems, suggest solutions, show your value, but don’t share how.
Next point, without people on standby, some engagements are unreachable because the client will not engage if: a) you have no perm employees, b) you are too small, as in, what if you go under 6 months down the line or some bigger client paying more comes around.
It can be rewarding but it’s a tough market to be in. Competition is huge and there’s always someone with prices lower than yours but positioned better than you at a given point in time.
Alternatively, one does contracting sourced through headhunters but that’s not really consulting.
It’s all about talking to people, building rapport, establishing trust. Often talks lead nowhere for months or years. Talk to people about their problems, suggest solutions, show your value, but don’t share how.
Next point, without people on standby, some engagements are unreachable because the client will not engage if: a) you have no perm employees, b) you are too small, as in, what if you go under 6 months down the line or some bigger client paying more comes around.
It can be rewarding but it’s a tough market to be in. Competition is huge and there’s always someone with prices lower than yours but positioned better than you at a given point in time.
>This is all about meeting people in real world and talking to them. Events, conferences, paid introductions.
Right. I've always told people to do 2 things to always have a job and lots of job offers all the time:
1) public speaking at events and conferences.
2) public writing.
I know a guy, did SQL stuff, and if there was a group of 2 people that got together for a local users group, he'd travel 200 miles to give a presentation in front of them. He'd been doing it for years, as in decades.
The guy got 4 - 5 job offers every day. He had his computer there and showed me the offers coming into his email.
And of course, if you do a lot of writing for any kind of journal or blog, and get published, that's also going to explode your contacts.
.
When you publicly speak or write, it establishes you as an industry leader, even if there are people more technically knowledgeable than you are.
Right. I've always told people to do 2 things to always have a job and lots of job offers all the time:
1) public speaking at events and conferences.
2) public writing.
I know a guy, did SQL stuff, and if there was a group of 2 people that got together for a local users group, he'd travel 200 miles to give a presentation in front of them. He'd been doing it for years, as in decades.
The guy got 4 - 5 job offers every day. He had his computer there and showed me the offers coming into his email.
And of course, if you do a lot of writing for any kind of journal or blog, and get published, that's also going to explode your contacts.
.
When you publicly speak or write, it establishes you as an industry leader, even if there are people more technically knowledgeable than you are.
Becoming an "authority" can help as well. Having a public, professional, persona can help with credibility.
I started off doing training, which progressed to a book, which progressed to more training, which progressed to a free weekly webinar where I answer questions.
In my tiny niche, prospective clients "know my name". If I'm asked to supply credentials it's easy to do, and there's usually someone on their team who's heard of me.
It helps skip over the "can he do the work" part of the negotiation. Customers are happier to do projects, and pay more, if they are confident the project will actually succeed. Typically its not their own money they are depending, but project failures hurt their upstream reputation.
I started off doing training, which progressed to a book, which progressed to more training, which progressed to a free weekly webinar where I answer questions.
In my tiny niche, prospective clients "know my name". If I'm asked to supply credentials it's easy to do, and there's usually someone on their team who's heard of me.
It helps skip over the "can he do the work" part of the negotiation. Customers are happier to do projects, and pay more, if they are confident the project will actually succeed. Typically its not their own money they are depending, but project failures hurt their upstream reputation.
> ...show your value, but don’t share how.
Can you please elaborate on this point? Are you saying that if you create an open source solution, people won't pay you to implement or support it for their use case?
Can you please elaborate on this point? Are you saying that if you create an open source solution, people won't pay you to implement or support it for their use case?
I like this question.
The contrary. IMO, this is one of the best ways to go about it. However, the solution should not give away your secret sauce. Look at examples, two come to my mind: Ory and Yugabyte.
Their solutions are mostly open source and both are examples or healthy businesses operating on an open source foundation.
But not all bits are open source. Not all knowledge gathered by the org is shared for free. In both cases, the value is open source, the how isn't.
The premise is: "this is what can be done, you, the client, can do it roughly like this and this". There's a lot of space to fill between individual "this". That space is your secret sauce, the "how". For the "how", the client needs to engage. The client must have a way to learn the "how" but it's important that the client knows the price of the "how" and is contractually obliged to keep the "how" knowledge internal.
The contrary. IMO, this is one of the best ways to go about it. However, the solution should not give away your secret sauce. Look at examples, two come to my mind: Ory and Yugabyte.
Their solutions are mostly open source and both are examples or healthy businesses operating on an open source foundation.
But not all bits are open source. Not all knowledge gathered by the org is shared for free. In both cases, the value is open source, the how isn't.
The premise is: "this is what can be done, you, the client, can do it roughly like this and this". There's a lot of space to fill between individual "this". That space is your secret sauce, the "how". For the "how", the client needs to engage. The client must have a way to learn the "how" but it's important that the client knows the price of the "how" and is contractually obliged to keep the "how" knowledge internal.
Hmmm, I cofounded the company I'm at now specifically because companies trying to grow in my industry are tired of chasing "qualified leads".
So what we do is the work of getting to a request for bid or quote with target customers and forward those off to our clients.
A lot of "engineering types" including myself can be semi blind to the value of the MBA types. Or even just sales in general.
However, I think the content in the article addresses all that. They mention to:
- frame a value proposition as value creation by solving a problem for your customer
- set appropriate pricing, charge your worth
- and to network professionaly
If you're an individual running a FLOSS consultancy thats great advice to get going with sales, marketing, and B2B credibility. YMMV but for someone starting out they might not be able to afford a digital sales team or a large enterprise contract with an agency to drive growth.
So what we do is the work of getting to a request for bid or quote with target customers and forward those off to our clients.
A lot of "engineering types" including myself can be semi blind to the value of the MBA types. Or even just sales in general.
However, I think the content in the article addresses all that. They mention to:
- frame a value proposition as value creation by solving a problem for your customer
- set appropriate pricing, charge your worth
- and to network professionaly
If you're an individual running a FLOSS consultancy thats great advice to get going with sales, marketing, and B2B credibility. YMMV but for someone starting out they might not be able to afford a digital sales team or a large enterprise contract with an agency to drive growth.
>
A lot of "engineering types" including myself can be semi blind to the value of the MBA types. Or even just sales in general.
I don't think these engineering types are (semi-)blind to this. It is rather my opinion that this kind of sales pitches hardly works on engineers, and sales pitches from engineers do not work for MBA types.
For example, a quite successful business consultant (who nevertheless knows a lot programming) told me between you and me that selling anything to me is insanely harder than selling to C-level executives because I nearly always find the weak points in his sales presentations and ask critical questions.
On the other hand, I somehow "do not speak the language of the 'MBA types'". The most likely reason for that is that deep inside I consider completely different properties of a product to be important than most managers.
I don't think these engineering types are (semi-)blind to this. It is rather my opinion that this kind of sales pitches hardly works on engineers, and sales pitches from engineers do not work for MBA types.
For example, a quite successful business consultant (who nevertheless knows a lot programming) told me between you and me that selling anything to me is insanely harder than selling to C-level executives because I nearly always find the weak points in his sales presentations and ask critical questions.
On the other hand, I somehow "do not speak the language of the 'MBA types'". The most likely reason for that is that deep inside I consider completely different properties of a product to be important than most managers.
[deleted]
So your company acts as if they are part of "my" company and does the boring slog of "do you want a new CRM" until they find someone with that need and connect to a CRM provider?
Yup, we start by generating leads in house (based on your on boarding discussion we help with targeting as well). Then build / execute custom email and call prospecting campaigns on your behalf. All the way up to delivering your internal sales team an opportunity. If you're in B2B find us at Quantum-Quote.com : )
> For serious engagements, pricing should be defined as a function of the value gained for the client from the engagement. For example, if the client saves $250k as a result of the engagement, then you should charge a percentage of that savings.
Optimyze (later acquired by Elastic) initially tried this pricing model and found that enterprise orgs simply wouldn't go for it, despite the cost being effectively "free".
Optimyze (later acquired by Elastic) initially tried this pricing model and found that enterprise orgs simply wouldn't go for it, despite the cost being effectively "free".
Big companies hate rev share, which is essentially what value based pricing model is. Rev share pricing is great for getting small, money-conscious people in the door, but there is a threshold as you get larger where it becomes more cost-effective for the client to go with standard billing.
Substack's been running into this problem, where it's easy to get people to try it out, but as a content creator gets popular the rev share amount becomes greater than the cost to hire an agency and "self-host". Someone making $1mm/yr is going to chafe at a $200k rev share when an agency at $50k/yr retainer can do a similar job.
Unrelated to that but related to the main topic: it's interesting that people treat FOSS consulting as a weird beast and ignore the thousands of successful WordPress/Drupal/etc. consultants and agencies. There's a lot to be learned from analyzing their strategies!
Substack's been running into this problem, where it's easy to get people to try it out, but as a content creator gets popular the rev share amount becomes greater than the cost to hire an agency and "self-host". Someone making $1mm/yr is going to chafe at a $200k rev share when an agency at $50k/yr retainer can do a similar job.
Unrelated to that but related to the main topic: it's interesting that people treat FOSS consulting as a weird beast and ignore the thousands of successful WordPress/Drupal/etc. consultants and agencies. There's a lot to be learned from analyzing their strategies!
It's not more cost-effective for the client if the work just never happens. Further, I don't care what is more cost effective to them. I want to capture some of that value. That's the mistake these businesses are making and what you need to inform them of.
[deleted]
I was once part of a consultancy (not related to free software) that proposed this kind of pricing. The challenges became:
-- Companies couldn't / wouldn't quantify the savings, or refused to share that information.
-- Companies weren't willing to pay it. They would rather have thrown their employees at the problems or paid for the cheapest contractors around, even if it didn't actually solve anything, IE: the illusion they were doing something and at an "affordable" price, regardless of outcomes.
I've had more than one customer argue with me over the years that they would rather pay hourly than a fixed price (however that fixed price was calculated) because it "felt" like they were more in control of the costs, IE: they could micromanage the hours. I've had these same customers spend many multiples of what it would have cost them had they agreed to that retainer or fixed cost.
-- Companies couldn't / wouldn't quantify the savings, or refused to share that information.
-- Companies weren't willing to pay it. They would rather have thrown their employees at the problems or paid for the cheapest contractors around, even if it didn't actually solve anything, IE: the illusion they were doing something and at an "affordable" price, regardless of outcomes.
I've had more than one customer argue with me over the years that they would rather pay hourly than a fixed price (however that fixed price was calculated) because it "felt" like they were more in control of the costs, IE: they could micromanage the hours. I've had these same customers spend many multiples of what it would have cost them had they agreed to that retainer or fixed cost.
> I've had more than one customer argue with me over the years that they would rather pay hourly than a fixed price (however that fixed price was calculated)
Hello, I have been one of these people.
If I agree to a fixed price, then the goal of the contractor becomes "do the minimal amount of work possible to deliver something that can be argued to meet the letter of the contract (and no more)."
If I agree to an hourly rate, then the goal becomes "bill as many hours as possible while demonstrating at least some plausible incremental value for those hours."
Unless I am _really_ good at specifying a precise deliverable (and who among us in the software world is?), the second set of incentives looks much healthier, both for me and for the contractor. I think this is particularly true for open source deliverables. Maybe it costs more, but bounding that precisely is easy ("cannot charge more than X hours in Y period").
I don't want to micromanage your hours. I don't have time for that. Mostly the fact that when you send me an invoice you might expect the question of "What did you actually do?" to come up is sufficient to make sure you really did something (and if not, pretty easy to resolve).
Frequently in the fixed-price contracts I have done, even with reputable people with whom I've had a previous relationship, that "argue" bit above is not hyperbole. Then it falls on me to demonstrate why what you did does not meet the requirements, or is flawed in some other way, and I don't have time for that either. That was why I was paying you. Now the relationship is adversarial and asymmetric: it is easy to not understand a problem, and hard to both understand it and convince another party who is not invested in understanding it to understand.
Whereas if you are billing hourly, you are more than happy to be told about problems that you can then charge me to fix. I get something I can actually use that way, too.
Hello, I have been one of these people.
If I agree to a fixed price, then the goal of the contractor becomes "do the minimal amount of work possible to deliver something that can be argued to meet the letter of the contract (and no more)."
If I agree to an hourly rate, then the goal becomes "bill as many hours as possible while demonstrating at least some plausible incremental value for those hours."
Unless I am _really_ good at specifying a precise deliverable (and who among us in the software world is?), the second set of incentives looks much healthier, both for me and for the contractor. I think this is particularly true for open source deliverables. Maybe it costs more, but bounding that precisely is easy ("cannot charge more than X hours in Y period").
I don't want to micromanage your hours. I don't have time for that. Mostly the fact that when you send me an invoice you might expect the question of "What did you actually do?" to come up is sufficient to make sure you really did something (and if not, pretty easy to resolve).
Frequently in the fixed-price contracts I have done, even with reputable people with whom I've had a previous relationship, that "argue" bit above is not hyperbole. Then it falls on me to demonstrate why what you did does not meet the requirements, or is flawed in some other way, and I don't have time for that either. That was why I was paying you. Now the relationship is adversarial and asymmetric: it is easy to not understand a problem, and hard to both understand it and convince another party who is not invested in understanding it to understand.
Whereas if you are billing hourly, you are more than happy to be told about problems that you can then charge me to fix. I get something I can actually use that way, too.
You’re describing a dysfunctional arrangement in both cases. If the only way to ensure that your requirements are met is by paying hourly so that you and the provider have the shared expectation that you can say “just do it, I’m paying you to do it so do it” then you’re working with bad people.
The problem with hourly is that it is a totally different way of running a project from fixed cost: fixed cost front loads the challenges and provides a great opportunity to assess the suitability of your provider, it demands clarity, a shared understanding, it is immediately apparent if a project is going to go to shit: a fixed cost project (managed properly) can’t start without understanding the end.
If someone can’t give you a fixed cost that you can rely on: find someone else. If someone can’t give you the confidence that they’ll actually deliver what you want: find someone else.
As a software engineer, I bill a day rate for most of my clients because that’s their preference, and it’s easy money for me so I don’t refuse the work, but I actively discourage it because it is terrible economics for clients: it’s burning money. On a fixed cost project, 100% of my time is spent delivering. On a day-rate project, 50% of my time is wasted — because if you’re paying for my time, the dynamic is exactly like that of an employer employee relationship… and to spend a day in any office anywhere in the world, and you’ll find at least 50% of everyone’s time is wasted.
The problem with hourly is that it is a totally different way of running a project from fixed cost: fixed cost front loads the challenges and provides a great opportunity to assess the suitability of your provider, it demands clarity, a shared understanding, it is immediately apparent if a project is going to go to shit: a fixed cost project (managed properly) can’t start without understanding the end.
If someone can’t give you a fixed cost that you can rely on: find someone else. If someone can’t give you the confidence that they’ll actually deliver what you want: find someone else.
As a software engineer, I bill a day rate for most of my clients because that’s their preference, and it’s easy money for me so I don’t refuse the work, but I actively discourage it because it is terrible economics for clients: it’s burning money. On a fixed cost project, 100% of my time is spent delivering. On a day-rate project, 50% of my time is wasted — because if you’re paying for my time, the dynamic is exactly like that of an employer employee relationship… and to spend a day in any office anywhere in the world, and you’ll find at least 50% of everyone’s time is wasted.
>I actively discourage it because it is terrible economics for clients: it’s burning money.
Here’s how I did this on software dev projects in the past that I thought was very fair. I did a monthly retainer of $xx,xxx, where that number is equitable for everyone and is actually discounted off the equivalent hourly rate. Why? Because it’s a pain in the ass to track hours, to argue with you in advance over how many hours each task is going to take, to argue after the fact about why it took more hours, etc, etc. So for me, it’s worth a discount to just bill the client monthly, do the work, and everybody wins. But more often than not, clients still wanted to pay the hourly rate premium.
Here’s how I did this on software dev projects in the past that I thought was very fair. I did a monthly retainer of $xx,xxx, where that number is equitable for everyone and is actually discounted off the equivalent hourly rate. Why? Because it’s a pain in the ass to track hours, to argue with you in advance over how many hours each task is going to take, to argue after the fact about why it took more hours, etc, etc. So for me, it’s worth a discount to just bill the client monthly, do the work, and everybody wins. But more often than not, clients still wanted to pay the hourly rate premium.
I strongly disagree with your sentiments above. As a professional, my goal is to do the work to the best of my abilities. That aside, I should note that the work I was referring to wasn’t software development, but other types of technical work where the customer was bleeding, knew they were bleeding, and the bleeding was to a point they knew they needed outside professional help. But they would still cheapen out and do the equivalent of “stick a bandaid on it” rather than have surgery.
If I were to guess accounting rules the company uses do not account for that sort of pricing. Lets say I install software X. It lets me take 3 people and put them onto something else. Do I really save '3 peoples worth' of money installing this project? Maybe I now need 2 to run the thing? Oh and you have to get this info out of a manager who probably is not really managing that sort of thing and lets 'the money people handle it'. Also it was explained to me once 'why do we have so many contractors even though they cost wildly more' 'we have two budgets, one I come up with every year and I have to stay inside of that, the other I can change at any time, care to guess which one the contractor budget comes out of?' Software/hw expenditures are not discretionary usually, and usually have some sort of depreciation schedule. A rev sharing scheme would put a damper on that sort of tax games they play. What you are seeing is a side effect of our tax system.
Can't really blame them. They just want to know how much it's going to cost them. Somebody is trying to allocate a budget for this project, and they ask "what's it going to cost?" and the answer can't be "the result of a function whose inputs are undefined at this time".
I've come to the conclusion that estimating "value" can be quite tricky. Is it the difference as to what their profit would have been without your specific consultancy, without any consultancy, without a specific solution?
To illustrate why, consider the "value" of a (1) a toilet, (2) nuts and bolts (sorry, I'm not great at examples). You couldn't live well without a toilet, the differential cost of having/not having a toilet in your home is immense. That doesn't mean it's reasonable to spend thousands of dollars on a single toilet -- even if you would if you absolutely had to. The cost isn't that high. The same goes for nuts and bolts in a product: they can be essential for the functioning, but it doesn't really cost much, nor makes sense to use uber-costly nuts and bolts. So a naive differential definition of value can be just a rent-extracting proposition, which I think most orgs would try to avoid.
If you're sure no one else in the world could deliver this solution (i.e. it's extremely scarce and non-reproducible), then the value proposition starts to make more sense (because your time and attention is also limited). I tend think that's rare.
So it seems more natural to adapt to each situation: you need to estimate your (operation) costs and target revenue, and then charge with a healthy margin on that; and if your service is highly unique or in high demand, you adapt by increasing your pricing accordingly.
To illustrate why, consider the "value" of a (1) a toilet, (2) nuts and bolts (sorry, I'm not great at examples). You couldn't live well without a toilet, the differential cost of having/not having a toilet in your home is immense. That doesn't mean it's reasonable to spend thousands of dollars on a single toilet -- even if you would if you absolutely had to. The cost isn't that high. The same goes for nuts and bolts in a product: they can be essential for the functioning, but it doesn't really cost much, nor makes sense to use uber-costly nuts and bolts. So a naive differential definition of value can be just a rent-extracting proposition, which I think most orgs would try to avoid.
If you're sure no one else in the world could deliver this solution (i.e. it's extremely scarce and non-reproducible), then the value proposition starts to make more sense (because your time and attention is also limited). I tend think that's rare.
So it seems more natural to adapt to each situation: you need to estimate your (operation) costs and target revenue, and then charge with a healthy margin on that; and if your service is highly unique or in high demand, you adapt by increasing your pricing accordingly.
>That doesn't mean it's reasonable to spend thousands of dollars on a single toilet -- even if you would if you absolutely had to. The cost isn't that high.
Check out Toto washlet prices. :-) e.g. https://www.totousa.com/washlet-with-smart-toilet-g450-10-gp...
But I agree with your point. If you have some specialized, almost unique, knowledge, have plenty of demand, and are hard to substitute for--and it's something high value--you can charge a lot.
Check out Toto washlet prices. :-) e.g. https://www.totousa.com/washlet-with-smart-toilet-g450-10-gp...
But I agree with your point. If you have some specialized, almost unique, knowledge, have plenty of demand, and are hard to substitute for--and it's something high value--you can charge a lot.
Ah yes, I forgot about those :)
Indeed I would complete the analogy as follows: if only you could produce toilets in the entire world, you could (and probably should) charge a lot of it, since it would be so scarce -- it would be the stuff of world leaders and celebrities; or you could charge for 'how to make a toilet' (which makes sense since your production capacity is limited). That's when your product/service justifies something close to value pricing.
Indeed I would complete the analogy as follows: if only you could produce toilets in the entire world, you could (and probably should) charge a lot of it, since it would be so scarce -- it would be the stuff of world leaders and celebrities; or you could charge for 'how to make a toilet' (which makes sense since your production capacity is limited). That's when your product/service justifies something close to value pricing.
Nah. You can definitely blame them. As a vendor you should be able to put some kind of error bars on the potential savings. If they then refuse because they think your cut will be too high, move on and let them flounder. The major malfunction a lot of executives have is that they overestimate the value of not only their own labor and their company's position in the current market, but they underestimate how hard it will be to get a competent replacement.
I don't really know why. It's partially hubris. But I think it stems from not being able to separate the superficial understanding that happens when being told something from the true understanding of synthesizing that understanding yourself. Most executives seem to go through life thinking they are amazing just because they can understand what people are telling them and attribute it to themselves, when in reality they can make nothing of value.
I don't really know why. It's partially hubris. But I think it stems from not being able to separate the superficial understanding that happens when being told something from the true understanding of synthesizing that understanding yourself. Most executives seem to go through life thinking they are amazing just because they can understand what people are telling them and attribute it to themselves, when in reality they can make nothing of value.
The assumption/trick here is that you are experienced enough that you can make a guess as to how much money the company thinks they will save by contracting you, and you bill them appropriately, without actually telling them what you're doing.
I find that if you're getting this response, you're not talking high up enough in the org chart. Eventually, somebody does care about the overall good of the company, over the turf wars/budgetary bureaucracy of the middle management layer. But your project also has to be worthwhile enough to invoke the higher-ups.
I agree it is extraordinarily difficult to pull off. I have seen it attempted hundreds of times in technical professional services deals and never once seen it get past procurement.
You can however incorporate into your pricing by charging $high_day_rate or $high_fixed_price if you have established the value.
You can however incorporate into your pricing by charging $high_day_rate or $high_fixed_price if you have established the value.
Value based pricing as been tried a bunch of times. I've only seen it work to lower the price.
Apart from RedHat, a couple of successful FOSS consultancies include Igalia and Collabora. Interestingly Igalia is also a co-operative, owned by the employees.
https://www.igalia.com/ https://www.collabora.com/
There are more listed in the employers section of the FOSSjobs wiki:
https://github.com/fossjobs/fossjobs/wiki/resources
https://www.igalia.com/ https://www.collabora.com/
There are more listed in the employers section of the FOSSjobs wiki:
https://github.com/fossjobs/fossjobs/wiki/resources
I think SUSE have some positions focusing on consulting as well.
Lots of good stuff in this article.
However, this bit I find odd:
> When you are starting out, you will also want to focus on recurring revenue. This provides two key benefits: first, you have a bottom line greater than $0 if you aren’t able to close larger engagements, which happens from time to time, especially during the summer months, as managers tend to go on holiday. Second, the recurring revenue customers, assuming that you provide them with good service, will recommend your consultancy to others, including large businesses.
The second point here is that recurring revenue customers will recommend you to other businesses. Why does that have anything to do with them being recurring revenue or not?
Do I miss something here?
However, this bit I find odd:
> When you are starting out, you will also want to focus on recurring revenue. This provides two key benefits: first, you have a bottom line greater than $0 if you aren’t able to close larger engagements, which happens from time to time, especially during the summer months, as managers tend to go on holiday. Second, the recurring revenue customers, assuming that you provide them with good service, will recommend your consultancy to others, including large businesses.
The second point here is that recurring revenue customers will recommend you to other businesses. Why does that have anything to do with them being recurring revenue or not?
Do I miss something here?
What is FOSS consulting?
Aren't many developers "FOSS consultants" since they will introduce at least a few OSS libraries to a codebase?
Aren't many developers "FOSS consultants" since they will introduce at least a few OSS libraries to a codebase?
FOSS consulting is simply working on FOSS projects for money. Integrating FOSS libraries into a proprietary codebase usually doesn't result in work on the FOSS libraries themselves, so doesn't count as FOSS consulting.
Straightforward, sensible business advice. Not much to say about it or opportunities to flame anyone.
What are some real world examples of FOSS consulting contracts?
Has anyone here hired a FOSS consultancy before?
i read this first as a sarcastic title, like you plan to consult on software for free.
kind of like "So you have decided to start a free IT support business" (by offering to help family / neighbors with their computer problems).
i think a much better title would be "So you have decided to start an OPEN SOURCE software consultancy"
kind of like "So you have decided to start a free IT support business" (by offering to help family / neighbors with their computer problems).
i think a much better title would be "So you have decided to start an OPEN SOURCE software consultancy"
"Free software" and "open source" are somewhat famously not quite the same thing.
The free software definition [fsd] and the open source definition [osd] are different in wording and spirit, but Free Software and Open Source designate largely the same set of licenses, save for a few odd ones like the Sybase Open Watcom Public License which is considered as a non-free software license by the GNU project [1] / FSF [2] and most Linux distributions (including Debian, which uses the DFSG [3], which is essentially the same text as the Open Source Definition) but as an Open Source license by the Open Source Initiative [4].
Free software does not mean free as in beer. The confusion caused by the word "free" in English is unfortunate but the world is not perfect.
[fsd] https://www.gnu.org/philosophy/free-sw.html.en
[osd] https://opensource.org/osd
[1] https://www.gnu.org/licenses/license-list.html#Watcom
[2] https://directory.fsf.org/wiki/License:Watcom-1.0
[3] https://www.debian.org/social_contract#guidelines
[4] https://opensource.org/licenses/Watcom-1.0
Free software does not mean free as in beer. The confusion caused by the word "free" in English is unfortunate but the world is not perfect.
[fsd] https://www.gnu.org/philosophy/free-sw.html.en
[osd] https://opensource.org/osd
[1] https://www.gnu.org/licenses/license-list.html#Watcom
[2] https://directory.fsf.org/wiki/License:Watcom-1.0
[3] https://www.debian.org/social_contract#guidelines
[4] https://opensource.org/licenses/Watcom-1.0
That’s the hardest part of running a professional services business by a factor of 10.
The second hardest part, almost as hard as the first, is attracting and recruiting good and reliable talent who won’t mess up your customer engagements.
Negotiating prices as per this article is right at the end of a very long process. If you get there you are almost home dry on the deal.