Comment by jillesvangurp
3 hours ago
I always wonder why people bother with providing source under a source available license. It makes outside contributions a lot less likely. Your active community of people working on the code base effectively becomes your employees.
There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing. Including free usage and distribution of the work they did. It's not likely to be helpful.
My attitude to source available products is the same as to proprietary products. I tend to limit my dependency on those. Companies have short life spans. Many OSS projects I use have a history of surviving the implosion of companies that once actively contributed to them. Developer communities are much more resilient than companies. Source unavailable effectively becomes source unavailable when companies fail. Especially VC funded companies are kind of engineered (by VCs) to fail fast. So, it's just not a great basis for making a long term commitment.
If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license. Somebody could take over the project or fork it or even create a new company around it. Some of the original developers would probably show up. A project like that is resilient against that. And projects like that have active contributors outside of the corporate context that provide lots of contributions. Because of the license. You don't get that without a good OSS license. I judge software projects by the quality of their development communities. It needs to have diversity, a good mix of people that know what they are doing, and a broad enough user community that the project is likely to be supported in perpetuity.
Shared source provides only the illusion of that. Depending on them is risky. And that risk is rarely offset by quality. Of course people use proprietary software for some things. And that's fine. I'm no different. But most of the stuff I care about is OSS.
Counterpoint: I’ve often wished the proprietary software I use was source-available so that I could fix bugs for myself.
The idea of doing free work for a company does feel weird. But when some bug is really getting on my nerves, being able to fix it and not have to deal with it anymore is a huge benefit!
I don't mind the idea of contributing back with fixes on a sources available project. Especially in the context of work.
It does however make it unlikely for me to pick and use the project in the first place.
And definitely not a fan of living through the "era" of open source term washing, post truth, tech influencers and their echo chambers.
DHH says Y, now dozens of impressionable Xs will start parroting the same thing.
> I always wonder why people bother with providing source under a source available license. [..] There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
20 years ago, I used to consult with Fortune 500 companies that run Oracle and IBM products (web servers and Java frameworks).
These are distributed as enterprise binaries. It's common to face _at least_ one or two weird errors in production. Then you have to raise a ticket to support.
Would you like to know how it is discussing a binary-obfuscated error with Customer support? And then after few weeks being assigned to a newly joined fresher? And so on and on, where every person or layer every week says "you're doing it wrong" and you have to restart your proofing and explanation process from scratch?
Hint: After few weeks/months of this (or after 4 times of restarting your proofing process), you start questioning your sanity and life choices.
In those days, all I wished for is just "source-available", so that I can just debug myself what is going on and provide a concise bug report, instead of talking to support.
The weird part is, I'm pretty sure, on the other side, Oracle/IBM also LOST money in that same process. They had to hire an army of people. It was lose-lose on both sides.
Source-available means customers of that software can perform debugging themselves and file pretty good support tickets.
If you are an enterprise today, you would absolutely consider make it source-available to save on your own costs.
The BUSL license requires shifting to an open-source license no later than 4 years after publication. I'd be happy to contribute to a BUSL-licensed project knowing my contributions will shift to an MIT license within 4 years.
And the original authors don't have to worry as much about Amazon eating their lunch.
Good for you; you seem like a trusting person. I'd recommend against spending your time on that. Or at least try to get paid for it.
I tend walk away from anything with a shared source license. I don't invest my time in it. I don't finish reading the README. It's an instant red flag.
The whole point of having a license is that you don't have to rely on trust. It's right there in the license. There's no way to weasel out of it.
https://mariadb.com/bsl11/
"Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License" ... "To specify as the Change License the GPL Version 2.0 or any later version, or a license that is compatible with GPL Version 2.0 or a later version, where “compatible” means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version"
While that is certainly better, the original point still stands. If the company goes bust the latest source code will only be open source after 4 years. By that time other software has likely taken over the need in the first place, because not having that need fulfilled for 4 years is mostly not reasonable. And older versions often don't have compatibility with new versions either.
Maybe that's the whole point. Entities which rely on the product enough to propose contributions are more likely to be paying customers who really need to have a given feature available?
People seem to complain that they are burnt out by open source quite often so not sure that there are that many contributions apart from a couple projects.
It may also protect a project against business vultures. If you are trying to monetize your project but someone richer than you forks it and offer it for free, what can you do?
Yet, by being source available, the code is still auditable. It is easier for people to understand how the software works. And nowadays you can fine tune an LLM over it I guess...
Seems that is might also be a valid perspective? You can probably have a kind of bus clause so that source code does not become abandoned?
In the case of Fizzy, the app that 37signals has made “source available”, the real motivation for publishing is form of advertising for Ruby on Rails.
DHH is on a mission to show that you can write great software with way less bullshit than is in vogue.
This code base is sparkling in its design. No build frontend, server side rendered templates, minimal js used primarily to drive interactivity, extremely simple models, jobs, and controllers.
It has < 3000 lines of js with incredibly rich interaction design, when was the last time you saw that?
>minimal js used primarily to drive interactivity
Damn weirdos. Next you're going to tell me that you can deploy it without k8s or even a container?! /s
It's a way for SaaSy companies to do business in Europe.
> I always wonder why people bother with providing source under a source available license.
I treat it as "business plus", not "FOSS minus". And of course, some source-available licenses convert to FOSS over time.
> Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Funny, that's the same complaint FOSS companies have about AWS free-riding off their hard work and then competing. They switch to source-available licenses because a FOSS license allows flush FAANGs to exploit them.
You can switch to a copyleft-FOSS license that requires users like AWS to effectively contribute back too. And this way you stay "open source".