> I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear.

I have no problems with open source maintainers charging for software, but I think the bigger problem is people having incorrect expectations of the open source model.

The main point of the open source is that if the software isn't doing what you need, then you can fix it yourself. Developers often act so helpless when it comes to dealing with bugs or missing features in their open source dependencies. Obviously that involves work, as you can't rely on some third party to maintain the software (or at least your fork) for you. On the other hand, you can't always rely on the vendor of proprietary software either. But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.

In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.

As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".

> But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.

Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature. Very rarely will a company say there is no price high enough for them to add a feature. This is so common that the pricing is pretty much standardised, nearly every company I've worked for when adding features for customers charge the same 1 thousand euros per developer day of work.

Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.

> In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.

The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.

> As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".

Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.

> Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature.

You can also almost always pay for someone to maintain a custom fork for you, if you don't want to do it yourself.

At that point for companies they're maintianing the fork. With third party where you paid for a feature, you don't pay for maintiance.

> Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork.

I think I was unclear. My point was not that you could merge your own fork into the upstream, it's that you could merge any changes from upstream into your own fork. My point is that yes, you are maintaining your own fork, and while maintaining a fork is work, it is a valuable option that people forget about and yet is one of the key motivations behind open source to begin with.

> With third-party corporate code, you can nearly always pay for them to add a feature.

I have seen developers refuse to fix bugs in software that costs literally millions of USD in licensing. But beyond that, there is always the possibility that the software ends up with no maintainer, and even for the source code to be lost completely. Open source hedges against that risk.

> Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.

That's good. You'll see no objections from me. I don't really care much personally how people choose to license their software. While I have mentioned some of the benefits of open source, my point is not that "open source is better" but it's that the problems people have with open source come more from bad expectations of how that model should work in the marketplace rather than a problem with open source itself.

> The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.

There is no inherent obligation to maintain projects you have released as open source. The code is already out there. If people want to modify it to fix bugs or add features, they are welcome to do so. They can even share their changes with the world! The only maintenance costs in open source are those costs the maintainers choose to take on. If a maintainer chooses to update their software, then each of those versions is a release of open source code, and the guideline still applies. If you make a change in an open source project, the cost of that change should already be accounted for before you release it.

> Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.

That's true, but doesn't undermine my point. The point is that the pursuit of status plays a role in why people contribute to open source (and why they put up with onerous user requests). They (consciously or not) hope that by contributing they will be seen as cool and smart by others (or at least others within a given clique).

The problem with paid proprietary code is that it almost inevitably devolves into a bloated mess of haphazard features being tacked on year after year by contractors who don't care about how hard it is to maintain, and don't even care if it works well because they don't need the code themselves, and the people buying the code don't use it, because they're buying it on behalf of a company and the people who actually use it just have to suffer through it.

I think the one thing that would help open source more than anything else is if we outlawed contracts where the employer owns all copywritable material created by the employee.

I would say that problem exists in open source too.