51–60 of 173 posts
I predict that the problem of overburdened open source maintainers will be solved by adjusting expectations, rather than new funding or new business models. Open Source maintainers owe nothing to non-paying users. The norm should be that only those that pay get support.
Requiring payment for support would mean that poor people who switch to open source are going to have a bad time. A better option would be to create a community of users and contributors that are willing to support each other and improve the project at the same time. The new GitHub discussions feature can help facilitate creating such a community for those projects that use GitHub.
"Github discussions" looks to me like Github discovering user forums. It's not an innovation — user forums have been around for decades.
The expectation that maintainers will provide unlimited support to poor people illustrates exactly why maintainers burn out. Maintainers don't owe poor people anything, any more than they owe corporations anything.
Earlier quoted context omitted.
Requiring payment for support would mean that poor people who switch to open source are going to have a bad time. A better option would be to create a community of users and contributors that are willing to support each other and improve the project at the same time. The new GitHub discussions feature can help facilitate creating such a community for those projects that use GitHub.
How do you differentiate leechers from contributors? "Github discussions" looks to me like Github discovering user forums. It's not an innovation — user forums have been around for decades. The expectation that maintainers will provide unlimited support to poor people illustrates exactly why maintainers burn out. Maintainers don't owe poor people anything, any more than they owe corporations anything.
It isn't so much that companies are unfairly using others' work. It's that if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes, which translates into you putting pressure on the maintainers to do more work. By all means, use those people's previous work to put something amazing out into the world quickly. However, when you inevitably need hel…
Earlier quoted context omitted.
How do you differentiate leechers from contributors? "Github discussions" looks to me like Github discovering user forums. It's not an innovation — user forums have been around for decades. The expectation that maintainers will provide unlimited support to poor people illustrates exactly why maintainers burn out. Maintainers don't owe poor people anything, any more than they owe corporations anything.
The "leechers" are part of the ecosystem of the project too, putting down people who haven't yet started to contribute is a sure way to sour your project in their minds and prevent them from ever trying to answer other folks support questions, let alone contribute code to the project. So don't try to divide the community like that, instead treat everyone as future contributors and create spaces for them to start cont…
> But, with the exception of some big projects—like Linux—the labor involved isn't particularly communal. Most are like Bootstrap, where the majority of the work landed on a tiny team of people.
Offering unlimited free support is guaranteeing that either the project will fail when the core maintainers burn out, or that the core maintainers will live in perpetual misery.
Earlier quoted context omitted.
I go for #1 pretty frequently but my biggest frustration with trying to contribute to open source projects is: the repository whose owner pops in every 6 months or so to merge a PR or two, then disappears. Just enough activity to hope that they might eventually merge my outstanding PRs, not quite dead enough for me to just fork and move on with my life...
Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.
Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer.
The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
It isn't so much that companies are unfairly using others' work. It's that if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes, which translates into you putting pressure on the maintainers to do more work. By all means, use those people's previous work to put something amazing out into the world quickly. However, when you inevitably need hel…
This was so easy to "sneak" into the process where I work: > The fastest way to get results is for me to contribute a fix. > Can't we copy their code and fix it locally? > Absolutely, but then we won't get any fixes from them in the future, unless we set up our own build infrastructure and have a team make sure that they merge across changes regularly. ... which starts sounding like lots of money. Your employer cares…
Earlier quoted context omitted.
Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.
Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now . Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard . For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintain…
This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about.
raiser: "Merge my PR. It fixes this issue."
maintainer: "It fixes this single issue but you've broken this for everyone else."
raiser: table flip
Done poorly, it's throwing good money down a drain - but I would think the ROI would at least be as good as scientific grants (for which it is usually hard to get any type of sustainable infrastructure funding).
Open source hackers suffer the same fate as other creatives. What's the software industry analog of gigging at some shit bars that rake in money getting people who like your music drunk but not paying you all while working a day job so you can do what you love? Really it's this whole stupid capitalist setup. It's not just open source programmers and artists who suffer this. It's everyone. Have you ever met a single p…