Programming nerds love theoretical technical problems like The Prisoner's Dilemma, or The Dining Philosophers. Here's a fun mental exercise for your afternoon: What would happen to your favorite library/service/product if the principal engineer was suddenly killed by a streetcar? For an astonishing number of services, the answer will probably not be "continue to work seamlessly".
(i'll note that i decided to break this out of a different post about Being Nice for Selfish Reasons: Work Edition. i decided that it's a question that needed it's own post.)
Most projects, like most movements or causes, tend to have a singular leader. There's a lot of reasons for that, including the facts that running a successful project kinda requires someone to make hard decisions, say "No, we shouldn't do that" a fair bit, and "We're going to go in this direction, in spite of your personal interests". There are ways to present all of those statements, sometimes in friendly, happy ways, other times like a overbearing jerk, but there are ways. The problem is also the Achilles Heel of Open Software Projects: Getting someone else to give a damn about what you're building. You have to be nice enough or provide enough value that people want to help you and deal with your pushy ideas on how to do things.
There's a weird psychological edge to successful software development that many folks don't think about. If you even think about the tools and services you use, you probably associate them with one or a very small group of lead folks. These are the captains of the project and in some respects are cult leaders for their ideas, even if they aren't in direct control. Python has Guido; jQuery has jresig; PhP has Rasmus; etc. Larger projects like Webkit require a large, organizational structure to deal with the huge, complicated code base. However, even these projects have a small group or even an individual who is the acknowledged leader. This is pretty much how humans set things up.
So, what happens when such an individual leaves a project? Usually, it's "not good things". In the sudden vacuum, there can be a power struggle as folks fight to become the replacement, or things drift as the next person in line has a slightly different view of how to do things. In rare instances, it's possible for the project to continue or improve, but that's usually because one of the goals of the individual at the helm was to ensure that he or she is replaceable. Yeah, not a lot of folks think that way. It's very uncomfortable for people to confront their lack of permanence.
All of this does impact you, however. You invest in a given resource. Whether you like it or not, you become dependent on that resource more and more. When the streetcar comes, you're also subject to the repercussions. If you're lucky, skilled and have the time, you can fork the project and keep it alive long enough to find a suitable replacement. If not, well, you're dorked.
It can also be exceptionally difficult to keep your product "Streetcar proof". Sure, there's principals of abstraction, but the big problem is that there are reasons you've picked a technology or service over it's competitors, and those reasons will be reflected in the core of your product's design. Replacing or degrading those will not be easy, or potentially possible for whoever is maintaining your code.
Yeah, that's right. You're also subject to Streetcars.
So, when your personal streetcar arrives, how will folks deal with it?