Hi everyone. I wanted to let you know (and I know this isn't a huge surprise) that we will be shutting down the Google Code project hosting system over the next year.
I'll be hanging around answering questions, but the short form of 'why' is that it just isn't used much anymore, ourselves included, in favor of Github or bitbucket.
Please can you add a way for projects on google code to do a redirect to wherever they have gone. I moved all my projects late 2013, put notices on all pages I could etc, but still searching for the project often shows the google code site first.
Google Code did one thing very well - each project could have one wiki and issue tracker, but any number of source code repos. This is fantastic for projects where there are multiple parts - eg an Android client, an iOS client, multiple server parts etc. Github for example only lets you have one source repository per project, and as a result the wikis and issues are useless since they are almost always filed against the wrong sub-project.
Every startup I have been involved in over the last many years used Google for business (users, groups, office stuff etc), but then for code hosting we were forced to go elsewhere, needing yet another set of user accounts, groups, admin, billing etc. There was a ticket begging to let folks pay for google code, but it never came to pass. All the startups would have gladly paid, especially to avoid dealing with multiple accounts, sites and admin. Some features like the issue tracker were quite good. Heck you could even prioritise issues - something github still didn't have the last time I looked.
> Github for example only lets you have one source repository per project, and as a result the wikis and issues are useless since they are almost always filed against the wrong sub-project.
You can disable the wiki and issues pages on a repository-by-repository basis. If you're looking to solve the issue of issues being filed in the wrong place, you could try to pick the component that is the most central or most front-facing and only leave that wiki or issue tracker enabled. Then you'd just add a simple note in the README of the other repos about where to go to report issues or read documentation. It's definitely not the same, but it is a somewhat elegant workaround.
Hi cdibona! I'm primary on-call at GitHub today, and I wanted to say thanks to everyone that worked on https://code.google.com/export-to-github/ and worked with us to load test it before this announcement. It's really cool to see so much work put into making it easy for folks to easily move their data.
While true that no one uses Google Code. Every now and then, I bump into some obscure but a little useful project being hosted on Google Code. Maybe, makers of those projects have grown out of them and don't wish to put any more effort but still, there is a bit of value, I am able to derive from them.
What will happen, if those projects are not migrated because their developers have simply forgotten about them?
We are planing on taking the majority of these legitimate, open source, 'abandonded' projects and putting them up in cold storage in a git repo on googlesource.com
Someone needs to do an Internet Archive style project on all these repositories, put them up on Github, and make sure that they are indexed properly by search engines (i.e. intro pages become README.md, wikis are migrated, etc.).
It sounds like Google hasn't committed to serving this content in any form past 2016.
But there is a plan to provide archival-style info throughout 2016 (tarballs per project). Is Google in touch with someone like the Intenet Archive to make sure that these data are still available after Google stops hosting them? I'm sure there's some group that's willing to take on the work of hosting the project metadata and associated files.
I personally, occasionally use a handful of "orphaned" libraries that haven't been touched in years and only live on Google Code. Gonna be a bummer when those links break.
One thing that might be nice to do - if you see a project with high recent download stats (I'm sure there are a few) but their developers seem to have abandoned them, will you please do a courtesy backup to github, or perhaps notify people who starred it that the owners didn't mograte it to GitHub and the data will be lost unless someone does.
Have you considered that Google Code hosts amount of code that is related to the research papers and are not actively maintained (many probably since uploading). This wast valuable resource will be gone forever.
Mabe someone will finally get it. You can't trust third-party sites to keep your stuff up. Host it yourself if you want to be sure it's around somewhere. Use free hosting as a backup plan.
"What will happen to things that are hosted on google code, like jquery and the google font set? Thousand, if not millions of pages link to these directly - will they all be invalidated? "
I hope those millions of pages are not linking into Google Code URLs, which are repos for developers. I don't think popular libraries like jquery core and fonts even have Google Code URLs.
They should be linking into Google's Hosted Libraries, which are separate and will continue AFAIK:
> rather geeky and sometimes unreliable internet site called SourceForge
Wtf. SourceForge was for a long time very decent. It wasn't geeky nor unreliable, it offered CVS and later Subversion, web hosting, mailing list hosting, forums and downloads.
GoogleCode itself was geeky with its very basic "Wiki", but it had a leaner "GMail style" UI, with only basic features so newer projects used it over SourceForge.
"Bidding farewell to Google Code", that's a rather nice wording for closing down a web service. Please archive orphan open source projects to a read-only SVN/GIT repo or donate the data to archive.org.
It reminds us that more open source projects should host the code on their servers, e.g. using Gitlab. In some years SourceForge and GitHub may get closed down too. Some orphan project of great value may get lost of the digital dark age.
If any open source projects want to self host with GitLab CE we will be glad to provide free consulting to help them migrate and provide a free instance. Contact me at sytse@gitlab.com to get started.
I haven't read the source article, but SourceForge at some point was real slow. Like, it would takes minutes alone to Log In at SourceForge, let alone checking out SVN repo. Accessing website hosted on SourgeForge was real slow too. I think during that year (not sure which year), tons of projects migrate either to Google Code or to GitHub. It was later that sourceforge improve.
Would it be possible to get a list of all the projects inside Google Code? I would very much like to grab the lot and preserve them inside searchcode.com
Codeplex provides this sort of data and GitHub and Bitbucket have an API. I could write a crawler/scraper to do so but I would probably miss something.
Please don't let this become similar to Geocities and have it all lost forever.
Are there any alternatives that allow the use of SVN? I use Google Code to store my Skyrim mods-- because Skyrim mods heavily depend on being in the Skyrim folder structure, I need to have them on SVN (or TFS, I guess) so I can create "sparse" repos. Git doesn't allow this.
I got a kick out of the CmdTaco cameo in the Wired article:
“GitHub is just really smooth,” says Rob “CmdrTaco” Malda, who lived through the open source revolution as the editor-in-chief of the tech site Slashdot. “It’s a sexy, modern interface.”
These are some captions in need of a meme generator.
In all seriousness, though, I started my own open source project hosting website back in the day. It was the first to offer public Mercurial and Git hosting.
Google Code existed then and the interface and functionality has not really changed since I released the first version of the site.
As someone who used Google Code a while back (and did indeed end up moving to Github): it's a pity it had to end, but thank you for hosting it while it lasted. In its day, it was a service of unequaled quality.
No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate.
What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth overhead) by publishing static files over HTTP. With the addition of a static export of the Google Code pages (mostly doable by crawling; some pagination issues would need to be worked out), Google could host the site going forward on a simple HTTP server without needing to maintain its server-side codebase. And Google is lacking in neither HTTP servers or bandwidth... Belated abuse complaints would remain a problem, but it's easy enough to delete things on request.
Google is obviously not legally obligated to keep the site up, and under current mores I suppose it's not socially obligated either. But I think that when the owning company continues to be highly financially successful and maintenance is easy enough, there should be a social obligation for some kind of archival.
Or at least redirect the subdomain to whatever Archive Team comes up with...
Google hates anything that requires a human's touch, and per the article:
> Lately, the administrative load has consisted almost exclusively of abuse management.
They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.
As for the deep links, one of the Google Code devs did mention[1]:
> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.
His comment also contains a link to a wiki with more information on how to opt-in to this service.
> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.
And this is an opt in service, nothing is automated. They could ,AT LEAST, partner with Github or someone else to have the whole thing automated... Seriously... the really want to put 0 money in that stuff,they don't give a damn.
There are seriously good projects that will be lost no question.Open source code is a community wealth,even in funky languages nobody use anymore. What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".
But the parent comment gave a very plausible suggestion for how Google can do this in a very low maintenance way. Yes, there is abuse management, but now that they're read-only I'd expect this to fall off pretty fast.
Google's first business is access to information about links. You'd think they would be more careful about propagating link rot.
Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?
"Google hates anything that requires a human's touch"
Perhaps they should stop offering products to humans then?
Seriously, why would _anybody_ use/recommend a Google product, when the expectation of "customer service" is "maybe some other poor schmuk on some poorly maintained and difficult to search Google group once had the same problem and they (or some other non Google person) worked out a fix and bothered posting it".
Yeah, you're not paying for it - it's worth exactly that when anything goes wrong. (Unless you're running 5 or 6 digits a month in Adwords spend, then they're _remarkably_ good at CS...)
I think, when people give you something of value for free, it's not okay to respond with "But you should have given me more!" If that's not obvious to you, think of it in game theory terms: you're basically responding to cooperation with defection.
The proper response to something like this shutting down is "It's a pity it has to end, but thank you for running the service all those years."
Can you explain the game theory behind that? I would've expected that, in this case (where the worst case for a user is what will currently happen), responding with a request for more rather than cooperation is actually the rational behaviour.
Par for the course as far as Google's concerned. This is the one caveat I give all my clients before going ahead with using any google service beyond gmail, since you can easily get the rug yanked out from underneath you. It's not usually the discontinuation of an entire service, but they drop major features from many apps, and give the users as much warning as a Vogon would.
I disagree with your comment. I'm sharing my disagreement via this comment rather than down voting (because I don't do that).
I think Google and others should feel free to experiment, shut down closed experiments once the time is right, and not have to be obligated to spend resources on archiving things. As long as migrating is easy.
I'm sure some are going to immediately say "Yet another Google casualty", but I feel like this one probably needed to happen. It's been stagnant for years, and they have been on the mindshare decline since the first two years. I dread having to deal with open source software that is still on Google Code.
Admit failure, provide plenty of notice (like they're doing), and close up shop so resources can be spent on more impactful projects.
How is this even a failure? Google Code was the best at what it did for several years. Now it's not. That doesn't eradicate the time in the past where it provided real value to millions of users.
A party isn't a failure just because everyone eventually has to go home. It just means even successful things have ends.
> How is this even a failure? Google Code was the best at what it did for several years.
Google Code had a few good years, and I am grateful that it happened. However, it did fail to win the software forge battle as the space heated up. It failed to evolve enough to keep up. It failed to keep the mindshare it built in those two initial years as Github and others blew past it over the next six.
So call it for what it is: A project that had two good years out of eight. Like many failures, there were successful moments and positive impacts on the greater community. But closing down due to losing constitutes failure.
Basically, this. In case others didn't read the post, you'll have almost a year to take your projects off. We wanted the handful of projects that were still active to have plenty of time to migrate.
Is it possible, when code goes cold, to redirect URLS to archive.org rather than 404ing them?
I have been known to make use of ancient, forgotten code from geocities pages, and keeping the integrity of hyperlinks together matters to me. Think of the blog posts that currently link to Google Code pages; those will never be updated.
There are thousands of independent/homebrew projects that call Google Code their home that will probably vanish overnight. And not everyone likes using Git to begin with.
I don't see why they don't put stricter requirements on starting a project page or contributing instead of making this move.
I agree, a lot of google shutdowns are really awesome products that just have a small userbase. Stuff like Reader didn't even have good alternatives when it shutdown.
Google Code isn't that great of a product, it has a small userbase, and there are many alternatives.
Yeah. I don't think anyone is surprised by this, and it's very different from a Google Reader situation. The writing was on the wall when Google projects started moving off of it and onto Github.
Hi Chris, GitLab CEO here. What do you think about mentioning Gitlab.com as an alternative for people to move to? It has unlimited (private) projects and unlimited collaborators. It is based the open source GitLab project.
It is a very nice system, but the stuff that goes into a shutdown had me fighting to keep the message as tight as possible. I wanted to go on about Bitbucket, gitlab, and put in a long discussion about how this doesn't effect the scalable git team at google at all (we host android and chrome and a ton of internal teams on a git backed on our backends here) , but had to keep the message pure...
Thanks for the honest answer! I know a lot of geeks wont agree with this, but the reality is when you are doing PR (or anything else, including/especially software engineering) you need to be as simple as possible.
Rather than recommending a specific Git hoster such as Github, you should have listed out alternatives... especially as Google Code also supports Subversion and Mercurial.
I've used GitLab before as an enterprise type installation and it was okay but I had no idea you offered GitHub like hosting. When I visit your site it looks like there are no free options but Google Code was meant to house open source projects for free just like GitHub and BitBucket.
Do you have free hosting for open source? If not then I don't think it makes sense for them to mention your service.
Edit: As pointed out below GitLab.com actually has free public and private repository hosting. It took me a while to find it on the website. That's pretty cool!
Thanks for the love furry! We're seeing more people switch, including many from Gitorious. We try to combine the advantages of a good interface and free repositories.
It's a ballsy and maybe foolishly ambitious motto, but in Gitlab's case they actually deliver on it -- which, considering the current monopolization of project hosting is quite a feat unto itself.
I really don't think that blog post is the place to pitch code hosting websites. Github (and to a lesser degree bitbucket) are websites that are exactly in the space where Google Code and before that Sourceforge were.
I think it is fair to for GitLab to pitch their service, considering that the google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times, while GitLab offers similar functionality. It would have been fairer for the blog to not-specifically endorse anything or post a link to https://en.wikipedia.org/wiki/Comparison_of_source_code_soft...
Obviously, they specifically closed it because everyone uses Github. I think the key selling point though for you guys, is not putting code on other peoples' servers at all, which is unlikely to be Google Code alums.
Thanks, people hosting their own servers currently are the majority of GitLab users. But we also want to be a valid hosted alternative with GitLab.com and we think free (private) repos with extensive functionality is a pretty sweet deal.
I think that GitLab should compete directly with GitHub in open source projects hosting area. Free open tier is powerful tools for letting more people know you.
And for the whole community's benefits, we need another choice other than GitHub.
For all the touted distributed version control advantages we now have one world global centralized repo. Yeah, yeah, I know you can clone it locally. But of course if all the issues, and testing, and build tools are tied to Github. Isn't it a bit disconcerting?
Maybe I am just paranoid. And not saying that Google code was going anywhere, I saw more and more projects switch to Github and Google code receiving less and less attention.
You're not paranoid, but there are also lots of advantages to centralization, as the article touching on this in Wired says "Having one central location allows people to collaborate more easily" (I'd love to know if anyone has attempted to quantify this).
What to do about it?
* Use other would-be global centralized repo to create competition, eg Gitlab.com (or if you demand 100% FLOSS, maybe notabug.org though it is a very long shot for achieving such centrality)
* Discount centralization benefits and self host, eg using gitlab, gogs (which notabug runs), kallithea, or various other FLOSS code hosting applications
* Work making migration between hosts easier (eg issue and other configuration import/export)
* Work on harder problems of federation among code hosts; distributed bug trackers have been reinvented many times but never taken off, but maybe just the right approach hasn't taken off yet, or maybe there is something in federated social web approaches
* Do one or more of the above and treat Github as marketing and backup for your main platform (or vice versa), analogous to what the indieweb people recommend for dominant social networks http://indiewebcamp.com/POSSE
Some monocultures are natural, and may well be in the best interests of everybody. I certainly believe that the dominance of Google in search, Wikipedia in facts, Stack Overflow in programming Q&A, and GitHub in open source project hosting have all made my day-to-day work easier/faster/better.
It's not monoculture, there is also bitbucket which IMHO is much better product. Problem is that all the cool kids are now using github and if you want to look cool you also have to use github. Or you could just ignore the hype and use bitbucket.
I don't expect Github to go away anytime soon (though if it did---yes, it would be very disruptive; your paranoia is not unjustified). I'm more concerned about compromise of a single high-value target; anyone remember when rubygems.org was compromised in 2013?
I confess to actually trying to get http://suckless.org/ at least mirrored on Github. But I was wrong and the current suckless system is decentralised and works.
Seems like one of the better (best?) shutdowns Google has done IMO.
There are several compelling (also free) alternatives (GitHub/etc.), so this isn't like Reader (which had previously killed a lot of viable/non-free competitors in its market).
Agreed. There are viable alternatives, there are migration tools, and the "sunset" is staged nicely.
You can't create any new projects on the service.
You have 5 months to continue using the service while you work on finding an alternative.
In 10 months, it's shut down, except that tarballs of project source, issues, and wikis will still be available.
For ~12 more months (until the end of 2016), tar balls will be available for download.
A 2-year shutdown is more than reasonable. Hopefully by then I'll catch all of the orphaned projects that I may want to use, and be able to save them elsewhere myself.
Myself and lots of other academics chose google code to host projects that are no longer actively contributed to but still used or of interest to the academic community as building blocks for future research. At the time it seemed like the safest place to leave something.
I'll be moving my code and forking a few analytical projects I use appreciate but I hope they would leave the site up in read only or archive mode for longer then a year as i'm sure many authors have moved on and may not even be aware of this change.
Yes, this is also my biggest concern. I'm working in bioinformatics and smallish open-source repositories created by other bioinformaticians which haven't seen much maintenance but still get used a fair amount (like https://code.google.com/p/biopieces) will probably be the worst casualties from this transition. Guess we'll have to backup those dependencies somewhere else...
Correct. That's only become particularly relevant in the past few years, though. Sure, they retired projects before, but they are becoming increasingly ambitious with the retirements. By that I mean they are retiring things that lots of people still use (Reader), were not released that long beforehand (Helpouts), could be viable businesses with modifications (Wallet for Digital Goods), or contain large quantities of valuable content (Code).
My point is that Code has been running for quite a while, and at one stage it probably did look like the safest way to keep a project online. Can't blame people for choosing it earlier on.
Does this mean Chromium is also moving away from Google Code? I'm curious how Google plans to migrate almost 500,000 bug reports.
I'm expecting Google to purchase GitHub next in order to improve its deficiencies. In particular code search, which is really poor. Google Code search is good, so Google can then apply its search expertise "in-house".
At least for Android bug reports, Google mostly ignores them and closes them all as obsolete every release even though they weren't fixed. So I don't think they'll have any problem ditching Chromium bug reports. I've heard they have an internal bug tracker anyway, so the public ones like b.android.com are just jokes on people who don't know any better.
The problem is that last time I looked at these tools, they all sucked. I migrated code hosting and website for my project to github but left issue tracking on Google Code because the github API doesn't let you do any kind of high fidelity import of issues. I hope GH find a way to do some kind of reasonable issue import soon.
Last error report I created (which is consistently causing tab crashes) was marked as duplicate and merged (without comment) into an issue that is private and inaccessible. All attempts to get additional information have been met with silence.
Wired did a nice story about Github that touches on the shutdown: http://www.wired.com/2015/03/github-conquered-google-microso...
I'll be hanging around answering questions, but the short form of 'why' is that it just isn't used much anymore, ourselves included, in favor of Github or bitbucket.
https://code.google.com/p/apsw/
Google Code did one thing very well - each project could have one wiki and issue tracker, but any number of source code repos. This is fantastic for projects where there are multiple parts - eg an Android client, an iOS client, multiple server parts etc. Github for example only lets you have one source repository per project, and as a result the wikis and issues are useless since they are almost always filed against the wrong sub-project.
Every startup I have been involved in over the last many years used Google for business (users, groups, office stuff etc), but then for code hosting we were forced to go elsewhere, needing yet another set of user accounts, groups, admin, billing etc. There was a ticket begging to let folks pay for google code, but it never came to pass. All the startups would have gladly paid, especially to avoid dealing with multiple accounts, sites and admin. Some features like the issue tracker were quite good. Heck you could even prioritise issues - something github still didn't have the last time I looked.
For an example of what this looks like: http://code.google.com/p/iosched
You can disable the wiki and issues pages on a repository-by-repository basis. If you're looking to solve the issue of issues being filed in the wrong place, you could try to pick the component that is the most central or most front-facing and only leave that wiki or issue tracker enabled. Then you'd just add a simple note in the README of the other repos about where to go to report issues or read documentation. It's definitely not the same, but it is a somewhat elegant workaround.
What will happen, if those projects are not migrated because their developers have simply forgotten about them?
But there is a plan to provide archival-style info throughout 2016 (tarballs per project). Is Google in touch with someone like the Intenet Archive to make sure that these data are still available after Google stops hosting them? I'm sure there's some group that's willing to take on the work of hosting the project metadata and associated files.
I personally, occasionally use a handful of "orphaned" libraries that haven't been touched in years and only live on Google Code. Gonna be a bummer when those links break.
For instance if you want to file bugs for AppEngine the official way is through Google Code
https://code.google.com/p/googleappengine/issues/list
What are the plans on moving this and other issue lists for different Google products out of Google Code?
We have plans for this, we're just not ready to talk about them yet.
"What will happen to things that are hosted on google code, like jquery and the google font set? Thousand, if not millions of pages link to these directly - will they all be invalidated? "
They should be linking into Google's Hosted Libraries, which are separate and will continue AFAIK:
https://developers.google.com/speed/libraries/devguide
> rather geeky and sometimes unreliable internet site called SourceForge
Wtf. SourceForge was for a long time very decent. It wasn't geeky nor unreliable, it offered CVS and later Subversion, web hosting, mailing list hosting, forums and downloads.
GoogleCode itself was geeky with its very basic "Wiki", but it had a leaner "GMail style" UI, with only basic features so newer projects used it over SourceForge.
"Bidding farewell to Google Code", that's a rather nice wording for closing down a web service. Please archive orphan open source projects to a read-only SVN/GIT repo or donate the data to archive.org.
It reminds us that more open source projects should host the code on their servers, e.g. using Gitlab. In some years SourceForge and GitHub may get closed down too. Some orphan project of great value may get lost of the digital dark age.
Would it be possible to get a list of all the projects inside Google Code? I would very much like to grab the lot and preserve them inside searchcode.com
Codeplex provides this sort of data and GitHub and Bitbucket have an API. I could write a crawler/scraper to do so but I would probably miss something.
Please don't let this become similar to Geocities and have it all lost forever.
“GitHub is just really smooth,” says Rob “CmdrTaco” Malda, who lived through the open source revolution as the editor-in-chief of the tech site Slashdot. “It’s a sexy, modern interface.”
These are some captions in need of a meme generator.
In all seriousness, though, I started my own open source project hosting website back in the day. It was the first to offer public Mercurial and Git hosting.
Google Code existed then and the interface and functionality has not really changed since I released the first version of the site.
Dead Comment
No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate.
What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth overhead) by publishing static files over HTTP. With the addition of a static export of the Google Code pages (mostly doable by crawling; some pagination issues would need to be worked out), Google could host the site going forward on a simple HTTP server without needing to maintain its server-side codebase. And Google is lacking in neither HTTP servers or bandwidth... Belated abuse complaints would remain a problem, but it's easy enough to delete things on request.
Google is obviously not legally obligated to keep the site up, and under current mores I suppose it's not socially obligated either. But I think that when the owning company continues to be highly financially successful and maintenance is easy enough, there should be a social obligation for some kind of archival.
Or at least redirect the subdomain to whatever Archive Team comes up with...
> Lately, the administrative load has consisted almost exclusively of abuse management.
They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.
As for the deep links, one of the Google Code devs did mention[1]:
> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.
His comment also contains a link to a wiki with more information on how to opt-in to this service.
http://google-opensource.blogspot.com/2015/03/farewell-to-go...
And this is an opt in service, nothing is automated. They could ,AT LEAST, partner with Github or someone else to have the whole thing automated... Seriously... the really want to put 0 money in that stuff,they don't give a damn.
There are seriously good projects that will be lost no question.Open source code is a community wealth,even in funky languages nobody use anymore. What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".
Google's first business is access to information about links. You'd think they would be more careful about propagating link rot.
Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?
I guess robots will soon make decisions in Google too ;)
Perhaps they should stop offering products to humans then?
Seriously, why would _anybody_ use/recommend a Google product, when the expectation of "customer service" is "maybe some other poor schmuk on some poorly maintained and difficult to search Google group once had the same problem and they (or some other non Google person) worked out a fix and bothered posting it".
Yeah, you're not paying for it - it's worth exactly that when anything goes wrong. (Unless you're running 5 or 6 digits a month in Adwords spend, then they're _remarkably_ good at CS...)
https://news.ycombinator.com/item?id=9192554
(a) a project's issues and wiki will be preserved in some form, in addition to the repo(s) themselves;
(b) code.google.com links will be redirected to this googlesource archive (for projects which have not opted in to the custom redirect thing).
If the answer is yes on both, then I'm a happy camper.
The proper response to something like this shutting down is "It's a pity it has to end, but thank you for running the service all those years."
I think Google and others should feel free to experiment, shut down closed experiments once the time is right, and not have to be obligated to spend resources on archiving things. As long as migrating is easy.
Admit failure, provide plenty of notice (like they're doing), and close up shop so resources can be spent on more impactful projects.
A party isn't a failure just because everyone eventually has to go home. It just means even successful things have ends.
Google Code had a few good years, and I am grateful that it happened. However, it did fail to win the software forge battle as the space heated up. It failed to evolve enough to keep up. It failed to keep the mindshare it built in those two initial years as Github and others blew past it over the next six.
So call it for what it is: A project that had two good years out of eight. Like many failures, there were successful moments and positive impacts on the greater community. But closing down due to losing constitutes failure.
I have been known to make use of ancient, forgotten code from geocities pages, and keeping the integrity of hyperlinks together matters to me. Think of the blog posts that currently link to Google Code pages; those will never be updated.
I don't see why they don't put stricter requirements on starting a project page or contributing instead of making this move.
FWIW. Mercurial can use Git as a backend which would ease the tension for those not enamored with it.
Google Code isn't that great of a product, it has a small userbase, and there are many alternatives.
But I heartily recommend people look at Gitlab...
That you haven't yet is mindboggling.
Do you have free hosting for open source? If not then I don't think it makes sense for them to mention your service.
Edit: As pointed out below GitLab.com actually has free public and private repository hosting. It took me a while to find it on the website. That's pretty cool!
Github is really great for the social experience, but I've been debating switching over to GitLab for all of my development projects.
"Better than GitHub"
That's quite a motto.
Just say you're the best git host. Don't mention your competitor.
I'm going to go create an account on it now. Good luck, guys!
Gitlab is not.
I would love to see the option to move from Google code to GitLab.
And for the whole community's benefits, we need another choice other than GitHub.
I am.
For all the touted distributed version control advantages we now have one world global centralized repo. Yeah, yeah, I know you can clone it locally. But of course if all the issues, and testing, and build tools are tied to Github. Isn't it a bit disconcerting?
Maybe I am just paranoid. And not saying that Google code was going anywhere, I saw more and more projects switch to Github and Google code receiving less and less attention.
What to do about it?
* Use other would-be global centralized repo to create competition, eg Gitlab.com (or if you demand 100% FLOSS, maybe notabug.org though it is a very long shot for achieving such centrality)
* Discount centralization benefits and self host, eg using gitlab, gogs (which notabug runs), kallithea, or various other FLOSS code hosting applications
* Work making migration between hosts easier (eg issue and other configuration import/export)
* Work on harder problems of federation among code hosts; distributed bug trackers have been reinvented many times but never taken off, but maybe just the right approach hasn't taken off yet, or maybe there is something in federated social web approaches
* Do one or more of the above and treat Github as marketing and backup for your main platform (or vice versa), analogous to what the indieweb people recommend for dominant social networks http://indiewebcamp.com/POSSE
4 years ago someone might've said the same about Google Code.
Expectations change, and then Github might go away.
http://git.suckless.org/ works
issue list? the mailing list
pull requests? which are imo quite painful in github still, are just patches sent to the mailing list. no login or special tooling required.
kiss,
There are several compelling (also free) alternatives (GitHub/etc.), so this isn't like Reader (which had previously killed a lot of viable/non-free competitors in its market).
They even have automated migration setup.
Looks pretty well done.
Kudos, Google!
I'll be moving my code and forking a few analytical projects I use appreciate but I hope they would leave the site up in read only or archive mode for longer then a year as i'm sure many authors have moved on and may not even be aware of this change.
Google is never the safest place to store anything, unless it's your personal data. Google sunsets products constantly.
My point is that Code has been running for quite a while, and at one stage it probably did look like the safest way to keep a project online. Can't blame people for choosing it earlier on.
I'm expecting Google to purchase GitHub next in order to improve its deficiencies. In particular code search, which is really poor. Google Code search is good, so Google can then apply its search expertise "in-house".
https://code.google.com/p/chromium/codesearch
Maybe it's just habitual, but I prefer the issue tracker on Google Code as well.
The chromium bugtracker is very active and the chromium developers are very open and helpful on it.
"How to export Google Code issue tracker data to other services" https://code.google.com/p/support-tools/wiki/IssueExporterTo...
So basically this is our 5 year warning on GitHub closing down !?