Citing the perl 6 fork leading to the decline of the whole language(s) is very interesting.
What the author doesn't know is that not only perl6 forked off, also 4 other perl5 forks appeared during the last year, which is a strong sign of an already dying community and language. I'm one of the forkers (cperl).<p>For me forking was a necessity since the perl5 community was not able to come up with any improvement at all since the author left 15 years ago. It rather managed to erode the codebase and the management (the perl5 "asshole" problem). "Faith" into the developers capabilities is a now a mandatory code of conduct point, even if the said devs did nothing to prove their capabilities in the last 15 years. Using religious arguments to hold people together might have worked in the middle ages and in a post-modern community. (perl is one, go figure).<p>On the contrary the perl 6 and perl 5 leaders are making cynical jokes about their future, to the end that a new backend or a new fork will make the language and the community stronger. (<a href="https://youtu.be/gmmVGPdcItM" rel="nofollow">https://youtu.be/gmmVGPdcItM</a> 2016 - "The Ongoing Disaster That Is Perl 5" - Ricardo Signes) Which is of course wrong. We don't need Volapük and the Kerckhoff fork to show this.<p>There are many bad examples in the BSD land, the latest DragonflyBSD, and many more on debian forks.<p>Now to the arguments why to fork:<p>* perl5 argues that forking (experiments) are good, and if successful will lead to "stealing" the good parts.<p>This never happened so far with perl5. They rather blocked competing forks to submit bugfixes and discuss critical failures upstream. While the forks manage to enhance security, performance and add many wanted features (which were not added in the last 15 years since they were designed by perl6), upstream did nothing. It didn't even merge the security fixes.<p>If a community is that broken, it needs to fork to be able to survive.<p>However with parrot, the perl6 backend, it worked fine. The unfriendly fork (MoarVM) eventually replaced parrot, using a much simpler architecture. This was an easy fork, because they could simply replace it upstream. No need to persuade the community to switch over.<p>* If a product is broken beyond repair, make a new one. People will switch eventually.<p>Do people use better ssl libraries over openssl? Some do, but most don't. E.g for perl there's not a single TLS library binding other than to OpenSSL/NetSSLeay. No boringssl, no libressl, no PolarSSL (mbed TLS), no NSS. For crypto no libsodium.<p>Did HHVM survive? Well, the php devs eventually got off its ass and made an ever better version with PHP7. They didn't steal much, they rather re-architectured the whole mess. This is the best example of a successful fork which strengthened everybody. Pressure.
The GCC fork under schmorp to use the new intel Pentium intrinsics was also eventually successful.<p>I cannot say much about Python 3, only that the inherent VM problems where not solved at all and only the forks (pypy, Graal, mypy) are able to overcome that technical debt partially.
ruby has it's number of forks but is still paying for it's ruby on rails meta-architecture disaster.