Most open source projects start small. The author writes code that solves some issue they have. Likely, someone else has the same problem and they would find the code useful. So it's published. For a while it's quiet, but one day a second user shows up and they like it. Maybe something isn't clear or they have a suggestion. That's reasonable and supporting one person doesn't take much.
Then the third user shows up. They have an odd edge case and the code isn't working. Fixing it will take some back and forth but it still can be done in a respectable amount of time. All is good. A few more users might show up, but most open source projects will maintain a small audience. Everyone is happy.
Sometimes, projects keep gaining popularity. Slowly at first, but the growth in interest is there. More bug reports, more discussions, more pull requests. The author didn't expect it. What was doable before takes more effort now. Even if the author adds contributors, they are now a project and a community manager. It requires different skills and a certain mindset. Not everyone is cut out for this. They might even handle a small community pretty well, but at a certain size it gets difficult.
The level of communication and collaboration required can only grow. Not everyone can deal with this and that's ok.
All of that sounds reasonable. But it also doesn't need to be a reason to find maintaining OSS very draining or unpleasant, as GP put it.
First of all, when a project grows, its core team of maintainers can also grow, so that the maintenance burden can be shared. This is up to the original author(s) to address if they think their workload is a problem.
Secondly, and coming back to the post that started this thread, the comment was "working for free is not fun", implying that if people paid for their work, then it would be "fun". They didn't complain about the amount of work, but about the fact that they weren't financially compensated for it. These are just skewed incentives to have when working on an open source project. It means that they would prioritize support of paying customers over non-paying users, which indirectly also guides the direction of the project, and eventually leads to enshittification and rugpulls, as in MinIO's case.
The approach that actually makes open source projects thrive is to see it as an opportunity to build a community of people who are passionate about a common topic, and deal with the good and the bad aspects as they come. This does mean that you will have annoying and entitled users, which is the case for any project regardless of its license, but it also means that your project will be improved by the community itself, and that the maintenance burden doesn't have to be entirely on your shoulders. Any successful OSS project in history has been managed this way, while those that aren't remain a footnote in some person's GitHub profile, or are forked by people who actually understand open source.
Honestly, I don't see how you're adding anything here other than inflated expectations and a strange anti-individual pro-mega-corporation ideology.
Fundamentally your post boils down to this: All contributions should be self funded by the person making them.
This might seem acceptable at first glance, but it has some really perverse implications that are far worse than making a product customers are willing to pay for.
To be granted the right to work on an open source project, you must have a day job that isn't affiliated with the project. You must first work eight hours a day to ensure your existence, only after those eight hours are up, are you allowed to work on the open source project.
Every other form of labor is allowed to charge for money, even the street cleaner or the elderly janitor stocking up on his pension, everyone except the open source developer and that everyone includes people who work on behalf of a company that directly earns money off the open source project, including software developers hired by said company even if those software developers work full time on the open source project. This means that you can run into absurd scenarios like SF salaries being paid for contributors, while the maintainer, who might be happy with an average polish developer salary doesn't even get the little amount they would need to live a hermit life doing nothing but working on the project. No, that maintainer is expected, I mean obligated, to keep working his day job to then be granted the privilege of working for free.
Somehow the maintainer is the selfish one for wanting his desire to exist be equally as important as other people's desire for the project to exist. The idea that people value the project but not the process that brings about the project sounds deeply suspect.
Your complaint that prioritizing paid feature is bad is disturbing, because of the above paragraph. The maintainer is expected to donate his resources for the greater good, but in instances where the maintainer could acquire resources to donate to the public at large through the project itself, he must not do so, because he must acquire the donation resources through his day job. To be allowed to prioritize the project, he must deprioritize the project.
The strangest part by far though is that if you are a company that produces and sells proprietary software, you're the good guy. As I said in the beginning. This feels like a very anti OSS stance since open source software is only allowed to exist in the shadow of proprietary software that makes money. The argument is always that certain types of software should not exist and that the things that are supposedly being withheld are more important than the things being created.
I personally think this type of subtractive thinking is very insidious. You can have the best intentions in the world and still be branded the devil. Meanwhile the devil can do whatever he wants. There is always this implicit demand that you ought to be an actual devil for the good of everyone.
We already have a "user agent" as a term for software (browsers, curl, etc.) that fetches web content on behalf of a user. It predates current AI agents by a few decades. I don't think it has much agency either, but here we are (were?).
As for anthropomorphizing software - we've been doing it for a long time. We have software that reads and writes data. Originally those were things that only humans did. But over time these words gained another meaning.
How am I supposed to research things myself? Let's say I want to research effectiveness and safety of a flu vaccine by myself.
I don't have resources to set up my own lab. I don't even know if the manufacturer will sell a dozen or so vaccines directly to me. So can't even do a basic stoichiometry on my own. And forget about me setting up a trial with actual people - I have no idea where I could begin to make it possible.
If by research you mean reading already published papers, that's literature review and I wouldn't call that a research. But because doing my own experiments and trials is out of question, I'm willing to settle for that.
Reviewing published papers comes with its own set of problems. A lot of papers are behind paywall and I don't have money for the ongoing journal subscriptions. I suppose I can rely only on open journals and pre-prints but that's not all of them. Messaging the authors directly is also an option but it's doesn't scale well and takes time.
Suppose I get my hands on a couple of relevant papers. How can I be sure what's written there is actually correct? It would be nice if I could double check against the raw data, but often that's not available. And at best all I can verify is that the paper's content matches the source data. I can't verify the data itself. At some point I have to trust the authors. Not to mention I don't have access to the data from research that wasn't published, for example because the experiments didn't show anything novel.
But that's fine. Nothing is perfect and after hours (if not days) of reading and playing with data I came to a conclusion that I'm happy with. Of course I have to review it again in a few years. The new research will be published by then. Maybe they will discover something different and I have to review that too.
Overall, I spent a lot of time and it was exhausting. Diligently reading and cross-referencing all that data is mentally taxing. I can't complain though because I've learned something.
There's one problem though. All of that effort was about just a single vaccine. But there's more of them. For other diseases too. And there are other problems I'd love to research. Windmills. Microplastics. Glyphosate. Dozens of types of food. Economic theories. How can I research all of that in a timely fashion?
I'm genuinely asking because I want to. I realize there will be trade-offs involved, but all of them are either relying on someone else (which we try to avoid) or won't be deep enough to form an informed opinion. And I'm not happy with either.
> Let's say I want to research effectiveness and safety of a flu vaccine by myself.
Sure. Let's say the manufacturer and the government claim that the vaccine is 100% effective, all of the time, with no side effects.
But you happen to notice that lots of women are complaining online about, say, missing their periods for months at a time after taking it. And getting the flu anyway.
Congratulations. You have done your own research, made your own observations, and thought for yourself.
That's the kind of thing many people were talking about. What else could they be talking about, since as you point out, they didn't have any access to raw data.
If you want to get hardcore into citizen science, that's really cool. You will have to pick a direction though; we can't do everything unfortunately. And funding is hard.
> A lot of papers are behind paywall and I don't have money for the ongoing journal subscriptions.
There are ways around this these days, but yeah the paywalling and siloing of knowledge is really holding back our potential as a species.
Did you know that it connects back to Ghislaine Maxwell's dad? Yeah, he was the guy most responsible for expanding the paywall model of academic research and maximising the profit from it. He could make or break scientific careers, keep certain discoveries to himself, hold leverage on academic institutions and professors...
It's there in the The Model Services Contract, under Core Terms:
> Quality Plans
> 6.1 The Supplier shall develop, within [insert number] Working Days of the Effective Date, quality plans that ensure that all aspects of the Services are the subject of quality management systems and are consistent with BS EN ISO 9001 or any equivalent standard which is generally recognised as having replaced it ("Quality Plans").
The Short Form Contract also have optional ISO 27001 or Cyber Essentials (which is, uh, an adventure on its own). But there's also an option for no certification required. It depends on the contract.
But yes, you're right. Dealing with requirements takes time and experience and you likely need a dedicated person (or team) to deal with it.
reply