> we want to write something that people use and love and talk about.

Then start off with something people are already using and improve that rather than to re-invent the wheel in some interesting way and then to be disappointed when nobody uses your particular wheel.

If all people did that, nothing new would get done ever. It's a risk. Developers who embark on wheel-creation know it's a risk. Nevertheless, rejection still hurts. Being ignored doesn't just mean you invested all those hours for nothing, it also means the audience rejects your take on the subject, and by extension your value system.

But telling people to just stick to established open source projects and be content with small contributions is not the solution either: first this would probably not be an interesting activity for those people and second participating in a successful OS project is by no means a protection from this kind of rejection or other kinds of grief. The "solution" here is clearly to "suck it up and move on", but I see how that can be difficult.

I'm afraid the only real advice to give here would be for developers not to get too invested in their pet projects because, like startups, most of them will never be of any interest to anyone. To all the people who are currently doing such projects, I'd say: keep doing it as long as it's fun, but not a second longer. Learn to let go.

This person clearly went on beyond that point.

Agreed that "contribute to existing projects" is not a real solution. If you want to solve a particular problem, or set of problems, there will be a finite set of solutions close to what you need. It's entirely possible that all of them suck at some level from architecture to implementation. Additionally, the current maintainers might resist the change of direction that you need, and maintaining your own fork of a large alien codebase might truly be more work than maintaining your own smaller and more familiar codebase. Many would argue that this was the case with distributed filesystems (my own specialty) from approximately 1995-2005, and perhaps even today. Saying that everybody should work on somebody else's project is like saying that everybody should work for somebody else's company. Nope. Somebody has to start the new thing before others can join.

The trick, as you say, is learning to let go. Accept that you'll have other ideas, and maybe one of them will gain more traction. In the course of a long career, maybe even one of those old projects will come back to life because of a shifting context or because working on other things inspired that one extra twist that makes it ten times more valuable. Setting something aside is not the same as throwing it away, and every good developer I know has dozens of ideas that they've set aside. You never know which one will be useful again some day.

This is an article about burning out and we're discussing on how to do open source right.

That's a bit like giving tips on how to cook a healthy meal to an anorexic who tells you she's really having trouble eating enough.

Yes, we're technically correct. No, it's not really helping anyone.

One problem with this variety of burn-out is that it appears to be for the most part self inflicted. People that are locked in to some job and that are providing that way for their family have a hard situation to fix. If you're contributing to open source and you're burning out on that then you need to recognize that this is a voluntary situation and that simply quitting is the solution. So I think the author got it right by quitting but I think burn-out is a bit too severe a term for this situation.

In that case I'd say it's similar to the fact that people get depressed regardless from their objective situations and how happy they should be relatively to others.

Put another way, I'd say that even a spoiled rich valley girl who tries too hard to be the light of the party at too many social events can suffer from a valid burnout.

I don't have as much sympathy for her as I would for the guy that burns himself out trying to earn enough money to fund his daughter's cancer treatment, but that's another matter entirely ;)

Speaking as the author of a tremendous amount of software noone uses, I found this ridiculous.

Sometimes it does hurt- mainly when you explain why what you're doing is better (or at least attempt to in objective terms) and someone still uses "the big thing". As an ops guy for a big startup, even though I get that it still kinda sucks.

But if it's causing you to feel burnt out you're taking this too seriously.

> Releasing FOSS is generally at least partially ego-driven: we want to write something that people use and love and talk about.

I think this is self regulating. Those projects rarely take off, because there's not enough motivation to be awesome.

The projects that get traction are the ones the author HAS to build to see if it'll even work.

I don't disagree with anything you've said here :)