UPDATE (March 14, 2015): Google now states that rather than deleting unmigrated projects after December 2016 as implied in their original posting, they will instead be preserving those projects in a repository on googlesource. Apparently this was the plan all along. Why didn't they explain this originally? I dunno, but perhaps it was to encourage users to migrate on their own. If they'd been straightforward about this in the first place, it would have saved me an inbox full of concerned queries and an entire blog posting. Still, all's well that ends well.

Google seems to be on a roll lately when it comes to pulling the rug out from under users. Recently there was their sudden announcement of banning explicit materials from Blogger (quickly and wisely reversed -- for which I've thanked them in the name of free speech and courtesy to users).

Now comes word of another change which -- while on a somewhat longer fuse -- may ultimately do far more damage.

You may not have heard of Google Code (GC), but over the years it has become a key repository for important open source and other software projects, documentation, and other materials.

While Google Code has clearly been eclipsed by sites such as GitHub in recent years, the fact remains that for a vast number of technical software searches the only existing references link to materials stored only on Google Code.

Google announced on their Open Source Blog today that they are not permitting new projects on GC as of ... today!

The site goes read-only this summer, and early in January goes to "tarball-only" (bulk download) read-only status until the end of 2016. Then ... it all vanishes. Poof!

The end of 2016 may seem like some time away, but in terms of the Internet and software code resources it's just a blink of the eye.

Google complains of high levels of abuse on Google Code. One might argue that lack of sufficient support resources provided to GC for years is at the root of that issue, but let that pass for now.

Google also asserts that since they are providing tools and assistance for moving projects from GC to GitHub, that this all shouldn't be a big problem at all.

Wrong. It is a big problem, and here's why.

First, much of the code on GC is from older projects -- still critical for reference purposes -- but there's nobody actively maintaining their GC project archives. Administrative email addresses have changed, the archives have long been stable, and so on.

There literally won't be anyone to migrate enormous numbers of those archives to other sites, or even receive notices regarding their upcoming demise.

Yet for vast numbers of GC projects there are also enormous numbers of links that point deeply into those GC repositories. The first clue users will have when they search for those un-migrated projects a couple of years from now -- perhaps in a critical situation -- will be "404 -- That's all we know!" -- thanks a bunch.

Vanishing code. Vanishing documentation. You get the picture. Just dandy.

Worst of all, there are obvious ways that Google could have avoided this disappearing act.

The simplest would be to take the site read-only with appropriate notification banners and explanations, and keep it available indefinitely as an important archive -- not just for less than two years. I'm sure Google could spare the disk space.

Or, as the site shutdown date approached, Google could themselves migrate the currently un-migrated projects to GitHub. Would GitHub object to this if consulted appropriately beforehand? I doubt it.

And for all migrations, Google could offer link forwarding so that the GC link references are not lost.

There are also other possible approaches, virtually all of them superior to the path that Google has chosen in this case.

Yes, there would be ongoing administrative efforts and costs necessary for all except the "After December 2016 you're just out of luck, kid!" approach.

But Google isn't some fly-by-night operation. They have the knowledge, skills, and resources to deal with this situation in a much more user-friendly, trust-positive manner, helping to maintain Internet resources, rather then deleting them for convenience's sake.

It's knowing that Google knows how to do these things right, that makes decisions like this one regarding Google Code so inexplicable and so very disappointing.

UPDATE (11:14 AM): Google tells me that they will put in place for some unspecified period of time a link redirection service for moved projects. That's very useful and appreciated. But of course that does nothing for projects that haven't been moved. Google should migrate the projects themselves that have not been migrated by the deadline.

--Lauren--

UPDATE (March 14, 2015): Google now states that rather than deleting unmigrated projects after December 2016 as implied in their original posting, they will instead be preserving those projects in a repository on googlesource. Apparently this was the plan all along. Why didn't they explain this originally? I dunno, but perhaps it was to encourage users to migrate on their own. If they'd been straightforward about this in the first place, it would have saved me an inbox full of concerned queries and an entire blog posting. Still, all's well that ends well.