I have always held the notion that Open Source Is Not A Business Model; just because you build it does not mean that you are entitled to money, especially if you willingly give it out for free.

Just like any startup, you must find product market fit and generate revenue. It's heartening to see the same philosophy in OSS as well. Treat it like any other commercial product, not as something special.

Plenty of non-opensource developers also have no idea how to act on GitHub. Some people are great. But I’ve also gotten more than my share of entitled “drop everything and fix this now” issues opened over the years. “It’s causing an outage!”. It’s like I’m a wayward junior engineer who needs to be brought in line. Do you appreciate my work or not, idiots? You can’t have it both ways. It’s kind of surreal.

The fact is that if those critical projects folded, the big companies would just take over the software 90% of the time - which is supposed to be a positive feature of open source. The other 10% of the time, the reason the software was profitable for the big company is because people were working on it for free.

Maybe the solution is to stop writing all of this corporate software for free, or at least AGPL it.

Many open source projects only have donations based funding, no way for be to download an actual software product that I am invoiced and pay for.

Package the binaries and sell them to me, I will happily pay with company money...

They do exist.

In the end the GPL resolves these issues and enforces stuff. Obviously most companies don't want that for different reasons.

Without GPL, as a company you take the code and if neccessary at some point, you employ somebody to further develop it in house (when maintainer gives up or something).

Why pay and share and give that advantage to your competitors?

The key to open source is when governments develop policies for using open source instead of paying licenses for proprietary software and maybe pressure from customers to companies which use open source software.

But average people don't know and don't care at all about open source ... :(

> Why pay and share and give that advantage to your competitors?

What companies have actually found is that collaborating on OSS infrastructure projects is extremely beneficial, essentially outsourcing some of the work to focus more on their unique selling points. This has happened more or less the same for GPL and more permissively-licensed projects.

Linux is the top example of a GPL project that has nurtured this type of commercial collaboration. Clang&LLVM is the top example of a non-GPL project which has achieved the same. Kubernetes is probably the second contender, and also non-GPL.

Ultimately I believe the GPL was an important step forward in getting companies to realize this type of business model can work. But it is much more of a hindrance today, since it brings about an awful lot of bureaucracy and ceremony when you need to combine it with proprietary code. So, I expect most collaborative OSS projects will continue to stay away from the GPL moving forward.

I think there are examples of this in FreeBSD: after a company effectively forked the project, FreeBSD kept rolling forward—with bug fixes, updated drivers, etc. The company(s) had to maintain larger and larger internal diffs to get all of these improvements.

At some point they tended to just start giving back whatever wasn't their secret sauce and keep their own code as self-contained as possible. I think a popular workflow nowadays is to just track -CURRENT [1], and maybe branch when they cut a release of their own product.

[1] https://klarasystems.com/articles/evaluating-freebsd-current...

Linux, as you say, does provide an example of mass collaboration happening with a GPL license but it's unique in so many ways that I'm not sure it provides a very useful study point.

Forcing derivatives to be open source seems on the surface like a good way to provide a project with some protection against market forces while also helping to keep knowledge and development accessible to humanity.

Genuinely curious about pitfalls and other options.

So you're right that the GPL provides some safeguards about code being reworked into a proprietary product and kept closed. But a lot of the industry has come to see that the flexibility associated with more permissive licenses can outweigh that. (And there's been a general shift towards more permissive licensing. Most everything in the cloud-native open source space is permissively licensed. I believe the CNCF even requires this for projects under its umbrella.)

Do you also believe Clang would have been in a better shape without the collaboration of all major compiler vendors?

Now that Apple is focused on Swift, and Google key devs went to play with Carbon, the amount of contributions to ISO C++ compliance has decresead and clang has an honourable 3rd place, between VC++, GCC and clang.

On the other hand, the world of C++ compilers is much bigger than only three compilers, so there are plenty more beyond the 3rd place.

You can do that with GPL too.

> Why pay and share and give that advantage to your competitors?

this is the essence of the issue;

we gotta understand why society is often seen through such adversarial lenses?

this question ("why adversarial thinking?") though asked rhetorically, has a good answer which is important to understand, as well as a bad answer which is also important to understand.

I've chosen to consider this question without fully answering; but by thinking about the notion of 'identity', what makes me be in this or in that group such that 'who are our competitors?' is not so simple to answer.

This is a statement that is (I assume) technically true. It's also quite misleading. And it carries through to the discussion of serendipitous and reliance developer models.

Sure, if you count projects on Github, I assume the vast majority aren't clearly worked on by someone paid as a developer to do so. But if you filter by widely-used and commercially-interesting it's a different story.

>Reliant open source is the majority of financed projects by far, and has yielded projects like Homebrew, curl, OpenSSL, Vue.js, rclone, Caddy, and countless others.

OpenSSL, for one, is a terrible example. As came out with Heartbleed, the OpenSSL developers were collecting something like $5K/year in donations.

But those are exactly the same people who would be developing their software if they brought the work in-house.

Off topic, but doesn't the success of open source software torpedo the claims by many companies that you need on-site collaboration for this kind of work? Even here on HN you see many comments going on about magical conversations in hallways, yada yada. But in reality, many of the software projects that millions use every day were built and are currently maintained by teams who have not only never met, but probably don't even know what the other team members look like.

I won't comment on overall risk of third party open source vs proprietary. But it is obviously true that open source has an advantage in that there's no problem that could arise that can't in principle be solved in-house.

When picking an open source library from the internet, you can immediately apply a strong filter: select codes which already have an active community and ongoing development, they already do something like what they say on the tin. You only see projects that have won a couple times.

Open source communities also draw in people who have the specific problem that their project solves. The need to have meetings to get everyone aligned on what the actual objective is is reduced, they showed up because they have the problem.

The corporate project is, at best, trying to solve an internal company problem (so they can at least have meetings with the interested parties and maybe even dogfood a bit). Or, it might have some totally imaginary customers that sales and management think exist out there somewhere, so let’s get together and brainstorm about what they might need.

One point I want to emphasize is to think long-term. If you want to build something great that is solid, it will be hard and it will take years. You are also building trust with your user base and this takes a lot of time too. So you need to ensure that you won't be burned out by your project, both for you and for your users.

On the negative side of things, I see several OSS projects that try to oversell (consciously or not//too much marketing) their project to speed up the growth, this makes all the more important the assessment of an OSS project before putting it in production.

My rule of thumb - if I really like a project and use it on everyday basis, I always pay back either by buying a license or by subscribing to monthly donations. This simple rule keeps authors afloat.

BTW, I make monthly donations to Caddy webserver because parts of our business are reliant on it.

"One gives freely, yet grows all the richer; another withholds what he should give, and only suffers want. Whoever brings blessing will be enriched, and one who waters will himself be watered."

First, as stated in this article, the problem is the asymmetry. Normally you need to pay to use a service and the service provider needs money in order to continue. But in software development, the developer needs money to continue but the user doesn't need to pay to use it.

This problem of asymmetry has already been solved all around the world. The citizens in a country can use a lot of services because they pay tax. This works because the government patches the asymmetry by filling in the gap of the missing money flow, using money that they collect from everyone who wants to be a part of this system.

There is just one difference with software development: software is global, so we can't use any existing tax system.

What we need is a global system that collects money from everyone who wants to participate in the system. The money could be collected by the software developers, similarly to how some of them already accept donations. When they get a payment, they register it in a global database that keeps track of who has paid. This database can then be used by anyone who wants to enforce this system by requiring that people have paid a software developer in order to be able to do certain things. The question then is how many people would be willing to make this requirement.

https://github.com/fossjobs/fossjobs/wiki/resources#grants

You are suggesting to "create from thin air" a new entity that will almost certainly do all the bad parts, and may or may not do the positive parts, and has control to gate-keep for whatever reasons.

The issue is that policy makers haven't seen the value in the same way (yet).

- For any requirements to be a part of the system, you can't pay a developer in one country and be accepted as part of the system in another country.

- Developers in one country will not get money from users in another country.

- Why wait for policy makers? The sooner we get something working the better.

There would have to be a list of approved developers you can pay because otherwise people could just pay themselves and register that payment in the system.

I can think of two ways to update this list:

- Some trusted maintainers of the system can add developers who want to be added, making sure they are real developers who have already done real work.

- People could use their money to vote for developers to be added.

Doesn’t that mean he needs users? And especially corporate users? The more he has the more $ he makes

A lot of open-source software is not developed openly or accepting contributions, it's just published as a tarball somewhere. There is no volunteer work, there is no fostering of a community. Some projects explicitly refuse outside contributions, like SQLite, but are still open-source (= license). In contrast, some software is developed in a communal fashion but is open-core, BSL, or at least partly proprietary.

In this article, every time the author says something about "open source projects", they mean community-developed projects.

Maybe the word "project" does enough work here, and everyone understands the difference between "open source software" (= the code, under open license) and "open source project" (= community-developed openly-maintained software)?

and while there are some tradeoffs, the advantages (I hope) are overwhelmingly in favor of open collaboration.

this is so important that the entirety of science (real (old-?)world science) hinges on this open access and 'public' collaboration; there's less of this kind of science now than before.... (see also: ongoing scientific publishing revolt)

but I digress, none of this to say that there's no problems, but the problems are more social (cultural and economic) than they're technical.

the points are: collaborative models of software development are technically superior; they make better software.

the 'problem' of how to "make this into a business" cannot be solved, we must re-evaluate wtf a 'business' even means. we need to question why do 'things' need to be 'businesses'.

Isn't this, in the light of some European legislation-to-be that could make an unaware maintainer liable because some other company used their code, a win-win? Either pay or don't use.

Consumers care about whether software works for their needs, they don't care whether it's proprietary or open source. And often there's also the factor of price.

The problem with FOSS is that too few developers have the willingness to ask for money directly, like selling binaries instead of sponsorships/donations which have terrible conversion rates. https://piero.dev/2023/02/foss-funding-chapter-2-binaries/

Other monetization methods proposed in the article just don't scale, aside from the running a SaaS business which is 100% a great way to fund work.

While I agree with you, this leads to confusion: the naive users from your first sentence then say, that they thought it is open source, why the author asks for money?

This can be seen for example with android apps, that have GPL-licensed sources on Github, free binaries in F-droid and paid binaries in Google Apps Store. So basically the author is charging only a convenience fee, but this confusion still arises.

If a user buys a binary, the seller should expect demands for work or a refund. But people don't expect refunds for donations. And it takes a lot of money to attach strings to a donation.

It can be done. Some companies do things along these lines. But, especially at the consumer level, that introduces a lot of adoption friction. I imagine most users will close the page and move on once they saw they needed to build a binary themselves to try something out for free.

Previous discussion: https://news.ycombinator.com/item?id=30706650 (44 comments)

Free for private and non-commercial use. $$ per seat for commercial use.

This can still be completely open source.

Software can be MIT + commercial. That's still perfectly open source.

https://opensource.org/osd

So does OSI have complete authority over the definition of OS?

Does their definition restrict dual licenses?

Have they thought maybe creating more lucrative OS models/standards would help their cause?

But "Free for private use, pay for commercial use" is a restriction.

If you pay for it, you can use it.

If you don't pay for it, you're restricted from using it. -- If there were no restrictions for not paying, then you'd just not pay.

Yes.

> Does their definition restrict dual licenses?

No.

I agree, but this is only putting it mildly. To make an analogy, does the United States get to decide what the borders of the United States are? No; there is (AFAIK) no international law which has delegated that right to the US Government. But most of the international community accepts that, if the US says that someplace is a part of the US, it is. In the same way, OSI and its Open Source Definition decides what is and is not Open Source.

Except GNU and OSI are in conflict?

> No

Then you can have an OS license with a business license or even an FU license (arbitrarily horrible license).

Not at all. The various GPL licenses are OSI-approved. Though the GPL may restrict your ability to offer an open core version of the project.

I think what you're missing is that if a project is licensed under an open source license, you can dual license it--including only offering some components under the proprietary license, i.e. open core--but the existence of that dual license doesn't take away any of the rights associated with the open source license on the open source portion of the codebase.

But dual license doesn't mean that the use of an open source codebase can can be carved up into allowable uses under the open source license and allowable uses under a proprietary license.

> if a project is licensed under an open source license, you can dual license it

Confirming this is all I am after.

I wasn't talking about carving anything up, though that sounds fun.

The FSF (including GNU) and OSI have their own histories, missions, and philosophies (to some degree although there's no real conflict about what open source/free software are). Yes, there are politics around both organizations but that's mostly inside baseball from the perspective of the average software consumer. There are any number of other non-profits in the open source space that also do their own various things.

And, yes, you can dual license. But understand that if one of the licenses is, say, MIT, a commercial entity can still use the software without paying no matter what the other license says. i.e. you can't use the second license to take away rights from the first license.

It's a simple IF statement.

IF commercial then $cash, else $mit.

A dual license doesn't mean they can choose if they already are what they are, ie for profit.

A dual license is not IF/THEN/ELSE, it's pick $mit or $commercial--your call. If I pick $mit, no obligation to pay. You can not use $mit at all. But if you use it whether as part of a dual license model or otherwise, you don't get to rewrite it. Of course, you don't need to be open source at all which is what I usually tell clients who want their software to be "open source" for marketing purposes but get around some of the business model challenges.

Here's the fairly canonical MySQL example of a dual license: "Oracle uses a dual licensing model for MySQL to meet the needs of its consumers. Oracle offers MySQL under a proprietary (OEM style) license for licensees who want to create and commercially distribute proprietary derivative works incorporating MySQL without revealing the underlying source code and do not wish to be subject to other restrictions and obligations of the GPL. Additionally, Oracle licenses MySQL under the GPL for licensees who simply want to use the software or who want to incorporate MySQL into a product to be later distributed likewise under the GPL."

(Note that Oracle owns the MySQL copyrights. They perhaps couldn't otherwise do this unless subject to some restrictions. You can also just use MySQL without contacting Oracle.)

But what you're proposing, the software doesn't have an MIT license. It has MIT license verbiage coupled to other license language that forbids free commercial use. It's not a dual license. It's a new, different, and non-open source license. (Which is fine but your software isn't then open source.)

So from the IF/THEN/ELSE perspective your variety of dual licensing is not possible in the sense of a rider on an approved open source software license.

(Of course, that assuming you can even define much less enforce "commercial." Creative Commons basically gave up.)

No, it can be both. As the originator of the work, you are free to grant licenses based on qualifications. It's done all the time. I can't choose Adobe's student licence because I'm not a student.

So is this what's held back dual licensing and OS authors profiting? If the buyer could just freely choose of course it's broken.

(edit)

Just to add, even Oracle's license isn't completely free for the user to choose. Depending on the plans or policies of the buyer, they are restricted to their choices. So an IF statement exists.

If that's not acceptable, don't release it under an open source license. Like Adobe's proprietary software, you can release it as free for educational or non-profit use only under your own license. Can be hard to define and hard to enforce but that's your problem.

Do open source or don't do open source. I don't care. But it's tiresome to have people who want the "open source brand" but don't actually want to release open source software. Most of the actual advantages of open source don't accrue to tightly controlled products anyway.

And, yes, I don't consider it a problem but dual licensing, at least outside of open core (which has its own problems), is fairly useless in the general case. So in that sense it's broken. But that is open source working as intended.

Take adobe student discount. They license at a discount if you're a student.

The rights holder can restrict who gets what license. If you're trying to be able to say "released under OSI approved rubber stamped" then sure, maybe duel licensing is not ok. But you don't need the two licenses to be in agreement, and if you're not a student you don't legally get the student discount just by identifying as one.

So you could easily and legally do, free for not-for-profit, $50 otherwise with source.

No, you are wrong here. Maybe it's semantics or whatever but a rights owner can impose restrictions based on conditions.

Yes. But what we seem to be going in circles on is that IF the rights holder wants to release the software under an OSI-approved license, they don't get to change that license, which is what you're doing if you want to say the software is only available under that license to some subset of users. Of course, they have the right simply not to use an OSI-approved license at all. But OSI-approved licenses all say you CAN'T impose certain restrictions if you're going to use them.

What they CAN do is to dual license the software under an all rights reserved license and their own "source available" license (for eligible users). So long as an OSI-approved license isn't involved, they can do anything they're legally permitted to. If you want usage restrictions, just don't use an OSI-approved license. It's pretty simple and the result is effectively the same.

They can even just cut and paste the MIT license and add a usage restriction clause. They just can't call it--and it isn't--the MIT license anymore.

No, they aren’t. GNU completely accepts the OSI definition of Open Source.

> Then you can have an OS license with a business license or even an FU license (arbitrarily horrible license).

“Dual licensing” is an OR operation, not an AND.

Can you combine that with what you said earlier? I read it as a counter argument to dual licensing. Now you seem to be perfectly OK with it.

For example:

If you plan on billing a client for this software or claiming it as an expense for your business, this software is provided with source for a one time fee of $50 with future upgrades provided at $25, after which will be under the MIT license. Otherwise this software is provided free of charge under the MIT license.

Also, having contingencies on what someone “plans” to to seems fragile. Suppose I don’t plan to bill a client for this software, nor claiming it as an expense. Therefore, I acquire a copy of this software, licensed only under MIT. Suppose then that I change my mind. I should be completely free to bill clients for the software, since the MIT license freely allows me to do so. Right?

Either I am free to do that, or the software I acquired was not actually licensed under the MIT license at all, but had added conditions. And in the latter case, it was not actually Open Source.

If I am looking to update a site for a client and see software that I need, and the author is asking for $$ for commercial use, and the client is willing to pay, I will respect that.

Presumption of conflict and safeguards against it, or just giving up, has caused a lot of great projects to be abandoned in my opinion.

If you go to github and the source is already there, the source is open. Any definition of open source beyond that is political and legal. And with that source being open, you could just copy it without even reading the license.

Most businesses make decisions based on $$. And they are happy to buy anything that helps their business. It's the cost of doing business. Think shopify apps. Most of those apps could be open source even if the only way to install them instantly was buying them through the app site. So having a paid for app for an open source project would be a great way get paid (or fund raise). Kind of like Linux being packaged for sale on the shelves of bookstores. That wasn't free, but people would buy it.

For business transactions, adding virtues and missions and meaning doesn't really come into play unless the marketing department has some plans that coincide with whatever virtues being sold. If the business is small, then maybe the founder. But again, it's not directly relevant to the product and use of it. Activism can be distracting when all you want to do is take care of business.

"If you agree with me, help me (or don't, you can still have it)" is a tougher sell compared to "this is $100, thank you, btw i believe in this" especially to the person/entity that could easily afford it (and pays for proprietary licenses already).

It's clear that if more OSS projects did better at making themselves money, they'd survive and maybe afford the price of continuing to improve and get better. This is in the interest of open source. I never took os to mean non-profit, although it has been synonymous with not-able-to-profit for quite some time now.

If OSI is an authority, maybe it would be in the best interest of "the community" if more help (in the form of guidelines and best practices) was provided in recouping development costs.

How do you expect to make money if no one pays you for the commercial license because you don't enforce it?

Many of these "open source" projects don't need licensing because no one is using because they don't have anyone to license too. You can't pay a commercial user to use this code even if you wanted to. These projects are akin to the people that start side businesses but spend all the time and money registering for an LLC and SEO advertising but have no work or customers for their side business but appear busy day and night working on their hustle and reports losses on their income tax and pay the accountant extra to setup tax shelters for imaginary income that aren't coming but that's what they saw someone else do and thus they need this and that tax service as well.

One could arguing enforcing open source is harder to afford specifically because you aren't making money off of it.

However, while I disagree with the statement, I agree with the sentiment. Most open-source projects' authors don't care about their users, at least not as much as in the beginning, probably because of the said incentive mismatch.

Sure, but getting outsiders to use the project may or may not be that reason. There are plenty of projects that publish for reasons other than to be popular.

I'm my own best customer. I write software that I want to use, and use it.

Writing my modules as full-fat, generic, supported, MIT-licensed libraries, means that their Quality is top-notch. I don't like to worry about my dependencies, and I like to be able to reuse them, if possible.

It also helps people to take me seriously, although that seems to be a rather optimistic approach. In my experience, almost no one ever looks at my work, and they usually just attack me, because I'm old, and come across as an "OK Boomer," whatever that means to you.

> because it means they need to assume full responsibility when relying on software in their multi-million-dollar business that was probably developed by a tired young parent or college student who didn't get enough sleep.

As the comedian says, "So, what's your point?"

They make a ton of money, from someone else's work. They don't give a damn about the other person, except as someone to bitch to, when they feel cranky. As long as the license doesn't say they need to pay, or open their own work, then why should they care?

I was just looking at adding a feature to my app for converting long/lat to timezones. This seems straightforward, until you look at a timezone map[0].

It's entirely possible to create my own mapping program, by splicing together some geo points, and a table, but I was wondering what was out there.

There's a number of choices, but they tend to want eye-watering prices. The open source stuff is basically an open toolbox.

I'll probably be rolling my own, into a Swift package. I may open-source it, just to be a dick, but I don't really want to be supporting a popular package.

[0] https://commons.wikimedia.org/wiki/File:World_Time_Zones_Map...

I decided to make it a server, instead of a device library, because I can just run it once on the source data, that way, and I don't need to keep running it.

In any case, it's PHP and LAMP, so no one on this forum will like it, which suits me just fine. Figured I'd post it, anyway, for Ss and Gs.

[0] https://github.com/LittleGreenViper/LGV_TZ_Lookup

I never wanted your Nodejs and SPAs. You hyped it up and then it was forced on me by the industry.