It initially got some decent traction and then all of a sudden, all the pull requests came, all the feature requests and then all the bug reports.
I kept telling people this was a side project, if they want to fork it go ahead, but this is not something I'm going to spend a ton of time on. Then all the hate started about how I put something out into the OSS community with no desire to support it. I was bad person, my code was shit and I should stop being a developer.
That was my first and last OSS project.
I applaud and respect the people who are committed to getting OSS out there, but for me, it was a horrible experience.
If you allow me to go on a meandering tangent/exploration:
___
I mean if you think about it, this outcome is more or less inevitable, given the environment we've created.
The foundational building block being that people will always optimize for their own benefit and personal gain. They fundamentally have to, because no one else will. So that gives us a natural source of conflict, because not everyone is a builder (or at least not everyone believes that they would), meaning that they need to get someone else to do what they want to get done.
You as a builder of course operate no different to that. You also want to optimize for your own personal gain. Where it is different though is that you do not rely that much on external resources to do that, given that you can create by your own.
So these are our building blocks.
To have a functioning societal system, we do want and need to allow people that don't to receive a decent-ish slice of the output of those that create for various reasons.
Something something shared humanity, but also the fact that a society built out of autonomous builders quickly collapses. Plus multi-dimensionality, meaning that person A might be a builder in discipline X, but needs others to sustain themself in discipline Y. Society and all. Shared workload.
The mechanism that regulates the flow of resources between these agents is friction.
For example, social shaming for not sharing the fair part of what you're earning is friction. That is a constant eroding force and cost that is supposed to shift your internal mental calculus to make contributing to society the most sensible outcome.
Equally so, the act of being protective of your time, demanding respect, boundaries and fair compensation is friction that is supposed to shift someone else's mental calculus to make fair treatment of you the most sensible outcome.
____
Okay, many words, but what the fuck am I on about?
Here's where this self-regulating system implodes:
In the last two decades or so, we have absolutely supercharged the mechanism of shaming and public pressure (rel: Twitter).
Simultaneously though, we've also _vastly_ nerfed any forms of friction a builder might employ. (rel: GitHub as the default, being "nice and professional" as the default, etc.)
And that is what simply is not working. But we're not talking about that properly, because any platforms we currently have for talking about stuff are absolutely and utterly dominated by those that do not create; meaning that they get to dictate the rules.
In a very unsustainable way of course (see also collapse of democracy in general) but that is still the reality we find us in.
___
And that is _I think_ also where we can find solutions to these problems. Don't get me wrong, I'm not proposing to return to linus and tell people that they should be retroactively aborted for having made a mistake. There were many very important advancements we made culturally to push out toxicity.
We will need to reintroduce friction though.
Likewise, we will need re-engineer our communication spaces to shift the balance of power back to a sustainable equilibrium. Which doesn't mean "cold uncaring meritocracy" (also, what even is merit?) but it will mean not handing out ever-larger megaphones based on who is already screaming the loudest.
___
Anyway, TL;DR:
It's the system, stupid. It is like this, because it can't be any else given the currently governing rules.
Thanks for attending my Ted Talk.
With free software, many projects have their own code hosting with separate accounts, sometimes even separate bug trackers with another set of accounts (think Bugzilla + GitLab). Any submission is by definition bigger effort, and thus the culture is significantly different.
As an example, just try submitting a patch to GNU libc (if it hasn't switched to GitHub in the intervening years, though I'd be surprised as it's a GNU project, but it's also largely supported by Red Hat), and see where you get to. Or join the GNOME community and submit a fix. Or FreeDesktop. Or KDE. Or...
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.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
This idea rocks because eventually someone is going to get blackmailed with their affair history over, like, adding native XLSX support to FFMPEG. Can't wait. Financialize everything.
- A business has some intrinsic motivation however minuscule to fix unsexy issues like security problems or problems that aren't as visible to customers so they don't get hacked and sued and go under; in a pay-what-you-want bounty scheme all of your users are playing chicken to not be the one to put up the money for the fix. Instead they'll wait until it becomes a problem and fix it in their own branch; no reason to bother upstreaming it until someone comes forward putting up the money.
- IMO there's no way to measure cuts for something like this that can't be gamed. If you close out the bountied issue, but you make use of a bunch of utility code I contributed last week, who gets it? Or if the code I contributed is mostly a mechanical refactor of some very complex code someone else wrote? Do we divvy it up by lines of code, number of commits, etc, and that's just for the squint-and-it's-qualifiable metrics for engineers. No idea how you'd measure a cut for project managers. Someone also may be the steward of the repository and handle administrative work but not do a whole lot of feature-fixing, what cut do they get? Instead of juggling KPIs you can just pay all these people for their common contribution - time - and then you're back at something that businesses do really well.
- For any bounty system to work you need somewhere to track the bounties and hold money in escrow for payouts. Those services exist, they cost money to run, and they are going to take a cut. I'd assume they'd also invest and grow that money while they have it unless that's illegal for some reason I'm not aware of. An incorporated business keeps its bounties in the issue tracker, and its money in an account that accumulates interest that can go toward further development on the actual product instead of third-party support services. Crypto is a no-go here because that limits your contributor pool to exclusively crypto perverts, otherwise normal people have to speculate on it and convert it to normal useful money for a fee.
- I've worked at a place where the devs got to work on whatever they wanted. Required to, really, because there was very little interest or hands-on management from the owner in the direction of the product as long as sales were stable. We had a great time and got paid and we all learned a lot on company time and last I checked they are no longer in business.
- Timelines are a big factor too. If some open-source software I'm using is missing a big feature I'd like (and if post-2024, it's too substantial to just make a copy and have Copilot customize it for my use) I'm still not going to kick in the first $10 in the hopes that somebody someday builds that feature for me. I'm going to be dead or not using the software by then. If I thought the feature I wanted was worth $10,000 and I had $10,000 to kick towards it in the hopes that somebody somewhere would decide to build it, I would instead hire somebody on contract terms to do the work with a greater guarantee of results and some recourse if they screw me.
Have a bot on GitHub that nags people about the pool of committed money towards each feature, to show that they care about it - with the money being placed into an escrow and being released once the feature is implemented and merged, or until a date is reached with no merge and it's given back to everyone / or when the request is closed with no changes. Ofc no idea how you'd validate each individual issue well enough to prevent someone from misusing it, but one could feasibly create such a system, even if it'd probably get a lot of opposition from everyone.
It might be good to have such a system as an option, but I wouldn't want it to become an expectation. I've got a couple of side projects that are out on GitHub. They have open source licenses and anyone is welcome to fork them, send bug reports, or pull requests, but I don't want to have any obligation of supporting those projects.
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).They did have things like trolls and zealots that thought "Their one idea" was a gift from god and the maintainers were idiots for not adding it to the application. And eventually those people may have been banned from mailing lists. But in general the people posting code were typically well known and had some interest in fixing the application for some useful purpose.
Simply put, no idealism stands the test of time without change. Nature shows us that everything must evolve or it goes extinct. How 'free software' evolves is now up for debate.
https://www.catb.org/~esr/faqs/hacker-howto.html#believe5It’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.)
As always it depends on the circumstances, but should default to quietly closing with WONTFIX. Others have said Daniel is typically helpful and respectful so there we go.
Except for all of the responses from people saying it doesn't sound plausible for the project in question, and for the acute lack of real evidence or even details to accompany the allegation.
Additionally, I think "last resort" is way too high a bar. It's totally reasonable for an open source project to have a zero-tolerance policy for AI-generated spam patches or bug reports, and to respond with public shaming after the first offense. Nobody should be expected to make any allowance for such egregious behavior.
A user who is genuine but simply doesn't know how to usefully communicate about their problem doesn't deserve that treatment and should simply be ignored if the devs don't have time to engage in the interrogation necessary to extract a useful bug report. But if the user decides to try to use an LLM to compensate for a lack of content in their bug report, that user would be earning a negative response by making a bad decision. (If you're going to use an LLM, ask it how to write a bug report, rather than asking it to make up a bug report for you.)
... Did they try anything as petty as the xorg maintainers are nowadays?
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.
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.
Literally you cannot, you can turn off "Issues", but you cannot turn of pull requests, Microsoft/GitHub forces you to leave that open for others to submit PRs to your repositories no matter what you want.
Just a note, you actually can't turn off PR's on Github repos. At least not permanently.
But the project is still open for issues and PRs. Can only be disabled on paid accounts, right? Never had anyone try yet. I had feedback through other channels, just not on GitHub, so maybe explicitly keeping all development offline has had the intended effect? I get a trickle of issues and PRs for my other repos where development is out in the open with every commit pushed to GitHub.
But if it was discovered by drive-by LLM contributors I would still have annoying extra work, for no obvious benefit compared to just sharing archives. I do not think anyone (out of at least dozens) discovering any of my repos do that on GitHub, but from seeing my posts elsewhere.
It's not like no one can fork a source code archive, even if it is like 3-4 git-commands to run instead of just a button to click.
From the beginning, GNU projects welcomed contributions, and discussions of bugs and features were in the public. Sure it was on mailing lists, not on Github, but it was more than just shipping sources with the binaries.
That isn't to say you have to accept third party pull requests and have an open bug tracker to be free software/open source. Sqlite is a famous example that doesn't follow that model.
FOSS means that the code to be free and open-source, not the schedule or the direction of its developer(s).
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.
What's stopping any open source maintainer from charging for their work?
Huge problem for successful OSS projects is like what we have for cURL right here - newbies trying to "earn badge of honor" for scoring CVE on high profile project. The variation of it is newbies trying to score OSS contribution on high profile project (hacktoberfest).
In the end all of it is propping own CV to land a software engineering job or cybersecurity job by wannabes.
As much as I don't want to do gatekeeping and especially "old" Linus Torvalds way of gatekeeping — cURL, Linux Kernel and many high profile projects require gatekeeping to go on forward. We didn't even start on the security side of things not to allow "shady contributors".
I hate "CV proppers", "OSS as great marketing tool", "corporate freeloaders", "APT threat actors using OSS as attack vector" because they break nice things that we could have.
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.
Untrue. Shopping source with _some_ OSI-approved licenses makes the work Free software. Shipping it with others merely makes it open source software.
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...)
True, but the expectation means that taking on maintenance involves taking on and leveraging a large amount of reputational debt in a very risky way.
If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
The existence of risk does not eliminate the existence of reward. It's called "expected value", and it's non-zero, and it's for the person to manage for themself like everything else in life. Working for equity also involves risk, and nobody says that it's not compensation.
> If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
This is like saying you suffer reputational damage by retiring from a career. The claim is clearly absurd. It's not hard to step down from leading a project in a way that preserves reputation in the same way that it's not hard to leave a company without burning bridges. Some people are bad at being people and fail at both.
OP said "it should be paid" because "it is a job", and so the rejection of that claim is two-fold: 1) Uncertainty in the expected value of payment does not change the fact that it's payment, 2) Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
OP's specific written framing, that because it's a job it needs to be paid, which is only additive commentary if OP believes that it isn't being paid, disagrees with your prediction about what OP really secretly bases their statement on.
We can look further back in OP's comment as well:
> The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user
This is only fractionally true, and it is only true in an unpaid way for a desire to consume free software. It is not true in an unpaid way for the desires to produce or maintain free software. Those are done because the producers and maintainers experience some kind of reward from doing so.
I can't pay my rent or my server bills in "prestige". Entirely different.
Also, in fact, people get things that otherwise cost money all the time based on prestige.
Crucially, money, bitcoin, and pokemon cards are all transferrable. You can't transfer prestige to someone else, so it has no value in financial transactions.
> you can sell the bitcoins
Prestige is influence, and you can absolutely sell the use or effects of influence.
> There are exchanges that declare their exact value.
Payment does not need to have exact value, just non-zero expected value, which prestige definitely has. There is no exact value to startup equity either, but it's still rightly considered to be compensation for investment of labor and money.
It's been a meme for decades.