When Google Code added Mercurial support, Mercurial and Git were roughly equal in popularity. Git was more functional, but Mercurial was a lot simpler to use. In fact, almost everyone I spoke to at the time preferred Mercurial and honestly I thought it was going to be the winner. Project hosting sites that had typically used centralized source control systems like CVS or SVN scrambled to add Git and Mercurial support (including Google Code).
Then GitHub happened. They realized that the it's not just the source control system that should be decentralized but every aspect of the project. Projects could be forked with a single click, pull requests created and tracked, network graphs explored. It created an organic and discoverable open-source ecosystem, the likes of which we never saw on Google Code, SourceForge, etc. Anyone could explore ideas in existing projects without having to gain committer access. It was magical.
GitHub may have just as easily decided to bet on Mercurial instead. I believe if that would have happened, Mercurial would be the most widely used system today. BitBucket did something similar for Mercurial and did pretty well, but GitHub always had the lead.
It was the project hosting sites that lead the source control systems, not the other way round
So, back to Google Code. It could have been something huge and it could have made Mercurial the winner, but Google Code never grokked the importance of "social coding". Even though the source code was decentralized, the projects themselves were still centralized. Decentralized project concepts such as forking, network graphs, pull requests, etc - this was all from the new world of GitHub.
Over the past two years we've seen Google release new open-source projects on GitHub, then existing projects starting to migrate. Recently, Go started migration too — this is no casual move because it affects the import paths used in a vast amount of user created Go code which will build breakages. Yeah, the writing is on the wall for Google Code.
When SourceForge fell out of favor it was sold. It’s now filled with ads, especially deceiving ones on project downloads page which try to trick users into downloading some malware infested turd burner. In fact, for a while SourceForge were actively modifying genuine project releases to include spyware. Cocks.
Google didn't do a SourceForge. If there's anything we’ve learned from Google over the years is that they’re not afraid of shutting down projects that don’t work out. By the way, I really respect Google for this — killing products takes guts.
Google Code — I salute you. You did well, you made the open source world a better place, and above all you stepped aside when you knew the time was right.
Codehaus was the birthplace of many Java open-source projects last decade.
Enterprise Java was becoming mainstream, but the open-source community saw that it had much more potential than the tools provided by Sun.
Codehaus provides project hosting (source control, issue tracking, websites, continuous builds, downloads, mailing lists, IRC, etc). This was back before GitHub existed and the only other option was SourceForge (which was terrible).
But above all, Codehaus provided community. The developers across projects all hung out together, on mailing lists, IRC and the occasional global meetup. Respect and friendship. It was there that many gripes and problems were discussed and new projects were born.
If you've ever benefitted from Groovy, Jetty, Grails, Gradle, XDoclet, XStream, jMock, EasyMock, QDox, Drools, Esper, Mule, PicoContainer, Jackson, Janino, JBehave, Stomp (and hundreds others), this was thanks to the Codehaus community.
Many of the projects and people have gone on to do great things. Companies have been formed. New communities created.
Many projects died, some thrived. Codehaus is no longer the hotness it once was, but it provided the foundation that many of us have benefitted greatly form, and it's no doubt one of the giants that the Java open-source community is standing on the shoulders of.
Codehaus is now shutting down: http://codehaus.org
Please join me in raising your glasses to the people and projects. Codehaus, we salute you. So long, and thanks for all the fish.
Yes, I often have 10K plus processes running on a production server. It's caused troubles at time due to misbehaving processes, but mostly it's been ok. Linux is surprisingly good at this (wasn't always the case).
For the times when some of my processes were misbehaving, it was easy to identify which processes were misbehaving with "ps", "top", etc and resolve with "nice", "kill". This killed the bad connections without bringing the rest of the app down. Sysadmins like me.