6 ms·
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
by yason 8y ago
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.
- bad_user 8y agoI’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 8y ago> 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.
- bad_user 8y agoIt'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.
- AstralStorm 8y agoThere 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 8y ago> 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 8y agoYou 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.
- ndnxhs 8y agoThe 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 8y agoRight, 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 8y ago??? 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 8y ago> 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 8y agoThen what's the cause? Your analogy should have helped illuminate your argument, but it made it more confusing :o
- setquk 8y agoJust 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.
- logifail 8y agoI wonder how many people end up just not contributing in public? See: https://rachelbythebay.com/w/2018/10/09/moat/ https://rachelbythebay.com/w/2018/10/09/moat/
- rleigh 8y agoThis 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.
- buboard 8y agoWhat about the social pressure, with dev social networks and all?
- yason 8y agoSocial 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 8y agoi 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 8y ago> 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 8y ago> 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?
- playpause 8y ago“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 8y agoOpen 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 8y agoYou 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.
- notacoward 8y ago> 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 8y agoYes. And then if it breaks and users want a replacement, they'll move to a fork
- notacoward 8y agoIf 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.