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