An example of this is Quicksilver on the Mac. It's considered to be one of the best Mac apps ever and the developer who made it, decided to open source it after he decided to take a job at Google. Quicksilver development fell apart afterwards.
My point is that people who used the app did so because of the talent of the developer. A community can't always make up for that hole.
I don't use a Mac, and don't even know what Quicksilver was until I checked, but this was posted 17 hours ago:
http://blog.qsapp.com/post/27644282840/ss69-release-quicksil...
Maybe development didn't follow at the same pace as before, but to say it "fell apart" when they are very close to releasing 1.0 seems not very accurate to this outside observer.
I'd still take "basic bugfixing and maintenance" over "gone completely" however.
I suppose in some sense it's a bit like owning a classic car, the warranty and support from the manufacturer is long since gone but there exists a community of owners and refurb businesses keeping it alive.
What happens the next time something gets broken after a major OS update? I can't wait for a few months to get it working again.
I'm not saying that open source software is lousy. I use it all the time. It's just that in certain situations you need the person there who created it.
Techspansion, however, was a good citizen and when a Mac OS X Lion broke VisualHub, he released a patched binary, so I'm still able to use VisualHub four years after it was EOL'd! :)
You probably were a quicksilver poweruser, but I don't think there were many of you.
Perhaps a neutral third party gets code access and a contract with the developer and users as to when/if it will be released?
The agreement between the Free Qt Foundation and Nokia gives them right to release the latest Qt version under a BSD-style licence if Nokia stop releasing Qt versions (GPL+LGPL).
The applications are still fully functional and are working perfectly fine until Apple changes anything they heavily depend on or something replaces imap.
You own your copy of Sparrow and it still works.
Imagine you buy a BMW and in 10 years you cannot get the required fuel anymore. Does this mean you only pay for a new car when you get all plans for the engine and the whole construction or do you just buy another car? (I know that the comparison doesn't work 100%)
Or: There is some bug which gets active let's say after year 2013 or after 10k mails or so.
Or: (I don't know Sparrow so not sure if this applies.) You have created/build some app-specific content/database (like have done all your mail tagging with Sparrow) so you want to re-use it on future Apple hardware. Now assume that Apple introduces some new architecture (like an ARM MacBook) or makes some incompatible API changes in future MacOSX versions. Either you can't upgrade your hardware/OS or you will loose the app-specific work.
Etc.
Since they want to keep it alive (in its current state) I believe they'd fix something critical.
Apple doesn't have a habit of changing things. If anything, I feel that Apple is too conservative when it comes to making changes.
Even cars from the 1950s are compatible with modern roads, also they can have a lead additive put into the fuel, or the owner can convert the car to run on unleaded petrol.
If your program is old and closed source (in this context , old cars are basically open source since they can be repaired by anyone with relatively standard knowledge and tools).
I never used Sparrow, but I'll assume that at least they worked with standard email protocols like IMAP and POP3 making a switch to another mail client feasible. Imagine instead that they had used some proprietary (and possible patented) web service API. Then their users would really be in trouble, and this is a sort of model many startups seem to be going for.
I know, I know, don't buy an application based on promises, buy it based on what the application currently offers. Wise words, I have learned.