Long time ago Sourceforge and then GitHub promoted into the current default the model of open source distribution which is not sustainable and I doubt it is something that the founding fathers of Free Software/Open Source had in mind. Open source licenses are about freedom of using and modifying software. The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user to better fit the user's needs. To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all. The currently default model of having an open issue tracker, accepting third party pull requests, doing code reviews, providing support by email or chat, timely security patches etc, has nothing to do with open source and is not sustainable. This is OK if it is done for a hobby project as long as the author is having fun doing this work, but as soon as the software is used for commercial, production critical systems, the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane. This is software support, it is a job, it should be paid.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
Free Software sure, that wasn't the point.
Open Source, that was exactly the point. Eric S Raymond, one of the original promoters of the concept of Open Source coined Linus' Law:
Given enough eyeballs, all bugs are shallow
Which definitely points in the direction of receiving bug reports and patches from users of the application. He was also a proponent of the Bazaar model, where software is developed in public, as opposed to the Cathedral model where software is only released in milestones (he used GCC and Emacs as examples, which reinforces the part of your statement about the Free Software movement in particular).I fully agree. The psychological burden is also high, what makes the maintainer feel miserable over time.
I don’t agree with this newer idea that has arisen that FOSS authors are “victims.”
It’s up to you to set boundaries (or prices) and communicate them, like an adult. If one is still rude and entitled then ban them from the repo, or let people fork, but not before looking in the mirror first and reflecting at your own behavior.
(I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.)
has nothing to do with open source
long time ago
Sourceforge is almost 30 years old. GitHub almost 20.How long does something have to be done a certain way for it to be "to do with"?
I would say we're now two generations deep of software engineers who came up with open source software commonly being mediated through public issue trackers.
That isn't to say it needs to stay that way, just that I think a lot of people do in fact associate public project tracking with open source software.
> has nothing to do with open source
I partially disagree. It does have to do with open source: Github (et al) are about creating a community around an open source project. It's hard to get adoption without a community; it gives you valid bug reports, use cases you didn't think of, and patches.
You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
> and is not sustainable
I 100% agree. People (including people at for profit companies) are taking advantage of the communities that open source maintainers are trying to build and manipulating guilt and a sense of duty to get their way.
The most insidious burnout I see is in disorganized volunteer communities. A volunteer is praised for jumping in with both feet, pushes themselves really hard, is rewarded vocally and often and with more authority, and is often the one applying the most pressure to themselves. There's no supervisor to tell them to pace themselves. And when their view switches from idealistic to realistic and then falls into pessimistic, they view the environment through a toxic lens.
Then they vanish.
> This is software support, it is a job, it should be paid.
What's stopping any open source maintainer from charging for their work?
I thought about this a lot recently and decided that the small, mostly complete, project I work on now, if I release it (I probably will), I will just post an archive somewhere with the source code, like in old days.
> the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane.
I think there are many insane expectations out there, open source or not, so I don't personally see it that linked with the idea/ideal of open source.
> This is software support, it is a job, it should be paid.
Anything can be paid, nobody says otherwise. Some people prefer nobody pays for their source code (open source). Other people do support for free. And so on.
> The currently default model of having ... has nothing to do with open source and is not sustainable.
There were always arguments why open source will not be sustainable, many having some truth in them. But the current issue can be probably solved with some push-back on the speed of things or how attribution works. Something similar used to happen on some forums: you can't post a new thread for one month if you did not reply at least once without getting down-voted. For the current problem : if contributions are anonymous for the first 3 years of you contributing (if you are not banned) and your name becomes public only after, then all this "noise" for "advertisement" will die. Doubt this will discourage any well intentioned contributor.
I've also noticed this expectation. Where does it come from?
FOSS means that the code to be free and open-source, not the schedule or the direction of its developer(s).
> This is software support, it is a job, it should be paid.
It is paid, even if not in money. It seems like maybe you lack awareness of the other forms of capital and reward that exist, because your framing implicitly insists that financial capital is the only form of capital and that monetary reward is the only form of reward. But there are also a bunch of other forms of capital, like social, cultural, symbolic, etc. which you have missed, and there are non-capital (non-convertible) forms of reward, like feeling good about something. It's the entire reason why permissive licenses still preserve attribution.
To wit, people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things. There are both intrinsic and extrinsic non-monetary gains here.
Stallman makes the same critical error in his foundational writings, so at least you're not alone in this.
(A foundational read on the subject of the different forms of capital is Pierre Bourdieu's The Forms of Capital: https://www.scribd.com/document/859144970/P-Bourdieu-the-For...)
(See also: https://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extri...)
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind
Who cares? That was 30 years ago. How different were computers, programming, and the world back then?
Things change over time. The world is not immutable.
> To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all.
Untrue. Shopping source with _some_ OSI-approved licenses makes the work Free software. Shipping it with others merely makes it open source software.
I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
The project managers also get a cut of all merges, testers also must approve of the merge and that feature X is the one they want. So the project manager gets to work and improve/reject features, the user gets control over the features of the project they want and developers get to pick specific features they would like to work on (sort of). everybody gets what they want (sort of). All via attaching $ to the issues of the software, not the people.