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:
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.
Active forum topics
New forum topics