It's a little dicey. Consider also that the developer who can't be fired also can't be promoted. Do you want to be the coder who made something so essential yet incomprehensible that nobody dares to fire you or promote you? Or do you want to be the coder who built something that's awesome and essential, but also simple enough to understand that anybody can maintain it, so you're free to move on to better opportunities at will? There's always somebody willing to employ the coder who can do the latter.

Then again, there are always people who have so much specialized domain knowledge and experience that it just can't be represented with any amount of good architecture, comments, and documentation. If you're in that position, do the best you can to make things clear, and try to be reasonably helpful in finding and training a replacement when the time comes.

I see the points you are making.

Here's another way to look at it. If you care about an open source project, you don't want it to fail if you get run over or pulled away from it.

Actually, that depends on the original motivations of the project. As a developer, I'll frequently code up something that amounts to a small "project" with the potential for re-use, and I might release the source of the program, because why not?

Whether it becomes popular, or achieves continuity isn't really a motive of that sort of stand-alone utility project. On the other hand, a number of wildly popular open source software projects have started out that way, as small, independent side-projects.