[mixedbit]

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.

[burningChrome]

Years ago, I built what I thought was a pretty basic static site generator using HapiJS. I was using it for personal projects and after some convincing by friends, put it up on Github. My friends went on Reddit and posted it and then told me about it afterwards.

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.

[calenti]

Bitching is free and easier than making pull requests. And I bet it was 1 or 2 choads plus a variable pack of minions, not everyone. And Megacorp X can file all the bug reports they want, their lack of investment is not my urgency.

[necovek]

In general, there is a difference of ethos and culture between Free Software and Open Source movements. GitHub is the latter: strewn with expectations from low-effort requests.

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...

[cjblomqvist]

Far from all OSS projects are like this. Eg. https://www.viblo.se/talks/

[hypfer]

Been there, done that, built walls.

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.

[nmz]

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.

[1-more]

All we need to do is create Kalshi contracts! Users bet that a fix won't be created for Issue 123 by date XYZ, developers take the other side of the contract and then do the best kind of insider trading: changing the facts on the ground. We did it!

[KronisLV]

> 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.

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.

[CodeMage]

> 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

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.

[pseudohadamard]

That's actually how a number of OSS projects work, we'll give you what we want for free but if you want us to do what you want you'll need to pay us. Having to implement a compatibility mechanism for some company's buggy train wreck from 20 years ago is a lot easier when you know you'll get paid at the end of it. A number of OSS dual licenses have been created to accommodate this.

[sinnsro]

You know what would be nice? For these billionaires to start sponsoring people instead of sitting on the obscene heaps of money they have—a patronage system. Everyone wins.

[llbbdd]

Are there any projects that have achieved anything close to this? I'm not against it in principle, but it seems like it ends up incurring issues from tiptoeing around wanting all the benefits of an incorporated business with employees or at least contractors without the stigma(?) of getting all official and putting someone in the hot seat of responsibility. Off the top of my head:

- 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.

[carlosjobim]

Those normal users are better off instead purchasing software. Then they will be listened to by developers if they report a bug or suggest a feature. Because they represent an incredibly valuable user segment: paying customers.

[klez]

> 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).

[pixl97]

ESR is also from a time where spamming countless reports/junk code wasn't really a concept.

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.

[ambicapter]

Linus’ Law doesn’t really imply anything about maintainers behavior though. As an example, you can imagine maintainers that never update their repos. Every bug fix is a forking of the repo, and people only use the repo with the latest commits. Eventually, the bug count goes down as well!

[solaris2007]

ESR was from a time that was radically different than the the VSCode / brew / macOS / Ubuntu centric era we have today.

  https://www.catb.org/~esr/faqs/hacker-howto.html#believe5

[mixmastamyk]

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.)

[otikik]

I think "we will ban and publicly shame you if you waste our time" is a very clear and adult boundary.

[ghostly_s]

Afaict github allows you to disable 'Issues' per repo, yet few do. I presume that means they are okay engaging with issues on some level, but I find it odd almost none post a policy/expectations around them.

[zahlman]

> 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.

... Did they try anything as petty as the xorg maintainers are nowadays?

[spicyusername]

    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.

[mnw21cam]

Thanks for making me feel old.

[NegativeK]

> 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.

[embedding-shape]

> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.

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.

[stryan]

> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.

Just a note, you actually can't turn off PR's on Github repos. At least not permanently.

[pixl97]

Yea, and before we got issue trackers quite commonly issues and code chunks were shared via email lists that quite commonly had online archives. Think things kind of like the LKML.

[1313ed01]

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.

[toomuchtodo]

What about posting it read only on Github so folks can download and fork it but not bother you with inbound requests (discussions, PR, issues)?

[thayne]

> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.

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.

[TomasBM]

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).

[embedding-shape]

I dunno, I think at one point there was a similar merge as to what happened with "git and "github" where "open source the licensing" somehow became the same as "open source the collaborative and open software development process", and nowadays people get kind of confused when you say you're doing open source yet you don't accept pull/merge requests.

[vladms]

> 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.

[snowmobile]

> This is software support, it is a job, it should be paid.

What's stopping any open source maintainer from charging for their work?

[boca_honey]

Irrelevance. The moment you paywall a project, it’s a death sentence. Unless you have a unique and highly sought-after product (top 1%), someone else will just make a free alternative.

[tom_m]

Totally agree. The expectations around what an OSS project should - or even must - have, do, and accommodate is absolutely insane. It boggles my mind sometimes as someone who grew up on OSS. I still contribute OSS and maintain some (small) projects, but I certainly don't feel compelled to support people. I often license MIT. People are grown ups, they can go fix their own issues.

[reneberlin]

I fully agree. The psychological burden is also high, what makes the maintainer feel miserable over time.

[ozim]

You mischaracterize the problem. You write like the problem would be corporate freeloaders forcing bug fixes on the open source.

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.

[madeofpalk]

> 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.

[nullc]

The original model works, the new model significantly fails. LLMs have taken many cases that were on the border over the line into failure, by changing the resource management tradeoffs. (Both by giving valuable contributors a cheap way to get 'extra eyes' on their own terms, and by empowering a new generation of trisectors and trolls to flood out even the most efficient public submission pipelines).

[jen20]

> 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.

[MaxBarraclough]

Technically correct, but not an issue in practice. If you want a licence that's approved by the OSI but not the FSF, or vice versa, you have to go looking for it. If memory serves there are no licences in the latter category, and the few in the former category are very obscure.

[BugsJustFindMe]

> 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...)

[nlawalker]

>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.

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".