Commoning open-source versus growth-hacking open-source
10 points by geekingfrog
10 points by geekingfrog
The article sets up a world view where the only reasons to write and share software are to start a business (growth hacking) or to share the work to support a business (commoning). This is a form of "capitalist realism" (used in Fisher's book https://en.wikipedia.org/wiki/Capitalist_Realism) and a painfully narrow world view. Many (most?) people writing and sharing software don't involve capital and business. In addition, many coders take lesser paying work in order to share their code, work on open standards, etc. My main point is that I resent the author of the article repurposing the word "commons" to mean shared work for capitalism. Commons usually exist despite capitalism and the loss of a commons is usually a direct result of unchecked capitalism.
Another divide is whether that "commons" is for the benefit of users (GPL motivation) or practitioners (BSD motivation). I see people talking past each other quite frequently because they are on different sides of that divide.
By the middle of the article, it says «the company behind» and if only the first paragraph qualified the projects under consideration as «single-company-led» it would be a more reasonable classification within that group.
Even if the code is open sourced in a way that it cannot be rug-pulled is not enough, as I argue here. Even after a rug pull, the old code is still available. With or without a license rug pull, the project's direction is still controlled by the company providing it and the developer know-how is concentrated there as well.
Why are the users so entitled to maintainers not changing licenses or maintenance practices that their doing so is worth describing using a term from financial fraud?
It's a breach of the social contract. If I announce an open source project, and people contribute to it, they expect their contributions to stay available under that license. Also, if someone chooses to use the project explicitly over alternatives because it's an open source project, and they start depending on it, that's why it's unfair if I then suddenly relicense. If they'd known ahead of time this would happen, they might've chosen another open source-licensed alternative. Now they're neck deep in lock-in, which might've been my plan all along. That's why it's considered a rug pull.
I think a significant value of contracts, including licenses, is to force people to lay out what the relationship will be rather than rely on assumptions. If the user wants a commitment that a project will receive maintenance under the same license for years, they should negotiate a support contract that says that. Not claim that declining to indefinite provide free maintenance of a free project is theft. If a maintainer pushes an MIT codebase up to a code forge, users are in no way entitled to their indentured servitude.
I think for things actively promoted by a for-profit company the norms about misleading advertising coalesce over time.
If it is not by a company, or is marked from the beginning as a single-time dump, or is truly abandoned later — those options are different from advertising something as based on an open-source solution then keeping advertising the same thing but quietly dropping the open-source part.
Why does a company using an open source license obligate them to provide indefinite support if the same license doesn't obligate an individual to do so?
I think that promoting something as an open-source solution can create additional obligations.
I do think that an entity having a PR manager should be held to higher standards of communication clarity than individual persons, though.
Obviously it's legally allowed (otherwise those companies doing this would not be doing it). As you say: the license is the contract. And of course the MIT license permits re-licensing, so arguably the outside contributors who donated their hard work have absolutely no right to complain as per the law.
Nevertheless, it's a dick move. You can argue until you're blue in the face, but it will still feel like a betrayal to everyone involved.
I've always believed the same thing as well! Being explorable is as important if not more important than open-source. Good explorable examples are Emacs and most Common Lisp environments.
I think that's orthogonal to the issues at hand here which is sustainability of the project and avoiding rug pulls.
Granted, explorability a la Emacs probably makes it easier to understand how the code works, but a big system like Emacs is still not something one would like to fork, and one would not likely have enough manpower to make effective changes and keep up with upstream (see XEmacs. AFAIK it's been an also-ran for a very long time, much like Open Office and XFree86 officially still exist).
The only cases where such forks have been truly effective is when most of the team left the parent project to work on the fork (e.g. in cases like Dokeos/Chamilo, Mambo/Joomla, Open Office/Libre Office and XFree86/XOrg) or where they were re-integrated into upstream (offhand I can only remember gcc/egcs but there have been others).
It might be equally important that Common Lisp code has very good chances of just being still useful years after years with minimal to non-existence maintenance, if the original authors step away…