Making Money from Open-Source Software | Hacker News Reader

Making Money from Open-Source Software

ayende.com

175 pointsaliswe41 comments

For others looking for ways to monetize open source, we’ve learned at Ionic that many enterprises aren’t just looking to buy a premium version of your OSS project, they want your help solving (with software) a ton of related challenges around the technology/space, too.

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

companies outsource the jobs that are the hardest, least-desirable, or worst case, within some turf war or other management dysfunction.. plenty of those also pay "the big money" ... for some duration.. its not easy

Isn't it just consulting? How is it different from just offering dev services as a feeelance agency?

It is, the open source project functions as marketing for your abilities to develop solutions in the space.

Because you can build products around the open-source core. So then you are selling enterprise products, not services.

No, you are shipping and licensing a software product (like SaaS) and you’re not building custom solutions (in the general case), but you are backing it with support. Support is also not the same as consulting hours as you aren’t billing hourly for it and customers can only purchase it if they also pay for the software. It’s probably more like an insurance policy than anything (and should be high margin on its own)

Support is tablestakes for B2B so this isn’t unique to OSS

Sounds like fixed-price consulting to me.

No, it’s more like a SaaS model. Yearly subscription/license and you’re not doing bespoke development

> Sounds like fixed-price consulting to me.

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[1].

[1] https://aws.amazon.com/premiumsupport/plans/

Yes there is s huge difference. One is a yearly subscription and the other is billed per-hour or is a set of consumable hours you buy one-off. Most teams don’t just sell support on its own, you only get it if you have a subscription to the software product behind it.

yeah what you're describing is almost a textbook example of enterprise services/consulting that companies like Oracle/IBM/HP have been doing for decades.

and what you're describing was also debunked as a scalable core business model by many companies...

https://a16z.com/2014/02/14/why-there-will-never-be-another-...

Actually our particular model is more like the OSS as a service he gets to at the end, but it’s unique to us and so my original comment was more broad strokes.

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.

this sounds much better than what the article suggests which i almost stopped reading at "making money from commercial licenses".

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?

Yes, I have the same question?

I work for a Danish municipality that co-operates a number of open source projects with other muniplacities. I know we’re a niche of sorts, but the setup we apply is to find small local development houses who can build and maintain our code based, but also sell us hosting.

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.

> whole governance around the code base

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".

Reupping Nadia Eghbal's excellent, Lemonade Stand: A handy guide to financial support for open source

https://github.com/nayafia/lemonade-stand

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.

Fun timing, we're about to publish an update on how we've done it (last mentioned in 2016 https://blog.sentry.io/2016/10/24/building-an-open-source-se... ).

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.

When you talk about making money with open source software, it's about figuring out what scarcity to sell:

https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...

I personally like CrossOver's model. It doesn't include anything you couldn't already do with Wine, but it's less setup, and you have a support staff that can look at it if you really need a particular program to work under Wine. Any improvements they make are upstreamed to Wine.

I have no idea if they're "profitable" or not.

Well, if they aren't then someone with very deep pockets is having fun there because they are like thirty people and have been around for more than twenty years.

Are there any examples of small/simple projects or pieces of code released under the GPL, with a non-GPL dual license being sold for $X000?

Would offering a “subscription” improvement program be a viable alternative? You the developer are the expert on the software, and hiring the original developer to modify or tweak the code may make sense, But make it a reoccurring fee kind of like a subscription. You could offer services based on the intensity of the work. Perhaps one subscription offering differs from another by the total max hours. Like the gold plan would be 40 developer hours per month and silver be 30 or whatever. You would have to feel out what kind of commitment could be there.

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 don't think so. I don't see why someone would choose this subscription model over a standard contracting model, billed by the hour. Or, billed by the hour with a 30 hour/month minimum and maximum.

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.

After reading this several times I still don't understand "how [they] did it." Also tried the AGPL description.[1] Can someone confirm: They just licensed it so that commercial use is prohibited without payment?

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.

[1] https://tldrlegal.com/license/gnu-affero-general-public-lice...

It is more nuanced than that: RavenDB seems OK to use if you have an application that shields its users completely from the database itself. The database server is AGPL, but the client library your application uses is MIT licensed, which is fairly liberal. If you were to directly embed RabenDB in a product, you would have to provide the full source, even if you run it as a service and don't distribute binaries of the software.

Therefore, companies pay for a license to avoid having to provide the full source of their application. Is that right?

From what I understood (surveyed this a while ago) RavenDB wants commercial clients to pay. They do this by licensing the free version as agpl. You pay to get another license. Keeping your code agpl as a commercial entity is a kind of loophole in their eyes.

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.

As I see it the licensing of RavenDB lets you get away with things like a closed source CMS using the DB for your own use, as long as the database runs as its own process. Not sure of you could sell the CMS binaries without source code, though.

You can if you distribute separately and the CMS binaries aren't embedding the DB software. You would ship an installer for the AGPL portion to comply with those terms, and your CMS would use a REST interface to interact with the AGPL-licensed backend

> 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."

Why not consulting?

Because as the article says its work intensive

TL;DR: AGPL database. Permissively licensed client libraries. Dual licensing the database. But really you should read the post, for the thought process that led to that approach.

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/

My personal project Video Hub App is for sale for $3.50 per copy, but is also open source: https://github.com/whyboris/Video-Hub-App

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.

I've looked into your app and loved it. The only thing preventing me from paying for (and using) it is tag support.

Tag support is coming in version 2.0.0 (before March 22nd). Pull in the current master to see it! Currently very WIP (UI needs minor polish and there are some bugs) but tags are usable.

I’m using IssueHunt. https://issuehunt.io/ It is an issue based bounty service for OSS. Actually I have not maintaining open source, but I’m using them in my work. So as my appreciation, I sometimes put bounties for issues of several projects. It seems that maintainer and contributor can get bounty.

How much have you paid out so far?

Most projects like that are well-meaning, but are more like tip jars than real monetization.

Not a question about the article but related: what software tools are lacking in the community? Where should people start looking when brainstorming for project ideas?

We can all agree we need to give back to the community. Eventually we will need to eat too.

getting paid for integration?

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

I guess it depends on the category, for something like a database it can be easy to charge money (e.g. managed instances, charging cloud vendors, etc...) but something like frontend javascript framework it's almost impossible to do that

Reply on news.ycombinator.com