Lambda the Ultimate

The process by which language libraries are maintained may have a bigger impact on language success than generally recognized.

A common event for developers is finding a bug in some crucial library function. The big question is, what happens then? There are several models:

1. The library is commercially supported.
   1. The vendor is responsive to bug reports. The user submits a bug report and the problem is fixed.
   2. The vendor is not responsive to bug reports.
2. The library is supported by volunteers.
   1. There is an community supporting the library, with multiple people permitted to make updates.
   2. The library is supported by a single person who is active in developing the library.
   3. The library is supported by a single person who is not active, and no one else can change the code.

In case 1.2, one has the option of generating negative publicity for the vendor, which sometimes helps.

GCC and Perl (CPAN) third-party libraries are under organizational source control, so the absence of one person doesn't mean the code is never fixed. So they're in case 2.1. Open source projects can stall out in case 2.3. This is common in the Python third-party library world, and Go seems to be taking that route.

This is an organizational issue, not a licensing issue. It's quite possible for a library with an open source license to get stuck in case 2.3. Anyone can potentially do a fork, or write a replacement, but that's only worth the trouble if there is a serious need for the library. A sign of this problem is finding many packages for a language which do essentially the same thing.