How to support open-source software and stay sane (2019)
nature.com
nature.com
As somebody that runs a semi-popular Open Source project[0], I am very aware of the painstaking task of taking a "hacky script on my machine" and turning it into something public that others can not only use, but trust enough to _depend_ on too.
Here is a rough checklist of tasks that come to mind:
- Write a Readme with a description of what the project is (help Google index it for future search)
- Publish a Docker image that can build the whole project and produce a binary or run the server (this is a massive PITA to get setup -- once you do this, setting up CI becomes very easy)
- Ideally there is a Docker image with a small POC app too (which is often more useful that docs are imo)
- Add a license to the repo and, if you really want people to trust it, add license headers to every file (I see _so many_ projects without even a LICENSE file. Without this, it's illegal to use the code at all!)
Beyond all of that, Docs help a lot too, as does a "legit" looking website, but you can get away with pretty crappy docs if you do all of the above.
Depends on your audience, I suspect. When evaluating something for use, the first thing I look at are the docs. No docs, or just videos pretending to be documentation makes it super easy to skip and move on to the next possibility. Crappy docs means I only come back to it if everything else is worse.
Another recommendation: Limit your dependencies to what is strictly necessary.
In what jurisdiction or country?
I won't argue for a particular license, but you should have one. I personally won't touch a project without a license as I usually aim to monetize my work somehow and don't want a potential legal headache.
A license just allows you to use the content/code under specific conditions.
Else you just are not allowed to use it.
Let us consider another software project at Berkeley: BSD UNIX. BSD was a research project, a vehicle for groups to do operating system research, an environment for the development of modern relational databases, and the tools that it helped introduce have scaled through multiple orders of magnitude of data set size and through many different hardware architectures. It was done by a combination of professors who obtained funding and crazy grad students who lived and breathed UNIX.
Eventually, the primary funder felt the project had reached its impact limit and reduced funding https://www.tech-insider.org/unix/research/1992/0622.html but the reality is that all this open source stuff happened before and will happen again. The government funding agencies have a messed up incentive system that funds primarily the "sexy" stuff and only around the time when it's producing the "sexy" publications. For example, one of the most important things that kept BSD going was Ingres (oh look, berkeley CS still hosts a copy from 1989: http://s2k-ftp.cs.berkeley.edu/ingres/vax-bsd/)
The UNIX tools I've used for over 30 years have scaled to every IO system I've worked with until I hit multiple-terabytes and moved to parallel computing. Even today, you can pump terabytes through pipes and if you have enough space, you can sort enormous files.
Actually, some bio software also qualifies. AMBER has been around since the 70s and is still a competitive molecular dynamics code that runs on the largest supercomputers and fastest GPUs.
I've concluded that the best source for longterm funding is to convince some billionaire that bio software is important, and then get enough funding to fund an ongoing staff that maintains the software and supports the community, and spinning off a commercial company that handles the enterprise integrations.
Dangle the carrot and let working people make a living, but force them to give back and prevent them from building closed source proprietary empires fueled by vendor lock-in.
There is a certain type of software, for example professional tools use by non-programmers - graphic editors - where traditional open source models, support contract or volunteer developers, can't work. If you won't be able to charge for copy, such software will never be written in an open variant.
I'm less of a fan of another license that's gaining popularity too, the "Server-Side Public License" (SSPL)[1], with projects like Airbyte and MongoDB because it doesn't have the "time bomb" aspect that BSL has. If there was a license that were in the middle between the two (SSPL but w/ a time bomb) I'd be pretty stoked.
Until then though, we'll just have to live with custom "Additional Use Grants" in BSL to carve out who can use it.
0: https://mariadb.com/bsl-faq-mariadb/
1: https://www.mongodb.com/licensing/server-side-public-license...
disclosure: I have a repo using the SSPL license
What I would like is to take the MariaDB 4 year old source and release my own database with better features, then compete in the market place with MariaDB, and have my own commercial exclusivity period, as I have explained elsewhere in the thread: https://news.ycombinator.com/item?id=32339945
To use the BSL in the sense I am referring here, the Change license must be BSL itself, with flexibility to allow a new change date, at the new developer's discretion, no longer than a set limit (4 years for BSL). If want to make the code free-beer, I set the change date to be the same as the release date, but the next day every other developer has the option to fork my BSL code and release their own BSL time-bombed version for up to 4 years and make money of it. Users who don't want that can take my code and enjoy all the freedoms that GPL would grant. [1]
Otherwise, if my only option on the Change date is GPL, which is very restrictive to me as a developer, I have zero incentive to work on certain types of free software that can't make money off support.
In a sense, a recursive BSL is freer than GPL, because I grant my users all the freedoms of GPL but additionally the freedom to create their own timed-bombed commercial release, i.e., to restrict the freedom of others with their own releases. The end users then have to option to use my original free-beer version, or pay for a better feature set, which itself is guaranteed to become free beer in a number of years. This incentive structure ensures a steady revenue stream for the developers as long as they create new features which are desired, but the revenue stops if they try to rely on vendor lock-in.
[1] (of course to do this recursive-style licensing one would need to modify BSL to grant the actual freedoms to run the code, distribute etc., the current text lacks this and relies on an external open source change license after the Change date).
That's contradictory by definition; such a license would not be Open Source. (With care, the three-years-later version could be Open Source, at which point people could build on that.)
> limited exclusivity period for the author during which they can charge for the software
It didn't say "support for the software" (and in any case anyone can provide support for the software).
After the time-bomb, it's undeniably open source: users have all the freedoms granted by open source and they have the option to release their derived version with a zero days time bomb, effectively equivalent in all respects to GPL. What GPL does not grant, and such a license would, is the ability to create a non-zero commercial exclusivity period, during which the software reverts to commercial-with-source-available status.
There are many ways that can be done, and authors are free to pick whichever business model works for them, depending on the type of software.
If it's a web service, build a commercial SaaS around it, and make sure that you're the first and best option for users.
If it's a desktop app, offer commercial extensions that enhance the core product. Or serve binaries behind a pay-what-you-wish paywall.
If neither of those are a good fit, premium support, merchandise and ultimately donations might be an option.
Why play the business game in nightmare mode?
Leverage is real, folks, i.e., I can withhold my software if you don't pay up.
Because some of us actually believe that it's unethical to release software to users that they are not 100% free to use and modify in any conceivable way.
Too many people today are hung up on "open source" or "free software" as a marketing bullet point. It's actually a philosophy and ideology, and the software licenses that came out of it are side effects.
But I can't modify Coca-Cola or KFC's eleven herbs and spices either.
It's called intellectual property, and it's undergirded economies both West and East since ancient times.
Intellectual property is a fiction. It is an abstraction invented whole cloth be legislative bodies to protect specific industries.
The extremist stance "free as in beer from day 1" is an ideology that, it should have become clear by now, is actually hurting the freedom of the public at large, who is pushed into proprietary cages set up by ruthless profit-maximizing businesses. There should be a better way where developers are paid, high quality software gets written, and users are free. There is nothing fundamental preventing such a world to exist.
Nothing except human nature. Ethics, business ethics particularly, is empirical. Usury was a bad word for most of human history. Now we just call it financing.
If only for forward progress's sake, one should accommodate human nature, not catechize it.
And what if neither of those are a good fit? Will you concede that there is a real world out there where open source software competes with proprietary and closed source systems? And that you cannot compete with corporations eating passion alone? That you have to have a monetization system in place that can generate at least a non-negligible fraction of what the closed source competitor can?
If you don't agree with that philosophy then writing OSS is not for you, and that's OK. Most users unfortunately won't mind using software that doesn't give them these freedoms, and the internet at large is evidence of that. Some of us will choose not to use proprietary software, but if your main goal is to grow a business, you likely won't notice a small portion of these potential missing sales.
What I'm pointing out is that we could imagine a happy compromise where 99% of the goals of free software are achieved, that would not only allow developers to make a comfortable living, but also benefit the vast majority of people who use software without understanding technical complexities.
If the software:
- has source available, and anyone can study it and audit it;
- allows anyone to create, for their own use, derived or custom versions;
- allows anyone to make a business selling derived versions within the license terms (for example, in the time-bomb period the users of your patch must be licensees of the original owner);
- guarantees that the vendor cannot lock you in, and the software will become completely free after a certain date;
- generates resources for software development that would otherwise not be available, so that functionality could only exist in proprietary, closed source form,
... then, I belive, the loss, for a limited span of time, of the ability to use it gratis is a very good overall compromise. We all understand and accept the idea that work must be paid and that a price tag designates something valuable, that is worth making and paying for. Don't castigate money ideologically, use them to achieve the philosophic goals.
Somewhere, somebody pulled a dirty trick on OSS developers and moved the goalposts to "and you must now renounce all material possessions and live on pure ether".
Just waiting on you to free it, even if there was a promised (but not in the license) deadline to do so is a lot legally shakier, you'd have to pursue it under promissory estoppel.
Such a licensed application would change its "main developer" over the years, for example someone would take the 4 years old free-beer version, invest money and time and create a compelling feature set that would make people pay for their version, after 4 more years someone else could do the same to the new feature set etc. So while the initial developer has the freedom to release under multiple-licenses, once they go for "commercial-copy-left" they set in motion a chain that restrict what future developers can do, forcing them to release their work too as commercial-copy-left if they want to have the 3 year binary exclusivity period.
I have many things I would make source available if I didn't have to worry about someone reselling them.
If you’re just sitting on it and not monetizing it, and you release it and someone else generates revenue with it, you have not been harmed in any way.
I mean... okay... it's currently a MIT license, but I really was pissed just for the question.
Well, because "ethics"!
In practice, all the above professions have similar marketing/businessplan/user-vs-customer problems; just not the trivial ones you listed.
There is no shortage of jobs where programmers are getting paid for programming.
And at the same time there is a growing abundance of artificially created worries for those who want to remain independent and sell their work directly.
But I have to admit I can't parse your comment and create coherent meaning from it.
So I don't know if I would agree or disagree with you.
Some discussion from 3 years ago: https://news.ycombinator.com/item?id=20325011