The big money is in doing those things too and not just being one small piece of the puzzle. So, for us, that means helping teams be successful with app development in general using our software/tech in the process (i.e. scalable software product on a yearly subscription and the same as sold to other customers, not custom development).
If you want to go down that route, get ready to have excellent support and be willing to be seen as an expert that your customers are going to call upon. But support is tablestakes for B2B so that comes with the territory.
Of course, this is no small leap. Going from having a successful open source project to building an enterprise business around it is really hard and took a lot longer than I expected. Looking back I wish we spent a little less time worrying about GitHub stars and more about solving enterprise problems, but we made it through!
Of course this is just one way to monetize and I’m also excited about the growing OSS sustainability offerings out there, like Tidelift
Support is tablestakes for B2B so this isn’t unique to OSS
and what you're describing was also debunked as a scalable core business model by many companies...
A lot of the software our customers pay us for is _not_ open source but fits in with the open source in a really natural way (and we’re on the frontend/mobile). We also don’t see support standalone, you only get it in tandem with the software subscription.
“Support” is a loaded term. Every B2B company has to have a team able to support their biggest customers and you’d be dumb to not charge extra for it. I don’t think the shape of our support is that much heavier than any B2B SaaS company today and our high gross margins just on support further prove that (but it’s not our core business).
So far the model is scaling. Can it scale to be another public OSS success like red hat or mongo? We’d like to think so but we’ve got a long ways to go still on that.
Is there no difference between technical support and consulting?
I see technical support as answering emails and picking up the phone when someone needs the help using your product.
For instance, AWS Support Plans.
that model just doesn't work for me because while it may work financially (and i have seen companies being successful with it), it prevents the product from being fully immersed into the Free Software ecosystem.
to sell commercial licenses i need to own 100% of the code, which means i can't easily accept outside contributions, nor can i use GPLd libraries which would conflict a commercial license. i do not want to be limited in my choice of tools to suit a commercial license. that's not what i think a good Free Software project should be like.
your comment therefore feels like a relief. my question is though, how to get the companies interested when the product is not yet proven? how to start, find the first customers? those who will pay enough for support to allow me to finish building the product?
We’ll need a system to handle our vacationflow, with employees reporting it, managers approving it and an integration to our payment system. We’ll handle the business understanding (it involves around 33 different tax laws and some silly organisational culture), the project management and the whole governance around the code base. You do the coding, and then you sell us the hosted solution which you run in Azure or AWS letting our ADFS handle authentication.
It’s worked marvellous so far.
Yes, ideally you want to have some highly competent in-house technical ability to assess the quality and maintainability of the codebase that is being produced, separately from the business requirements,
otherwise there is a fair chance that you may end up with a lot of low quality code and a system that cannot be safely or cheaply modified.
I've seen a couple of organisations outsource development, keeping only project management and domain expertise in house, but having no in house ability to assess the quality of technical work.
Don't do that. If your vendors fill your project with the most profitable least experienced/capable developers, after enough years of that you'll get to have exciting meetings about "we're no longer able to estimate how long it will take to make changes to the system".
This document aims to provide an exhaustive list of all the ways that people get paid for open source work. Hopefully, projects and contributors will find this helpful in figuring out the best options for them.
The #1 piece of advice I could give is standard b-school boilerplate: figure out what your unique advantage is and how the market wants to pay for access to it. That might be training, support, SaaS or paying for features but you have to do the legwork.
I have no idea if they're "profitable" or not.
But it can be nice for you that those hours are max. If they don’t ring you up at all you still pocket the money for that month.
I would also question the ethics - if three customers want the same thing, do I bill each of them? Or each of them at 1/3? After all, they are paying for hours.
I charge a yearly support fee for my product, which covers any questions (rare) and funds additional development. Support customers get free upgrades, so I don't need to figure out the hourly billing.
I've worked (and am working) with companies that have an open-source product and a commercial offering built around it. My experience is that it's easy to get _some_ companies to pay you, whether it's for the right license, added features, support, or consultation. But to make any significant revenue you're going to have to work hard to provide a lot more value on top of the open-source option, and you probably don't want it to be "consulting."
Then you realize that all your prospective buyers are anchored at "free" and need a lot of convincing (perceived value) to pay for the commercial version. The positioning needs careful consideration. Nobody wants to pay a five- or six-figure license for a slighty-better-than-the-free-version solution.
So they keep commercial clients out by using agpl. That means they want you to pay even if you build a website that uses a cms that uses ravendb. Even though agpl perhaps would let you get sway with it. Dont think so though.
Why not consulting?
Among well known database vendors, the natural comparisons are MongoDB and MySQL.
Like Mongo, RavenDB is available under a single network-copyleft license. Like Mongo, RavenDB client libraries are permissively licensed. However, MongoDB focuses on selling all-encompassing packages that include a mix of support, services, and add-ons. To hear this post tell it, Hibernating Rhinos is running more of a pure dual-licensing play with RavenDB.
That approach puts them close to MySQL. However, MySQL dual licensed both database and client libraries. Nobody needs to buy a commercial license for RavenDB client libraries.
The obvious question, in current context, is whether Hibernating Rhinos is cruising for a cloud provider bruising, the kind of which Mongo has loudly complained. Cue Server Side Public License.
Here follow shameless but relevant plugs:
Plain language, more general take on an SSPL-style license: https://github.com/kemitchell/shared-component-license/blob/...
Open form paid license agreement for indie developers dual licensing, or doing paid add-ons: https://github.com/indieopensource/paid-license
License Zero, which offers dual-licensing back-office as a service, as well as public licenses without the problems and known vulnerabilities of *GPL: https://licensezero.com/
Have 437 sales as of today (released 1 year ago) with many people opting to pay more than $3.50 -- though I'm funneling $3.50 from every sale to a GiveWell recommended charity.
Most projects like that are well-meaning, but are more like tip jars than real monetization.
We can all agree we need to give back to the community. Eventually we will need to eat too.
1) create a popular open source product
2) give it away, building market share and awareness
3) shake down corporations making money from your open source product in the form of "licensing & maintenance agreement*
4) Trickle down effect on non corporate users who in turn feed back into the loop by performing QA and community support.
I personally believe this is the future of software, at least someone who is competing against VC funded proprietary entities looking to IPO and not really give a shit about the product that brought them in a position to raise money.
What do you guys think? This is just my opinion of course downsides to this model.
One major downside of openin the doors to everybody is you get a ton of noises. People who shouldn't be using it complaining and it's always tricky to manage, especially when people feel entitled to it as it is free.
An argument to this noise is that any noise is better than no noise, meaning any type of engagement good or bad is considered a plus for the app, to discover new shit