I have a viable open-source solo business, so I'd dispute this.

I've written about this in more detail in the past (https://httptoolkit.tech/blog/free-as-in-beer/) in short:

* It's a freemium desktop app, with advanced features behind a paid subscription.

* It's 100% open-source - including all the paid parts.

* Although the paid parts are open-source, the code does include the implementation of the subscription checks. You are fully entitled to fork the project and remove all those to get everything for free, but if you do then you now have to maintain a fork of the project yourself. The product is not that expensive - for anybody with a salary, even having a meeting to discuss doing this is not worthwhile.

* All the core product code is AGPL, to avoid proprietary forks cloning the whole thing and breaking this model (many of the smaller internal libraries that are generic & generally useful are Apache 2 though).

* All open-source contributors get free subscriptions, so if you're willing to get involved in the project it acts like any traditional free open-source project for you.

So far it's working well - there's a few hundred paying customers, including a good few team subscriptions, and it's been making good steady growth for over a year now.

This model wouldn't work for everything (you need something product-shaped, rather than a standalone library) and I have no idea how it would scale out as a larger business, but it's been a very functional model for me to make an open-source project that's financially self-sufficient as a solo developer.

> product-shaped

Helpful in other ways too: 1. no royalties under international tax treaties 2. "desktop tools" seems more viable as a business than libraries e.g. JetBrains Intellij IDEA (maybe because a library is at the dev's level, but an app is one step removed?)

> free subscriptions

Great for a paid product (reminds me a little of Dropbox's referral program, in that it rewards with the product itself), but it seems an exaggeration to describe getting one month (or one year) free subscriptions as "like any traditional free open-source project". Though, I suppose if one was dedicated enough to contribute every month, it would be... (and of course, motivate that dedication) But let me repeat to be clear: this is great for a paid product.

You're way ahead of me, but let me share this anyway: if you are kind of open-source, and step too far away, it can generate a pure open-source rival. Or looked at another way: being sufficiently open-source is a barrier-to-entry (denies oxygen) to a fully open-source rival ("why would anyonw use it, when there is already your mature project?") Though "product-shaped" probably the greater help here.

A subscription model for a non-hosted desktop app twists my mind a little, but I think it makes a lot of business sense, both for you and for customers (two examples: it's an expense, not an asset; monthly (or yearly) is more affordable than an outright purchase).

Anyway, it's great to be able to devote yourself to open-source, without being taken advantage of.

Thank you for your input, and for the link to your insights. I'm working on bootstrapping an open-source project that solves a very common problem in a certain development niche, and finding a functional model for getting paid for the time I put in has been a thorn in my side. A similar approach to yours sounds very appealing.

For libraries people like you are the customer. So here's the question: How much could and how much would you pay for well-maintained libraries?

I am so tired of this bullshit old flogging horse. Here we go again.

There are lots of profitable companies built on or around open source. WordPress and its entire ecosystem come to mind, especially including all the rest of the open source projects Automattic ($3Bn valuation) touches. Similar for Drupal, especially the founder's own Drupal service company, Acquia (sold at $1Bn valuation). There's no shortage of smaller companies like Sensio Labs, maintainer of the Symfony PHP framework, at 100 people and $1.9M. Or Plex, or a dozen other ~100 person companies. We may even have too many consulting companies who contribute patches, testing, and extension into OSS ecosystems.

Should we bring up the biggest companies in the world, who maintain projects equally large in importance like Kubernetes, Typescript, Chromium, React, Golang, et al? What about the "pure" open source companies like RedHat or Canonical?

There are lots of ways to make money on, in, and around Open Source software. It's sure hard to make a unicorn valuation, but that's not the definition of a "viable business model." Every 10 person "mom and pop" web consulting agency that pays their employees has a viable business model. Microsoft and Facebook have a extremely viable business models. The fastest growing service on Azure is their Kubernetes implementation, which is open source down to the hypervisor (and yes, you can run AKS on your own hardware and KVM if you like).

So don't give me your sour grapes about there being no "viable" business models in open source. Maybe there are no viable UNICORN business models. Maybe there are no viable get rich quick models. Maybe there are no viable business models if you start from a development methodology rather than a customer need. Maybe Open Source is a liability for certain kinds of business models. We can discuss that. But "viable business models" are practically a dime a dozen in and around open source.

I've spent most of my career doing open source.

I take home a decent salary. It's about the upper end of software engineers NOT in FAANG and related companies. If I went to FAANG, I'd get double, potentially much more, and hate my life.

Newsflash. The problem isn't open source. Running a successful business is hard.

But there are success stories. IBM spent $37 billion last year to buy Red Hat. Microsoft has invested a huge amount into open source. Oracle keeps on buying open source products.

Most of the best successes are not pure open source plays. What you do is invest in open source for the complements to your main product, then charge more for your product. Companies and people start with a problem that they are willing to pay about $X for a solution to. They don't care about how that $X is divided up. So if some of the pieces are free, then others can cost more.

Oracle's investment in Linux 20 years ago serves as a demonstration. They invested in making Oracle run well on Linux, and pushed Linux over Sun. But if you tried to run Oracle on Linux, your license fee was higher. However it was cheaper than paying for Sun and paying for Oracle. The result? People switched to Linux and Oracle made more money.

From 2002: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

"Smart companies try to commoditize their products’ complements. If you can do this, demand for your product will increase and you will be able to charge more and make more."

My favorite model is to make it closed source initially, then once it's paid itself off plus profit, then open source it.

This is what John Carmack did with the game engines he wrote at id software, and the id lawyers hated it (but it was a great boon to the rest of the world)

When Carmack opensourced Doom and Quake those game engines were very dated and they had made hundreds of millions from them.

The Doom source code was released two years after Quake was released and 6 years after Doom was released. There was no opensource business plan.

That timeline doesn't seem quite right. Unless I am mistaken DOOM was originally released in December of 1993 and the source was released December 1997. That's only 4 years, however Quake was released in June of 1996, which is close enough to 2 years.

It is also worth noting that commercial releases of DOOM continued through 1997 on various home consoles even if you ignore the various resurrections it has had for the likes of the GBA or Switch.

Edit: I think I get your timeline, you're referring to the re-release of the DOOM source under GPL in October of 1999.

That mode does work particularly great for video games and other creative media, which really do depend on early sales but often have very little revenue after the first few months/years.

The vast majority of the back catalog of movies, music, and TV is nearly worthless to studios and labels, and when you dig into it you actually find out that studios are as cheap as possible with their archive of masters (perhaps with the exception of consistently profitable blockbusters). I recall reading an in depth article about a recent vault fire that destroyed many original studio recordings, and that the issues leading up to the disaster were preventable.

I think the studios are too short-sighted to see the value of releasing many of these into the public domain, and I think some creativity could turn it into a business model that drums up interest and revenue.

Here’s an idea: a studio or record label could run a “Kickstarter” where sales of a commemorative collection could hit a certain threshold to trigger release into the public domain. These could be mainly made up of content that has otherwise fallen into relative obscurity.

I mean, I’m no business expert and maybe that’s a dumb idea but it’s at least new and unique.

Vault fire article: https://www.nytimes.com/2019/06/11/magazine/universal-fire-m...

Follow up from this year: https://centralsauce.com/lost-in-the-fire

A previous notable fire: https://en.wikipedia.org/wiki/1937_Fox_vault_fire

I think the problem with vaults and vault fires is that the original - the master recording - is analog and irreplaceable by definition. All copies theoretically don't encode valuable data still left in the master that might be useful in the future as remastering technologies continue to improve. It's not a digital master where every copy is identical in fidelity. Until we can accurately clone physical objects, there can only be one master copy of an analog recording.

Thanks for that, I was far too lazy.

I wonder if there is a license that you can use that had a built-in expiration date. Like a auto-public-domain code release clause.

Some way that if you start using a product you have a legal guarantee that you won't be dependent on that company's service indefinitely.

A built-in expiration date, like a sane copyright law. The original law was 14 years before disney got a hold of it.

According to Wikipedia though, that copyright extension was to harmonize with the EU copyright terms. The EU member states increased the copyright terms first and companies in the US also wanted the same terms in the US.

https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act

The Business Source License does that. I'm not able to find a site for the project but Sentry's got a blog post about it: https://blog.sentry.io/2019/11/06/relicensing-sentry

Yes this is possible. Founded a company selling to governments and we put this in every contract. It help assuage their concerns in case we went out of business.

Sounds somewhat like the Transitive Grace Period Public License, where derivative works must be open sourced a year after deployment

In the United States, authors cannot put their creative works into the public domain. There is noting in the statute or case law that allows this. Furthermore, authors (except work-for-hires) and their heirs, have the right to terminate copyright transfers and licenses after 35 years.

No, but you can license the work on terms roughly equivalent to what is allowed under public domains via something like https://creativecommons.org/share-your-work/public-domain/cc...

I don't think you need a special license. The owner(s) of the code just need to issue a statement that the code will be available under <license> as of <date>, similar to what Dan Bernstein did with qmail.

If you are a company dependent on a startup you can often get the source code in escrow if the startup would to fold or be acquired. I have had this work out multiple times in the past.

Yeah what if it were similar to patents, they have a standard shelf-life of protection.

With software I feel like a much shorter timespan would be better as systems become obsolete much faster.

How would you enforce it? Patents require a patent so it’s easy for that to slip into public domain but source code is a living beast that’s al2ays changing are the patent offices supposed to keep an up to date repo of all projects?

I think op is talking about licenses, not drm.

oh, whoops

I mean it's perfectly possible to have a license that legally expires at a certain time. Most businesses, in an effort to avoid fine liabilities, will follow the legal terms. Periodic online activation definitely helps increase compliance rate, but in terms of true, total compliance enforcement, it's a DRM situation, it's not possible.

A license is a legal agreement, and good luck arguing in court that you live in a different time than everyone else. You’re talking about the mechanics of how a license key would work, which is really not what is being discussed.

You'd have to change the system clock of your legal system.

How is it an open source business model?

It is a closed source business model that decides to open source legacy product. It worked so well that the open sourcing stopped when Id was acquired by ZeniMax.

That is a cool move but (unfortunately?) not a business solution. Most of the common web tech would have failed if their creators had chosen this model at inception.

Reddit would disagree (although they’ve went the opposite way in recent years.). They were open source early on and yet no competitor arose to overtake them.

The thing about that though is an engine is not the game, and it's common to separate game content/assets from it's engine. It's not so clear that other software breaks down in the same way; should the whole thing be free, or should only the "core"?

Maybe applications can open their libraries, but not the apps themselves?

I've spent a career in open source businesses and helped some closed source businesses go open. The statement that there is no OSS business model is completely untrue. Let me give you a few models that work:

* Run a hosted service (ex: Algolia, Wordpress.com)

* Sell enterprise subscriptions which include packaging and support (ex: Red Hat)

* Sell professional services (ex: Hortonworks prior to Cloudera sale)

* Be a boutique consultancy (too many to name)

* Sell OSS relevant products - security or management (ex: Fossa, Snyk)

* Have an open core model where foundation is open but management/integrations are closed. These companies will also move the closed stuff over to the open side as the market dictates which will cause them to continually innovate (ex: Cloudera)

* Dual licensing based on usage. Consumers get one license, business gets another.(ex: mySql)

* Open source package subscriptions for developers (ex: Tidelift). This is a very cool managed open source model which is pretty encouraging.

OSS is the amazing way to do guerilla marketing that results in an emotional connection with your user. That alone is monetizable.

I can keep on going and going. There is definitely a way to make money. There is definitely a way to build a scalable business. Just because something is hard doesn't make it impossible. And lastly, for those who spend their days looking for solutions, this isn't a black and white issue. Look for the grey and you can unlock millions/billions in value.

(background: Former red hatter, part of 3 OSS startups, huge OSS fan if done right. personally like the hosted OSS model the best)

I wrote about this a while back:

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

Businesses require a scarce good or service that other people pay them for in order to function.

So many developers would simply like to sell their open source product so customers can run the product themsleves. It's simply impossible. There are some success stories, but they are always the exception, not the norm.

There is another option - one that some open source advocates dislike: source-only products i.e. you sell your software product to customers to run them themselves. You give them the source code of your product so they can customise it to meet their needs. But the software is not open source and cannot be shared the way open source can.

There are successful source-only products. Two examples: Craft CMS and Kirby CMS. Both publish their source code on GitHub and rely on the honesty of their customers to pay (which they do). They have a thriving community of developers making plugins and extensions - proving that you can create a community of developers around a 'source-only' product.

By the way, the GNU Project (supported by the Free Software Foundation) has never updated their advice on selling open source software to reflect reality. They still advise developers to charge for support or charge for documentation (unpopular and unappealing with both developers and customers).

Or they advise charging for the distribution of software. This might have once made sense in an era of CDs and dial-up internet but makes no sense in an era of broadband and GitHub:

https://www.gnu.org/philosophy/selling.en.html

If people keep doing it anyway, there's no problem to be fixed.

Otherwise, government funding: it's infrastructure! Something like universal software engineer basic income. It keeps them off the streets.

When you do the "UBI but for _____" thing you can't call it UBI anymore. You have to change the first two letters because it's no longer universal or basic.

> Otherwise, government funding: it's infrastructure

In the current political climate it's difficult to remind people that tax money was the main source of funding for semiconductors, early computers, Internet, optic fiber, satellites, GPS, GSM, CD-ROMs, LCDs, touchscreens, batteries. And then C, BGP, early UNIX.

I'll listen to this later but in terms of successful open source businesses, one that comes to mind is BitWarden (and mainly that comes to mind because I just talked someone into that -- and away from LastPass -- this morning). It's certainly open to question if Freemium is a viable business model but it seems to be working for them. (Does Automattic count as being freemium as well?)

Granted, the fact I can only think of one or two examples does actually make your point more than question it.

It depends on what one's definition of viable is. Take VC money and become a billionaire?

It could also be that any business is hard and there is less people trying open source models so there are fewer success stories. It's not like there aren't thousands of failing closed source solutions or no opnen source success stories. I the end it does come down to is you can sell

If commercial software companies were liable for their security flaws the penalty money could be fed into an Open Source fund.

And who pays when the flaws are in open source software?

If the flaw is in open source software, it would be the responsibility of the commercial company that shipped the open source software, for not auditing the code they shipped.

You can always disclaim your code if you want to take no responsibility for damages, as in the MIT license.

You cannot disclaim away the law. You cannot sign a contract with a non-government entity that makes it legal to break the law.

If an individual can disclaim their code then there is no sane reason a corporation couldn’t. It’s not logically consistent otherwise.

Ignoring the fact that's either impossible or requires government overreach that would make a fascist blush, it would take the Hacktoberfest problem and turn it up to 1000.

> requires government overreach that would make a fascist blush

How is keeping companies liable for their failures something that would make a fascist blush? Companies should be liable for their mistakes, especially when it's negligence that results in user data being blown all over the internet.

> Companies should be liable for their mistakes, especially when it's negligence

There's a vast sea between mistakes and negligence. Exactly 0% of the people posting on this site have written 100% bug free code that's been pushed to prod/released to customers.

Yes, and no doctor is 100% error free in his/her judgement. We can sue if a doctor amputates the wrong limb.

How is software any different?

It's simply a matter of making companies pay for externalities. If you pollute the environment with your business, you need to pay for that. If you pollute the world with buggy software, you need to pay for that. But all companies have externalities?! Yes, and they should all pay for their externalities and if the cost is high enough that the business is no longer profitable, it needs to close.

Software without bugs isn't some pipe dream - the people writing software will simply be elevated to the level of a surgeon. Do you want your surgeon introducing 'bugs' during your operation? I don't, that's why surgeons get extensive training and are highly compensated.

People want to pay people peanuts for software that barely works, so that they can capture and monopolize as much of the market as quickly as possible. Uh, that's not my problem that people who want to get rich will have difficulty, I want shit that actually works.

Again, that's negligence and you can sue software companies over negligence.

> Software without bugs isn't some pipe dream - the people writing software will simply be elevated to the level of a surgeon.

Your doctor analogies really don't make a lot of sense. Surgeons likely make small mistakes all the time, they're just working on one system (person) at a time and can fix them immediately.

Software without bugs is absolutely a pipedream. Maybe you just haven't worked on very complex systems written over the span of many years or decades?

> Yes, and no doctor is 100% error free in his/her judgement. We can sue if a doctor amputates the wrong limb.

> How is software any different?

You can't bugfix an amputated leg. Which is additionally only 1 clear defined task.

I'm really wondering why someone on HN is making this illogical comparison. This ain't reddit

You can't bugfix a nuclear plant disaster once it happens due to a software bug.

Software is used for real world things, and some of those things have irreversible consequences.

You are comparing regular software to nuclear disasters and amputating a leg.

That's nuts.

Things like SqlLite have 100% unit and integration tests, because that's what it requires for being used in airplanes.

That's how "bugfree" software things works.

Read more about it and you'll see what insanity you have to apply to fully test your software to let it be "bugfree".

Summary for only SqlLite:

- Four independently developed test harnesses

- 100% branch test coverage in an as-deployed configuration

- Millions and millions of test cases

- Out-of-memory tests

- I/O error tests

- Crash and power loss tests

- Fuzz tests

- Boundary value tests

- Disabled optimization tests

- Regression tests

- Malformed database tests

- Extensive use of assert() and run-time checks

- Valgrind analysis

- Undefined behavior checks

---

Feel free to create software with a all possible checks for "employee time off". By the time your full stack app is done, you're 20 years from launch.

In the meantime, 1000's competitors with an MVP successfully launched and expanded features and your stuck because of all the tests.

The moment such liability becomes widespread, there will be a corresponding increase in the need to carry business liability policies. I think it's naive the believe this (and the associated cost) won't trickle down to the individual developers.

You can usually only fix one problem at a time.

For every fix for every problem, there will be some cynic saying it doesn't fix all of the world's other problems and he/she would be correct.

If your goal is to come up with one action that fixes all problems, your best bet is to do nothing at all because the ask is impossible, outside of suicide, which would eliminate all perceived problems, for all of time to come.

I don't disagree; I'm talking about the two pieces together: fine closed software and then give the money to open source. Fines are for disincentivation and/or victim compensation.

Governments fine companies for environmental, ADA, etc. incidents/violations, why not for IT-related security incidents/violations? Governments also give money away to for-profits and nonprofits all the time via grants.

Not sure how those things are related? Non IT security events are not penalized by the government, e.g. if someone breaks into your warehouse and steals physical goods you don't get slapped with a fine for buying the wrong padlocks and ABUS doesn't get a fine for making a lock that was cuttable.

Governments do penalize non-IT security events-- first thing that comes to mind are laws that impose penalties for improper storage of a firearm. It probably depends on jurisdiction but in my Google search, "proper storage" can require the firearm to be placed in a locked container or have a tamper resistant mechanical lock.

SourceHut proves this wrong. Every single line of code we've written is open source, since day one. There are no periodic code dumps, no prototyping in private, no open core with paid extensions. We accept patches from the public. Our company is 100% bona-fide open source.

We've been profitable for 2 years, and our profit margin continues to grow. We published our Q3 financial report last week:

https://sourcehut.org/blog/2020-11-11-sourcehut-q3-2020-fina...

This doesn't include our part-time consulting arm, which is also 100% open source and generates similar revenue.

It's still early, and we're still small. We did not take on any outside investments, either. But the model works. You CAN make money in open source.

Am I missing something? I mean, I know you said "we're still small", but:

>The total gross revenue during Q3 was $16,134, which after transaction fees is $14,972. >The monthly revenue from all subscriptions is, accounting for credit card fees and amortizing yearly payments, is $5,952. >SourceHut has $13,858 in cash at the time of writing.

Those figures are tiny! SourceHut doesn't make enough money to pay a typical full-time software developer. That doesn't feel like a viable open source business model to me.

We pay two full-time software developers, actually, and are likely to hire a third next year. We don't pay especially generously, but we do all make a living and we're satisfied with our income. Plus, we earn more from the consulting arm I mentioned - which has comparible revenue to our SaaS offering, and is also 100% FOSS.

The title of the article isn't "There's still no viable billion dollar open source business model". We have a business. It's a small business, but a viable business nonetheless. Our business is growing more slowly than the typical VC-funded software startup that we commonly associate with tech businesses in $CURRENTYEAR, but it is profitable and growing nonetheless.

I don't need something to have a billion dollars in revenue to be "viable". But that "viable" word is important. A business as lean as SourceHut clearly feels like it's in the start up phase, it doesn't feel like it's reached viability to me.

With just 2 software developers doing this work, I wonder what happens when one of the them is hit by the proverbial bus (goes out on parental leave, takes another job, etc). Because that's a thing that happens and is handled in real, viable companies.

And I'm guessing these software developers have some ownership stake in the company and are accepting below market salaries for now, in the hope that SourceHut becomes valuable enough to cash in that way. But folks won't stick around for below market pay forever, especially if it gets to a point where it looks like the big payday is never coming.

Well, we are a startup, we've only been here for 2 years and our product is still in alpha. But we are already profitable and sustainable, and have been for a while - that counts as viable in my book. We're going to have to come up with a definition of viable that disagrees with that if you want to argue it further.

Our planning accounts for the bus factor. It'd be bad, but not unrecoverable. And because our software is entirely open source, it wouldn't even be the end of the world for our customers.

And no, our other employee does not have a stake in the company, other than a personal one. Our motivations are not based on future earning potential, some future "cashing in" moment, but on being able to do what we enjoy full-time. Either of us could (and have) worked for more, much more, but we're comfortable and happy with what we're doing. The business is basically a way for us to be comfortable and happy with our work first, and a profit vehicle second.

The fact that this is unusual, and makes you raise your eyebrows and question the viability of the whole affair, is disappointing to me. We believe that this is the socially responsible way to start a business, and that it should be more normalized in the tech business community. That our business is viable is a mathematical fact.

Agreed, we're just thinking about our own, different, definitions of viability. No big deal.

That nit aside, what you've done with SourceHut is really cool. Congrats on getting it to where it is today and best of luck continuing to grow and improve!

It's opensource + a hosted offering, which is a pretty popular business model used by eg MongoDB.

By my understanding, though, you're not being paid directly for open source. You're paid for the code hosting, etc. You might arguably say open source is what's bringing in customers for your paid services. The problem is that most open source is not like that, with no similar opportunity for monetization.

I'm not sure why this is supposed to be a meaningful difference. We write open source software and make money doing it. Why does it have to apply to every kind of software project to be valid?

Because if there are software projects that can't practically be free software while bringing in enough money to fund development, then free-software advocates should acknowledge that sometimes proprietary software is a perfectly valid option. Put another way, while free software is good and should be encouraged when it's practical, I don't think it's right to insist that proprietary software is bad and should always be avoided. The companies that abuse the power that comes with the proprietary model are well-known (and thankfully I no longer work for one of them). But some developers of proprietary software are just trying to develop good software while making a living, the only way they've judged that they can.

Also, the hosting business model sometimes leads to misaligned incentives. I don't believe Sourcehut falls in this category. But consider, if a developer of an open-source package makes their money from hosting, then what incentive is there to make the package easy to self-host?

Maybe “business model” is the wrong approach?

The question should probably be, "how can a business benefit from open source," instead of, "how can a business profit from open source."

The primary benefit is the ability for businesses with diverse, or even conflicting, interests to collaborate on a project. You won't see many businesses creating and profiting from an open source operating system or development tools. You will see businesses contributing resources to open source operating systems or development tools since they don't have the resources to develop their own and don't want to be bound to conditions stipulated by another business. Consider how much power Microsoft had over the PC industry simply through the licensing of BASIC, DOS, and Windows in the '80s and '90s. Consider how much power Google has over the licensing of closed source components of Android.

I suspect the reason why open source works in a handful of domains and not in others depends upon who the end user is. Notably, the end user must have the motivation and skill to participate. If you're developing embedded devices, you probably have the ability to contribute to an open source operating system or development tools. The fact that it contributes to your competitors is nearly irrelevant since everyone needs that infrastructure. If you're a publisher that wants to avoid the escalating costs of Adobe products, you probably lack the skills to contribute to open source alternatives and it doesn't make financial sense to acquire the talent to contribute. Not only is it expensive, but there is no guarantee that your competitors will do the same.

As for being a lone open source developer or development firm, that pretty much defies the point of open source. Without collaboration, there is very little reason to pursue open source.

For me the goal is 'how do we produce open source software and compensate the creators'. It's certainly worth casting a wider net than just "businesses", but there isn't a lot of funding otherwise, besides universities, and those aren't oriented towards providing and maintaining end-user friendly systems.

It’s frustrating. On the internet we have massive scale and instant distribution. Crowdfunding in theory could easily pay a living wage to all of the major open source developers.

Maybe it should be hidden like a platform tax. When you pay for a hardware device and/or a software platform that uses open source software, there could be a small tax that goes into an open source fund.

Who decides how to distribute the fund? How do the rules for that distribution get setup? How are disputes resolved?

IMHO one of the main problems of open source is that you cannot personally police the use of your project because you do not have the time or money to do so. So once it's open source someone can use bits and pieces of your intellectual property without ever letting you know, and how are you going to find out? This is true for example for obscure tricks relating to optimizations when dealing with OS interfacing code or with specific algorithm implementations. I have a few large code bases I have thought about open sourcing and the lack of solutions to these problems have kept me from doing it. Yes, I can use GPL, but how do I efficiently also license it for commercial use and how do I monitor the use without needing to pay lawyers to police all of it? If you deal with an industry with thousands of indie developers this becomes even more complicated.

This is the "copyright cop" model of software development. The idea is you make something attractive and then rely on social control mechanisms to punish people if they touch in ways you don't like. This business model is identical to proprietary models, and requires lawyers and all that, as you note, because you've created a system that incentivizes erstwhile customers to step outside the model that makes you money.

Another model is to make something attractive, give it away, and sell something else that goes well with it. Now customer interests are more aligned with yours.

RH sold for 11 digits doing the second.

This is basically a "loss leader" business model -- take a loss on selling milk, hoping that brings in customers to buy your cookies.

So in open source, there are some things you can do -- sell support (where the software is the thing that draws in the need for support). Second thing is sell a service that ties into the open source code. Third is have the core product open source, with paid add-ins. The paid add-ins is even more attractive if there is a third-party requirement that prevents the additional functionality from being open source (i.e., if you want to add Oracle database support to your backup code, you need to license [under NDA] a development kit from Oracle; or things like patented plugins for specific video streaming formats on a media app).

interesting. how does this work for a hardware product?

"rely on social control mechanisms to punish people if they touch in ways you don't like" - in the industry I'm dealing with people get upset by other people using open source in a certain way to profit from it, yet the customers keep buying the rip-off products anyway and the people behind those products keep profiting. so at least there, social control isn't delivering the desired result. you could argue that social control acts as a marketing tool for the original developer of the project (?). in the RH case, are you talking about selling subscriptions to complement the free / open product?

I've always thought that selling license exceptions could be a good business model: https://www.fsf.org/blogs/rms/selling-exceptions

Basically, your software is copyleft unless a user pays for an exception. I've thought that it may be a reasonable business to offer a service to owners of popular GitHub repos to somehow get started with this business model. Anyone who quits maintaining popular OSS in rage (as has happened a few times) stands to gain more by simply changing the license and then charging non-OSS users in the future.

Edit: Thanks for the comments explaining. I was unaware of the barriers to this path.

That's dual licensing. It's mostly relevant to software libraries or anything that can be included into another product but for end users it has no benefit at all.

This is not new. It's called dual-licensing. It's very hard to do for a number of reasons.

It means you have to CLA all contributions, which decreases the number of external contributions you get, as contributions are all taking someone elses work.

Depends on what you consider a business model.

How big? How many people get paid? What growth curve? What emphasis on revenue maximization?

Given my answers to those questions, ardour.org is doing extremely nicely as an open source business.

Based on someone else's answers, it might be viewed as a near failure.

MongoDB is valued around 15 billion dollars right now. You can argue that they are not really open source, due to their new license that is not OSI-approved. But it’s pretty close, and it’s something that aspiring open source businesses should consider. It’s basically “almost entirely open source except AWS can’t offer your product as a service.” To many people, that is just as good as open source, and if it makes the business model that much better, maybe it’s a good trade off.

And confluent/kafka w/4.5B. Not to mention Google themselves are making money from open sourcing containers, like tons of it.

They start this conversation saying "only redhat can be redhat", but then basically throw their hands up in the air because they can't describe all of open source as one business model. Different products & technologies require different business models.

I don't think it's surprising that a podcast named "on premises IT" is out of touch with a wide array of successful service based business models (I say this with love).

But AWS is offering their product as a service, isn't it?

No, AWS offers DocumentDB which is "MongoDB-compatible". In practice, it's incompatible enough that many people use MongoDB Atlas, which is the MongoDB-provided full managed database service for MongoDB.

Yes but I think that's why they changed their license wasn't it?

AWS had no MongoDB-as-a-Service before MongoDB Inc. changed their license.

Amazon can probably get volume discount, and sell with a nice margin to their gigantic customer base who will not care to reach for MongoDB cloud?

idk

Open source gives away value you could charge for. That makes it much more likely the business will fail. The only reason to base a business on open source is if the software can’t be used to deprive you of value (Facebook and Google’s strategy), or if you yourself need to exploit some pre-existing open source software, so you have no choice, or for weakish marketing reasons around vendor lock-in. Do it for any other reason and your business succeeded despite your choice.

Is there a transcript?

This is a very silly question. Open Source is a development methodology, not a business.

It's like saying "There's still no viable business model for science."

Just makes no sense. I've been making a living on Open Source code (now at FAANG) for over 30+ years. It's all about the code, someone else does the business (thank goodness, I'm terrible at that :-).

It's not that silly. Open source is actually a licensing model, not a development methodology. And the licensing implies that at least in theory anyone could get the licensed software at no cost. Given then "business" typically concerns money flowing from A to B, it is certainly not entirely obvious how one can build a business around a product whose theoretical cost is zero.

People manage to do this of course, which simply points out that real world economics doesn't follow theory that well.

I'm glad to see so many folks listening/watching! The On-Premise IT Roundtable selects a controversial premise to discuss on each episode, and it appears that this was a good one!

If you'd like to join in a future discussion, I'd love to have you join us. I'm @SFoskett on Twitter.

The dual license strong copyleft/commercial seems to be validated for software infrastructure (not necessarily products).

I've noticed it reduces support costs immensely, when your paying users are developers and they have unbridled access to the source alongside developer forums.

The related issue is if there is a closed source business model. Maybe only if its SaaS. I can't think of any packaged commercial software from new companies, only old established ones Adobe, MS, Oracle etc.

Is there a closed source one? There's only a handful of companies that capture the market. Content is currently a semi-viable business model, until it gets overtaken by autogenerated content

I’d throw Basecamp in as a successful open source company.

Basecamp itself is closed source, as were all of their previous products, but Rails is open source.

Oh yes there is: (A)GPL + dual licensing.

Those who are not happy with (A)GPL have to pay for other license.

Well. Does it need to be a business? This is an honest question.

I mean you can't work on something full time and have it not be a business unless you're already independently wealthy, so what you're really asking is "what if being able to work full-time on projects was something that only rich people could do?"

Hashicorp, Gitlab, Bitwarden, Mattermost, Automatic (WordPress), Discourse, Canonical, Red Hat...how many should I name? I’m surprised this discussion even took place.

I reaize that I’m reading into the title, I don’t have time to watch the whole thing. But I think the title is meant to provoke the kind of response I’m dishing out. Consider me provoked I guess.

Successful examples tend to be revenue models where what you pay for is support.

While that does technically generate revenue (and potentially lots of it) it is not generally applicable to many open source projects particularly those not large enough or foundational enough to even raise the interest of paid corporate support. At the moment that would leave donations as the rev stream and I guess that might work for some.

The other model that can work is one where you offer a basic open source product but then charge for a closed source "professional version". I guess, I wonder if that type of thing is is really open source in the end.

Obviously your list isn't intended to be all-inclusive (that's kind of the point), but Sidekiq and Sentry are two of my favorites.

Sentry isn't FOSS: https://blog.sentry.io/2019/11/06/relicensing-sentry

Zabbix too. As others have said, the proven business model is services (support, SaaS, certification, etc.), not the code per se. That said, it's harder to make services for open source games or office software.

Cloudera as well.

Keep down-voting: it matches the idea that Open Source is for "playboys", people who aren't immediately dependent on or motivated by earning an income (i.e. in general it's for independently wealthy, white men).

If so, that group of people won't have such a business motive.