[yason]

I don't see the relevance. Open source developers need not be burning themselves out, they can just choose to work on what they want.

If a big company uses an open source library there's no contractual agreement that the developer must slave away for free and fix stuff for the big company. The developer, or the company that develops open source, can just essentially say "fuck it!" and do whatever they want.

Instead, the big company can take what's available. If it's not enough, they can contribute to the open source project (a wise move!), find a replacement project to ride on, or buy or write their own implementation.

Not all open source developers work for free but many do because they want to spend some of their time building something they care about. If the project has big impact sometimes the developers get hired to continue working on the software on a payroll. This is probably a win-win: the developer gets paid to do what he would be doing anyway and the company gets stability into future development.

If open source developers want to build a good, trusted brand of their software then it of course takes continuous involvement to support their users and can lead to burn-outs but that has nothing to do with open source. The exact same applies to building an established brand out of proprietary software.

And that effort only makes sense in the first place if there's a chance for a significant financial payout in the end, or the developers really, really just want fame in which case they have their own priorities on how they want to resource the development.

Still, nothing to do with open source per se.

I bet a thousand-fold more developers are burning out in jobs working on proprietary software.

[playpause]

“Open source developers need not be burning themselves out, they can just choose to work on what they want. ” – that sounds nice, but you must be missing something, or we would not have the phenomenon of OSS developers burning out.

The observation that people in paid jobs also get burned out doesn’t give much insight into the curious, sad reality of the experience of an OSS dev working to to the point of burnout for a constant stream of non-paying clients who are often rude and unprofessional in their interactions with you.

Open source developers can’t ‘just’ choose what they work on, anyway. There are benefits in maintaining an OSS project (exposure, satisfaction at making something that a lot of people use) but these only apply if you focus your efforts on projects that become popular, which are exactly the projects that suffer the problems discussed in the article.

[yason]

Open source developers can’t ‘just’ choose what they work on, anyway.

Oh yes they can.

However, if the developers choose to chase popularity, then it's a different game and they must recognise that the stakes will be higher then. Yet that has no relevance to open source itself.

You can very well chase popularity, satisfy rude customers to the world's end, and eventually burn out writing a closed-source shareware application, too.

I tried to convey they point that the fact that there are burned out open source developers is not an inherent trait of open source itself.

You don't need to open your source to get rude customers, endless demands, and gigantic requirements. If you choose to deal with all that then that is always your own choice and you must face the consequences. But it's the same class of problems whether you write open source or start a pizza restaurant. Some customers are just net-negative. In any business or hobby where you provide something you must learn to set limits to how high the customer's bang-for-buck must be for you to come meet in the middle.

I would tend to think there are more open source projects that are abandoned rather than with burned out developers, but I obviously don't have data on that.

[tonyedgecombe]

You don't need to open your source to get rude customers, endless demands, and gigantic requirements.

In my experience the less you charge the more of that stuff you get. There is something about the very bottom of the pricing scale that is toxic.

[lsc]

It is... really weird. I think it might be related to how the boss will be more respectful to you after you successfully negotiate a raise.

Like normal people are somehow wired to treat more expensive people better than less expensive people. The immediate explanation is that normal people are kind of jerks?

I mean, I'll put up with more shit for a lot more money... but that's not how it works. As I've gotten paid better, every step of the way, I got treated better in other ways, too. And that expectation is built in everywhere.

[bad_user]

I’m not sure what your point is.

As a personal curiosity, do you maintain open source projects that actually have users depending on it?

I’m asking because when people say that OSS devs of popular projects suffer from burnout, that’s not an opinion, but a matter of fact.

And no, it’s not the same as a regular job. It’s more like starting your own company, except without the payoff.

[azangru]

> do you maintain open source projects that actually have users depending on it? I’m asking because when people say that OSS devs of popular projects suffer from burnout, that’s not an opinion, but a matter of fact.

Not the author of the parent comment and not a maintainer of a popular open-source project, but could you explain the process of how devs get into this trap of burning out? I mean, there are quite a few projects that have been abandoned by people who lost interest or have too much on their plate, so their authors are by no means forced to stay on the project if they no longer want or are able to. These projects can be forked or taken up by other maintainers.

[kakwa_]

As the creator and maintainer of a project, it's really hard to let go of said project.

It's really hard to completely abandon a project you know people are relying on. You do feel responsible for it in the end.

Also, nearly every time someone opens a ticket, it points a deficiency in your project, and it's somewhat hard to accept that your project is not "perfect" (spoiler alert, it never is). Consequently you, as a maintainer, always want to fix issues or implement obviously missing features.

Also publicly admitting that your project is abandoned (by an header in the README for example) is quite hard, it feels like a failure and at least, you are publicly admitting something with a negative connotation.

"Maintained" forks that take over the initial project are extremely rare. In most cases, a fork will be tiny modifications done to fit one user's specific need. Nobody really wants to factorize these modifications into a common solution and maintain it. Well maintained forks do happen, but only for highly projects.

I'm speaking out of experience, I maintain a bunch of projects, not highly popular ones (a few dozen stars on github), but definitely used by other people. And in these projects I've a few that I definitely have nor the motivation nor the means to really maintain well. Typically I created a puppet samba module that is quite successful, but I've not used Puppet in 3 years, so I'm not a consumer of my own software anymore and I've not followed the evolution of Puppet in years, yet, I've not set my mind on publicly stating that this project is not maintained anymore.

Lastly if I do get PR for these projects, these are generally not really complete quite complete, documentation and unit tests are always missing, and the code quality is rarely on par, specially if the PR is quite complex. For every PR I accept I generally have a few commits to complete it/fix it.

[Ayesh]

You can easily fix the low quality PR issue with a CI setup.

Setup a Travis job to fail often (build, lint, test, coverage, etc), so you pressure them PR author to complete it. This will make the entry barrier massive, but helps you focus your attention.

In addition, take an hour setting up issue and PR templates and guidelines in GitHub. A good readme with an FAQ section helps too.

See Symfony/Symfony for a good example.

[bad_user]

It's easy to get into that trap.

We love to code and the projects you work on become like your babies. Have you ever heard of this expression from people doing what they love, or from people starting their own companies? "Like your baby"?

Well the trap is that you end up putting a lot of work in it, at first it's for fun, but then it's because what you're doing is popular and you hope of leaving something valuable behind. And unfortunately these things happen:

1. the project is never done, there's always some feature that people want or some bug waiting to be fixed, or some dependency waiting to be upgraded (these are the worst) and if nobody does it, then users will end up abandoning the project

2. people willing to contribute are very rare and people capable of great contributions and of sharing the maintenance burden are like unicorns

So the answer is: if you don't keep doing it, the project dies. In which case all of your effort was for nothing.

[jhbadger]

Projects have a lifespan. They don't have to be monuments for eternity, and if they get abandoned because the maintainer gets bored/burned out, it often is because the problem it was trying to solve doesn't really make sense in the current landscape anymore. The development time wasn't "wasted" if the project served its purpose in its era.

[AstralStorm]

There is also part 3, someone picks up an unmaintained project, cleans it up and makes it workable. Or patches in the feature.

This is what cannot happen in most shareware or freeware apps. It depends on the source code repository being easy to find, so centralized big ones win. (SourceForge, Github, Gitlab, etc.)

The sad part is companies not delegating a person to maintain or develop critical dependencies even though they could.

[azangru]

> In which case all of your effort was for nothing.

I thought people maintain open-source projects if they use them themselves. In which case, all your effort was for solving particular use cases that you had.

When developers have no further use for a project (e.g. when they've moved on to a different technology), then the project will likely die. I haven't seen many people keep maintaining a project after they've stopped using it.

[rleigh]

You can stop using the tool yourself, but still have a large active userbase depending upon it. As a result, you can still end up with an unwritten obligation to support that userbase.

[rleigh]

You end up having unwritten obligations to your users.

You can start from the position that you can write your software, make it public, and you have no obligation to do more. Some people do just this. But once you have to (or feel that you have to) answer support questions, fix bugs, add features, make releases and do so on an ongoing basis, you can end up in a situation where you effectively have a second full-time job.

I'm not saying that this is desirable, or even necessary. But it's a reality for many open source project maintainers and contributors. You get sucked into it. End users have expectations, and it's only human to try to meet them. I've personally been very badly burned by this, and I've get to contribute at anything but a minimal level for the last six years as a result.

One of the things which I don't like are that people can have very unreasonable attitude towards what they can expect from a person who does this in their spare time who helps them for free, sacrificing their spare time for someone else's benefit. The longer I've been doing this, the more I appreciate that it's not as sustainable as we might like to believe, and that being fairly compensated for work is no bad thing. We should be more willing to say that we would be happy to fix that bug, or add that new feature, so long as we are paid for it. But in many projects this isn't politically or practically possible.

[ndnxhs]

The op comment did not say that they are not getting burned out but that they need not get burned out. Instead of listening to twitter drama just do whatever you want and if people want stuff you don't feel like doing then they can do it themself

[bad_user]

Right, and my comment is that this line of reasoning is bullshit.

It's like telling fat people that they don't need to be fat and they should just eat less what's the problem.

[pas]

???

So by the analogy popular OSS maintainers have cravings to satisfy/answer/handle every last little bit of report/email/tweet about their project? Because if they have, that's no inherent to OSS, that's inherent to humans haven't evolved sufficient self-control against larger than tribe societies, and that's exactly how some humans have insufficient self-control to resist overeating. It's not their fault, but it's still their decision.

[bad_user]

> that's exactly how some humans have insufficient self-control to resist overeating

My analogy was perfect because those that preach know nothing about the cause.

No, it's not about cravings. Or self-control.

[pas]

Then what's the cause? Your analogy should have helped illuminate your argument, but it made it more confusing :o

[setquk]

Just as a point, I’ve helped with open source projects under commercial interest. I’ve fixed bugs and created documentation and all I got was a fuck off or silence from the maintainers.

So I don’t bother any more. Most of the time I build a new wheel that benefits no one.

Fostering a good culture requires lots of work from both sides, contributor and maintainer.

I’m not saying all projects are like this but I’ve waded into too many of these so far.

[rleigh]

This very much depends upon the project. Being open source doesn't imply an open development process. It's very frustrating when people ignore contributions.

On the other hand, some contributions can be very expensive to integrate. If they require extensive review of the design, the code and then testing, it's imposing a huge burden on the other party. Clearly, this doesn't apply to trivial bugfixes the same way it applies to feature additions and wide-ranging refactoring, but it's important not to forget the costs which have to be borne.

It's always a pleasure to contribute to a project which has thought about this, and actually dedicates resources for external code review and integration, and actively fosters a strong and loyal community around it. It encourages repeat contributions and deeper participation, and is genuinely of mutual benefit. But not all projects can afford to do this, particularly smaller ones where a single person has to forego their evening to look at your stuff.

[logifail]

I wonder how many people end up just not contributing in public?

See: https://rachelbythebay.com/w/2018/10/09/moat/

[notacoward]

> Open source developers need not be burning themselves out

What about responsibility to one's users, and the computing community in general? As we very recently saw with the event-stream fiasco, there are consequences when the author of a popular piece of software tries to retire from maintaining it, because of burnout or any other reason. What if they can't find a suitable successor? What do you suggest should happen then? Just freeze it, letting it break as things it depends on continue to change?

[joaomacp]

Yes. And then if it breaks and users want a replacement, they'll move to a fork

[notacoward]

If it breaks visibly (which tends not to include security issues), and if people who didn't come forward to be maintainers of the original suddenly get motivated to be maintainers of an active fork. That's not really a very good succession plan, and the people who actually write software know that. It's why those who have some sense of responsibility and professional pride risk burnout maintaining software they'd rather be rid of, but those who lack those qualities will never understand.

[buboard]

What about the social pressure, with dev social networks and all?

[yason]

Social pressure exists regardless of the source code distribution model and whether it's free or paid work.

People can always succumb to social pressure. Open source developers do suffer from that too but taking up on social pressure is not inherently relevant to the project being open source.

[buboard]

i m not talking about real life social pressure, but github turns software social, with all the anxieties that come with it. and people do want it to reflect well on their profile/CV. In my experience, the expectations from other people in the community is a big motivator.

[TeMPOraL]

> and people do want it to reflect well on their profile/CV.

Ah, there you have it. It's not related to Open Source.

The problems so oft complained about usually show up when what you really want is to be popular. Popularity takes more work, and different kind of work, than just delivering software with open source.

[onlydeadheroes]

> github turns software social, with all the anxieties that come with it

And there is your problem. Maybe the social functions of github are not helping?