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.
That's great, until code.google.com no longer resolves, at which point it won't help :( Would be nice if they used that info to automatically redirect to the new site.
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.
Projects on Google Code will need to set the "project moved" flag, under the
advanced tab of the project. But once set, things should work like you
expect.
> 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.
This doesn't help for the issues. With commit messages you can reference or close tickets (eg "fixes #73"), but that won't be available if committing, unless in the one repo that does have issues enabled.
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
Will it keep existing deep links published in books and research papers from breaking? What prevents Google from setting the whole site into read-only mode as-is? Keep it working as it does now and disable changes.
Could you publish a list of projects w/descriptions? That would be great for others (gitlab?) who might want to host / cherry-pick / curate the collection a bit more than that.
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.).
Not at all, that's 100% the point of most open source licenses. Which are compulsory for a project on GC.
E.g. MIT:
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
Specifically, note "Permission is granted" and "distribute".
Comply with those terms (i.e. include that piece of text when you redistribute) and you satisfy MIT.
GPL, &c, they all have similar clauses. In fact, MIT goes much further. I could take all those projects, mirror them, and charge people insane amounts of money for it.
If you can't even rehost on Github, what good would copyleft be?
Not really.
Unlike a lot of other hosting services, Google code required you to pick an open source license for the project.
Even if there are no headers on source, you have a good argument that they were proclaiming to the world it was licensed a certain way, ...
(now, third party code they may have included is a different issue, you can't get rights to that through someone else's claims, but ...)
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.
Looking at my own and others actual behavioral patterns, I'd say the opposite is more closer to the truth. Dead links often go to someone's old server that they at some point probably planned to keep online forever. But you are of course right in that redundancy is a good thing!
"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 [email protected] 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.
Sourceforge was really good and as big in the open source world (between 1999 and 2006) like Github today. Later Google Code took over a larger part but never become as popular as Sourceforge or Github. Sourceforge is still used by many open source projects as download hosting provider (binary files). Google Code already stopped the download functionality several months/years(?) ago. Google Code was a 20% project created by Google devs in their 20% free-project-time, though it never improved beyond its first MVP stage, but was for many years very successful nevertheless.
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.
I might be feeding here, but the lesson is that you can't count on things Google releases to be around very long. Even APIs for popular products, like Google Maps. Just don't expect anything they release to have a long shelf life. It's annoying and it sucks, and it is now laughable when they tag things with phrases like "free code hosting forever" and so on.
For them to change, they'd have to either: 1) Support everything into eternity, which given their propensity to release new things frequently would grow to be impossibly expensive, or 2) Be more disciplined in what they release, so that it can be supported in perpetuity. I don't see either happening, so we end up where we are now. They have to keep innovating or they'll stagnate and die.
They kind of get a bad rap for this because of how large and visible they are. The funny thing is that many of the people here on HN have worked on projects that had very finite lifetimes as well, often closing them down for some of the same reasons.
Someone has to invest the time and money to keep services running, even if only limping along. Google likes to experiment and test the waters. It's part of why they've been so successful. I hope they keep killing off their underperforming/underused services so they can keep on pushing other things forward.
However, closing down stagnant projects is very different from locking down access to previously open APIs (Google Maps). Since we're discussing the closure of Google Code, I won't get distracted with that controversial topic.
I also find a certain level of humor in the oft-espoused "release and pivot" ideology, accompanied with the pleas for mercy found in these Google product shutdown threads. What is different? Why is Google not supposed to release and pivot like everyone else?
It is puzzling, but I think their rapid ascension has led to some people setting their expectations for Google too high. Others seem to hold them to some golden moral standard (of their own design), for some reason.
In the end, they are a for-profit business. Not a charity.
Because at some point you stop being a feature of the landscape, and you become the landscape - or a big part of it, at least.
That's where GitHub is now. If GitHub closed in the same way, that would be... unfortunate.
That seems to be where Google Code was trying to go. For whatever reason, it never quite made it.
But if you're part of the scenery - and Google Code was, for a while - and not just a shack hardly anyone visits, a burden of responsibility goes with that.
At least from my perspective, the problem is that Google sometimes releases into already-existing fields at a price point no one can compete with, absorbs the entire market, then pivots away. This is pretty destructive behavior, and I think fundamentally different from entering a field in which you intend to try to run a business (as opposed to subsidizing your entry into the field with profits from elsewhere in the company in order to undercut current players).
Except in this case they didn't absorb the market and then pivot away. The market moved away from them and consequently they shut down a service that nobody really uses anymore.
Sorry, should have made it more clear that I wasn't talking about Google Code specifically, but was responding to the parent comment regarding "release and pivot".
I think it is because of the side effect (can it be called an externalized cost?) to developers wanting to use existing open source code and not being able to find it. Google code is used by a lot of people.
Whereas an early start-up with 100 users selling a product with not much lock-in can pivot without too much side effect. The users know they are dealing with a start-up and may expect it.
Yes, and the projects that people on HN have worked on that have had very finite lifetimes get a very negative reaction on here too, for much the same reason. In fact I regularly see people suggesting that it reflects badly on startups as a whole and that you shouldn't trust them with your data whenever one pulls a stunt like this.
'Eternity' overstates it. Plenty of vendors support projects long after they are obsolete. IBM supported OS/2, released 1992 and a marketplace flop, until the end of 2006.
That means that if I need something to be around for awhile, I'll count on IBM and not Google. Google has the perogative to make that choice, of course, and long-term support generally is associated more with the business market than with consumers. Party that's because it costs more for businesses to change, partly IMO because consumers are poorly educated customers.
EDIT: It's a little odd to see this very normal comment modded down to -1 (now -3!). Another perfectly fine comment was modded down to 0. I don't care about the points at all, but it supports my instinct that some on HN are trying to protect Google. Employees? Fans?
> 'Eternity' overstates it. Plenty of vendors support projects long after they are obsolete. IBM supported OS/2, released 1992 and a marketplace flop, until the end of 2006.
I'll give you three guesses as to how much those companies still running OS/2 were paying for support in 2006.
Have you ever done business with IBM? They do the exact same thing, all of the time, except that it's software so you need to deal with migration.
When IBM buys a company/product, they will merrily throw everything out and declare that v.next is the next version of whatever product you are using. Then the legacy product goes in life support.
OS/2 lived on because it was widely deployed in banking for ATMs and POS, and it generated a lot of complimentary revenue. So when a company like Target had 100,000 cash registers, IBM got to sell services around deployment and maintenance, and management software like Tivoli to manage the devices.
I think there's a huge difference between continuing support of a product and continuing support of a service. Not the least of which is that products can pick up their own life and unofficial support even after the company has abandoned them. The best you could hope to do for a service is faithfully duplicate it, with all the effort that involves.
I think people tend to hold large companies with far-reaching services to a higher standard in this regard. I'm not arguing that stance's validity, but if MS or Google or even Facebook (yes, I know) release a product or API, people assume that it will be well supported. Partly because of $large_company's deep pockets, and partially because it's assumed that those companies understand the far-reaching consequences of their actions and want to act responsibly.
(a) For things (eg. Reader, Google Wallet for Digital Goods) that could be viable businesses in their own right with some modifications, spin them off as small companies.
(b) Open source the project they no longer have interest in. (as was done for Google Wave, which arguably wasn't necessary because the level of interest in Wave at that point was quite low)
In this case (and perhaps they already have this), I would suggest that they allow anyone to discover all the projects on Google Code and export them such that they could be imported into other code hosting sites, allowing everyone else to build a Google Code alternative.
Edit: The parent comment was flagkilled, but he was ranting about how Google should be expected to keep Google Code (and their other failed services) on life support indefinitely out of the kindness of their heart, because negative public perception.
This is pretty ridiculous. It is a free service, sustained only by how long corporate wants to foot the bill. This is why it's so important to keep in mind how sustainable your dependencies are longer term (if having to move away from them would be such a big deal).
Not only that, but Google Code lost the mindshare battle and hasn't been getting much development attention for some time now. It has fallen way behind, is now sub-par, and there has been a mass exodus of projects away from it. It had a nice year or two, but it's time to put it down.
It's simple: Stop wasting developer manpower, money, and time on something that no longer offers much utility. Close shop, figure out how those resources could be better spent doing things that are useful.
Honestly, I think he was right. Google has a really bad image problem right now where lots of people don't want to get involved with their projects because Google will most likely kill the project just like Reader and Glass.
See my couple of wasted Google Glass devices that will never see an Android update again. Do you think I'll ever buy a Google Android product after they wasted $3k of mine? Do you think I'll buy any more of their tech device blunders like cars or thermostats or other devices? Likely not. It's well established they'll just drop them soon after release anyway.
They are getting the same reputation for software services. There are lots of startups that would have been happy with Reader's usage numbers besides, so they aren't even making decisions everyone would agree are good kills.
With my Android apps, any time someone sends me a bug report or a complaint, I refund them immediately and thank them for the feedback. Does this make me the most money? Hell no. But I have a lot of friendly users who email me constantly with improvements and who aren't mad I'm ripping them off or screwing them over. That's worth a lot too. Google is saving money to screw over users with this Google Code decision and it's definitely not one I agree with.
> Honestly, I think he was right. Google has a really bad image problem right now where lots of people don't want to get involved with their projects because Google will most likely kill the project just like Reader and Glass.
Again, these are two very niche projects. Reader was a niche within a niche. Glass was an experiment that a tiny subset of the population ever even touched first-hand. It never even reached a "1.0".
As early adopters and as technologists, it's easy for us to get upset when our favorite pet project gets killed. But in the end, Reader failed to get any kind of traction beyond its niche. Glass ran into a buzzsaw of negative perception, legislation, and media twisting, in addition to technical challenges. The lessons learned from Glass will be applied to present and future efforts.
> Killing reader was a terrible idea. That cut my daily google usage in half and was obviously a key social and relevance asset.
It sucks for our niche, but ultimately Google Reader was a product that didn't have any appeal beyond said tiny niche. The original goal was to make RSS more accessible beyond technologists, but it failed to reach any kind of mass appeal. Some of this was more to do with RSS/Atom feeds having some ergonomic issues that weren't solved before the social media frenzy took hold.
Failure is when results don't meet expectations, which is what happened to Reader. I don't fault them for closing it, despite it being inconvenient for me to switch. What does a for-profit company have to gain by dumping time and resources into a failure whose window of opportunity has passed? Some goodwill from a tiny, miniscule subset of their userbase?
If you joined Google's Glass Explorer program (twice?!) expecting anything but a beta-level device with a short shelf life then more fool you. I don't think they could have been any more explicit about the goals of their program.
I think his point stands though, that Google cannot be trusted to keep services going. This will adversely affect their appeal in many minds, including mine. I have used Google since about 1998 (?) and you'd be amazed how many products have come and gone in that time.
Apologies for the rantiness of the post below, it isn't meant aggressively, just more frustration at no apparent direction seen within the Googlesphere.
The removal of features that people use with no warning and non-implementation of features immediately after release is really really annoying. It makes their stated goals ("index everything") meaningless/temporary/untrustworthy, and dissuades me from buying services from them. Freeloaders use their products a lot (I do!) but I would think twice about ever ever ever paying for software from them, or for a service because you have no idea when it'll shut shop. Even products they still produce appear to be completely disjointed (see the Play Books app on Android and the complete disparity found with their web interface...)
Here's a list of annoyances in products they've released to much fanfare, then apparently just not bothered developing anymore:
1. Google+, yes all of it. And I use it! (where is it going now that Gundotra has left?)
2. Maps: My Maps now isn't integrated into the Android app (they spun it off??), Latitude is gone, Google Local is gone but apparently still there (you can read reviews but hidden and secret GUI controls are now the order of the day for working out how to do anything in Google Maps)
3. Google Drive desktop client: will it ever tell me how far it has got in uploading a massive file? The web client does, the desktop one doesn't. Surely that's an OBVIOUS feature in a filesync utility. Don't ask about their promised Linux version. Couldn't they write it in Go or something?
4. Google Hangouts Android client: the forced update from Talk with the removal of features (is someone actually online? a presence feature seen since MSN Messenger that somehow escapes Google's notice)
5. Google Chrome OS: why is it even here? There was much talk of being stiff competition to Windows and OSX but it's like an Etch-A-Sketch toy operating system. I think TinyCore Linux does more?
I'll stop now because it's coming up to lunch time and I'll get indigestion.
I am a big fan of Android, but their incessant removal of features within their core apps and then rereleases of similar-but-ever-so-slightly-different apps ever year at I/O is getting wearisome.
Although you are correct, it's more a matter of perception / PR image. If we are looking at Google that shuts down pretty popular projects (Reader, Code, and now G+ seems to be shifting) or pretty innovative projects (Wave, Glass) then how should we feel about becoming dependant on/involved in Google products? What if Gmail switches to paid-only model? What if the next-big-Google-thing will be closed down after a year, again? What if free Google Apps will close down, and only paid version exists? What's the point of getting involved into any free Google stuff? What's the point of using Google at all?
> Although you are correct, it's more a matter of perception / PR image. If we are looking at Google that shuts down pretty popular projects (Reader, Code, and now G+ seems to be shifting) or pretty innovative projects (Wave, Glass) then how should we feel about becoming dependant on/involved in Google products?
You just listed a bunch of projects that failed to get traction or lost mindshare battles. I expect an innovator to move on from failures, which is what all of your examples are. Reader: Failure, Google Code: Failure, G+: Failure, Wave: Failure. The reasons for each failure differ, but said reasons are irrelevant to this discussion. The fact is that Google attempted something, maybe enjoyed a little bit of success, but the results didn't meet their expectations. Rather than continue running these things with skeleton crews (to what effect?), they've done the right thing and closed them down.
The only exception is Glass, which was an experiment that already is impacting other current and future products. It never had a guaranteed future. It never reached consumer "1.0".
That's great if you are an investor or employee, but if you are a user it kind of sucks.
Google just needs to be up front about it (and maybe they are): We make no commitment to supporting this application or maintaining it as is. We might make radical changes, we might shut it down. If we do shut it down, we'll warn you at least 9 months ahead of time.
I'm not going to invest much in those applications, but others might.
I gotta be frank here:
If you expect anyone in the tech world, Google or otherwise, to support a non-paid product past the point it's obviously declining in user base (IE obvious to not just internal users, but to external ones), for more than a few years, you are just not going to use anyone's products ;)
Google code is mostly irrelevant to this calculus, because it was not ever meant to make money for anyone, but i think you are a little harsh here.
Don't get me wrong, as a user, I would love to have the stuff i want to use supported forever. But it's unrealistic.
The problem is that Google represented itself as an altruistic supporter of open-source. People trusted it because it deliberately cultivated the impression of being more responsible than the default 'duh capitalism' mentality it now represents.
Google is suffering the reputational damage it deserves - not because it is now behaving any differently from other corporations but because it has betrayed the promise that it would.
> Google just needs to be up front about it (and maybe they are)
Nobody launches a new product and guarantees "If this doesn't work out, we'll keep it around indefinitely on life support". You don't start a new effort expecting failure. If it doesn't end up working out, it'll be closed down. Google's failures are just a lot more public than whatever side business many of us may take a stab at.
This isn't unique to Google. Failures need to be learned from and culled. We as a small business/startup oriented crowd should understand that more than most. I've had to kill off more projects than I'd like to admit because I didn't want to spend the time/money on what I perceived to be failures.
Not that failure is bad. Like Google, I've learned a ton from my unsuccessful projects.
In fact, many vendors, especially in the enterprise market and physical goods, stand behind what they sell through their products' lifetimes. As I mentioned elsewhere, IBM supported OS/2, a marketplace failure, for ~16 years. Buy a washer from Sears; even if that model doesn't sell well, they will support yours.
Consumer and 'free' software is the exception, and it's a recent exception with rapid release schedules. It's just shifting the costs from the vendor (maintaining old products) to the consumer (changing/upgrading).
> Consumer and 'free' software is the exception, and it's a recent exception with rapid release schedules. It's just shifting the costs from the vendor (maintaining old products) to the consumer (changing/upgrading).
It's important to note that in many cases, the vendor pays for what is otherwise a free service (Reader, Wave, G+). In the case of some services, they may gather some data from which they can profit from, but that doesn't always pay the bills.
So yes, the customer may have to switch services or upgrade, but unlike enterprise software, they aren't paying four to six figures to use said services.
I don't think "free" has anything to do with it. In fact, the reason this is not a big deal is specifically because there exist at least 2 superior free options.
it was expected by many people..infact there was discussion about same happening... Why to run a project when it is not being used?..nothing bad in that...People are angry about Glass..not this..
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".
On what planet is shutting down a service, with months and months of notice, evil?
I get it, we all hate Google on HN (for reasons unclear to me) but this is ridiculous. If these projects are truly important than donate some time and move them over yourself. To demand that google invest time and resources into the migration of these migrations or to keeping this running forever is just silly.
Shutting down Google Code is equivalent to destroying a storage full of handwritten articles, some of which exist only in a single copy and some of which are incredibly valuable.
Why valuable? For example computer science researchers had been using Google Code to host supplement code for their research publications for years now. These repositories are not maintained by these researchers any more, yet the code some times is incredibly valuable, because it allows to reproduce research results. The reason why researchers were using Google Code, is because it was supposed to be as stable as the underlying company. Yet now, in 10 months, these repositories will be destroyed.
If the code is that valuable, then perhaps they should put some time into maintaining the code, moving it to another provider, or convincing somebody to pay for hosting.
In that paper she publishes a link to a Google Code repository as supplement materials. For example, in the aforementioned paper there is a link to the following repository: http://code.google.com/p/glu-genetics/
Given she published the paper and link, she should either a) take responsibility for the general availability of the materials, and b) make sure that if people email her for the materials (after finding that they're not available on Google Code) she shares them.
Don't get me wrong, I'm all for retaining the materials and knowledge, etc etc. I'm just having a hard time understanding why you expect Google to do the work and maintain it? What if she uploaded her materials to Megaupload, or any of the hundred other filesharing sites - would you hold them to the same standard? Why doesn't the journal that published the paper (which, has a revenue stream) host the material, given that it directly supports their work?
Megaupload did not hold itself out as a repository for original work.
Megaupload is not run by Google, with the stated mission of organizing the world's information.
Megaupload is bankrupt. Google is one of the richest technology companies in history.
This is not Megaupload throwing away its hoard of 90's B movies. This is Google, knowingly and literally throwing away coding history. We don't even know what might be thrown away.
What if some currently unknown researcher wrote his first code and uploaded it to Google code and forgot about it, and turned out to be the next Zuckerberg or even Turing?
What if some valuable research that was entrusted to Google from a deceased researcher suddenly disappears?
There are likely many more unintended consequences stemming from such an act, and I don't think we should give Google a pass, especially since Google controls possibly the largest collection of computers on the planet. (besides, source code tends to compress pretty well!)
Seems like the least they could do is stick it in an 'unlimited' Google Drive and lock it as read only.
Great example. In 2-10 years from now, someone will want to find that repository.
Does anyone know of an effort to maintain this, like is done with sequencing data at the NIH? Something like PubMed Central?
I have first hand experience with this on the biology side, looking for reagents or even protocols from a 10 year old paper...and coming up completely dry. It's kind of a travesty, but the world collectively shrugged.
Handling and archiving supplementary materials should be the responsibility of the journal (like distributing and archiving the article itself). They should discourage linking to 3rd party websites where the author published his/her work.
I'm pretty sure that Google Code had a TOS where they stated that they don't guarantee that your repository is safe there forever.
There could be several reasons for closing a repository including Google going bankrupt. The availability of a scientific article should be much longer (ideally infinity) than the lifetime of any company.
FWIW, Google were happy for a lot of other people to invest time and resources into putting their projects there in the first place - you don't think there's some reasonable expectation that Google would expend some extremely minimal resources at their scale - to ensuring those peoples effort wasn't wasted/lost?
Having said that, I'm not part of any movement to "demand Google do something different", but I've been a longtime member of the "Warn friends/family/colleagues about the dangers of participating in Google services in any way that'll have any downside when they close it down, because they've got a strong track record of doing that" movement.
If _I_ were the person making this decision at Google, my announcement would have been more along the lines of "blah blah shutdown blah blah apologies/excuses blah blah, so we're going to donate enough to archive.org to ensure everything on code.google.com gets archived permanently, and automatically redirect all future code.google.com requests to that permanent archive".
> On what planet is shutting down a service, with months and months of notice, evil?
The current planet? Open source projects have a lifetime of years so five months is not that long in the scheme of things. People put there code on there and participated (providing Google content that they were able to use and drive traffic) with the expectation that it would be there for the long term.
Would it be ok for Google to delete Usenet archives?
Or a library to burn down its own buildings? Or Google to delete all scans of old books?
History matters, because citations to "old" research/code may become more valuable with new requirements and research. Surely a company that "organizes the world's information" needs no explanation of these topics.
Somebody else did have a usenet archive - Google bought them, mashed up a bunch of other nn-usenet Google stuff into it, then let it bitrot until it was effectively useless, and then removed the only search features that worked...
(Admittedly, if I recall correctly, Dejanews had already gone broke trying to maintain that archive before Google bought it, so arguably Google didn't kill it, they just bought the dying corpse and kept it animated in a zombie-like state for a decade or so past it's natural death...)
And in the intervening years, no one running a news server thought to back theirs up, no one crawled Google and made torrents?
This is software, not ancient manuscripts written by scribes on now crumbling vellum - there is no excuse for there to be one canonical copy of anything. Every pornographic movie ever made has multiple redundant backups on decentralized peer to peer networks and darknets.
I understand the importance of maintaining references, but realistically, expecting URLS to be permanent is shortsighted at best, unless you own that ___domain and the server it's on and expect to have the money to keep the rights to it in perpetuity. You can't expect a third party host to be willing to keep the servers on forever.
But as far as the historical record and the data itself - Google's given warning, people can move their data or lose it. Fork and move on.
Why would they run their own Usenet archive? Google had the Usenet archiving business sewn up, and by the time they started showing signs of being untrustworthy it was too late and much of the 80s and early 90s stuff only exists in their archives. (Oh, and as a side note apparently a lot of the interesting porn from that era has been lost to history too.)
Trusting any one service to be the bearer of internet history carries the same risk, that the service can go down at any time, and take its data with it. If this information is to be preserved it has to be hosted somewhere, preferably multiple places. If it's to be accessible online, then someone has to pay for the servers and the power and the maintenance.
Google's an ad company, they don't have an obligation to be the arbiters of human history, whatever their slogans might be regarding 'organizing the world's information'. They care about the information that makes them money.
It would be the open-source world's equivalent to Geocities shutting down. There are still times when I'm trying to search for something (usually some obscure programming or hardware hacking topic) and the only source of information was a Geocities site. I can't imagine how much of a royal pain in the ass it will be if Google Code experiences the same fate.
> I get it, we all hate Google on HN (for reasons unclear to me)
The reasons should be clear to anyone with historical context; this isn't the first time Google has spontaneously pulled the plug on some "non-core" project it decided wasn't making quite enough money, in complete disregard of said project's use by the real world. It's these sorts of things that make me very reluctant to invest heavily in Google's ecosystem; I've personally been burned in the past by these sorts of things.
It's not a googlecode-hosted project: there is no /p/ in the middle, and you can't see its source (not that there'd be much to see). It's a tool made by the googlecode team to help migrate.
I seriously doubt Github would ever agree to that automation. First, what accounts would all these orphan repos go under? Second, how much spam would they be agreeing to host by saying yes to that?
This is a much better job for The Internet Archive or a read-only google code in perpetuity.
edit: in fact, it looks like they're planning on making a read-only version, but the definition of "legitimate" is going to be very important to nail down:
> cdibona: 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
> What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".
Oh come on! I'm not a fan of everything Google does, and I can see, and in part agree with, the point you are trying to make, but this is just grasping at straws. You just lost all credibility with this comment.
Yes, I can see unmaintained code being lost here, and that is unfortunate. But Google provided this service for free, a service they started to promote open source software development. They noticed that there was a big move to other hosting platforms, that they themselves also believe are better than theirs. This has led to support for this platform to be little more than dealing with abuse cases, and they feel that the benefit to the community no longer outweighs the cost of the platform.
They have gone out of their way to provide ways to migrate code from Google Code to these other "better" platforms, and they are giving people over 18 months to migrate their code:
> January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.
They really didn't have to provide any of this.
None of this is "evil". There are plenty of acts that Google do that border on "evil", but this is really just the wrong one to choose to call them out on.
We have over a year. There will be backups of all of google code made, and even then the Internet Archive will certainly have a backup of all the software projects on it. I doubt any code will be lost - active participation might be, from developers who don't want to relearn how to do things on github.
A sibling comment already pointed this out, but the existence of https://code.google.com/export-to-github/ and its explicit mention in the post along with the clear language that they did work with GitHub and Bitbucket, leads me to believe that you did not read the post.
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?
Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?
That does make sense - the more people who stumble upon broken links an choose to use them to find information, the more traffic they get and can earn from ads with. Remember their experiments with Chrome hiding the URL(!) last year?
"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...)
Chris DiBona is Google's Director of Open Source and the author of the blog post announcing the deprecation, so I'd say yes. But he's "planning", not guaranteeing it.
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.
No, the best case for the user is what would have happened anyway. The worst case is the people who provided that free service, and maybe other people who see the thanks they got, end up thinking "well, damned if we're going to give those ungrateful bastards anything else for free."
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.
It actually can be considered a success in the style of the original intent of Chrome, Fiber, the Nexus line, and who knows, maybe the upcoming MVNO: to spur innovation and increased investment in a stagnating product area.
When Google Code came out Source Forge was horrible, and Github didn't exist. Google Code helped both open source software and the market for code hosting. Now there's a dominant, but so far so great, offering with Github, and several very good competitors.
Google Code wouldn't have even launched today, it's both necessary to projects and to Google.
Yeah, it's tempting to take a small bit of credit for the existence of the new generation of project hosting services. Google Code showed that there was room for new players, so it did open the door, but you have to give credit to GitHub for the concept of social coding. I never understood it and it goes against my personal OSS DNA, so I would never have made that leap.
Another way to (very charitably) count Google Code's success is to look at the role it played in Google. One of the largest users of Google Code has always been Google itself. In 2005, Google had released like 8 project tarballs on SF, kind of tentatively. Having Google Code as a home field endorsement allowed that to grow into the thousands. Now, OSS releases seem pretty routine for Google and feel more integrated with the community than ever.
> However, it did fail to win the software forge battle as the space heated up.
This is just the wrong metaphor entirely. It's not a battle because battles, and even wars, have ends.
But you're implying that somehow today is special and marks the end of the battle and therefore GitHub "won" because it's the most popular right now. But will it be in twenty years? If not, will you have to go back and edit your comment?
There's no winning and losing here. It's just an endless continuum of time where popularity waxes and wanes, where things end and new things begin. Google Code had a good run. So did SourceForge before it, and CVS and FTP sites before that. Something will come along to replace GitHub eventually.
The computer world is new enough that we haven't gotten used to the idea of software technology having a finite lifespan, but it absolutely does. That's OK. The goal of every product on Earth doesn't have to be to live forever.
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...
Wow dude, not only is using someone's quote on your website without consent pretty unclassy, using their employer to add legitimacy and make it seem like they're speaking on behalf of the company is just not ok at all.
Just to be clear, I asked the person that was quoted what he thought about it as I posted it and he seemed pretty relaxed https://twitter.com/sachinag/status/576145655120277504 but I still thought it was better to remove it.
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.
But, they wrote a Google Code to GitHub exporter tool. They felt the need to make a customer friendly egress tool, but not write a dozen of them. I think developers kinda know where they want to land already, and if they don't, they could do a google search, which would ultimately result in them using Github or Bitbucket, in all likelihood.
From a user action perspective, if you give a user who doesn't know what their options are too many options, they won't take action. They'll feel the need to explore all the different paths, and feel anxiety about making the right choice. I think giving users fewer things to think about is actually better a lot of the time.
Yes, good for customers to have a friendly exit path, but I'm sure Google are capable of writing a Google Code to AnyGitHostingCompany exporter tool :-)
There is also Kallithea (https://kallithea-scm.org/). Kallithea is a free and libre fork of RhodeCode after they dropped their GPLV3 license for parts of the codebase and added a paid user limit.
Kallithea is being actively developed (a 0.2 release is coming soon) by a free software community under the auspices of the software freedom conservancy. See this blog post from Bradley Kuhn for more details: http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html
Apache Allura (http://allura.apache.org/) supports Subversion, Mercurial and Git. And it is the platform which powers SourceForge so you can run your own or use it at SF.
Kallithea is partly a fork of our old, legacy version of RhodeCode without all the hard work our engineers spent over the last 12 months in turning an open source project into a real, sophisticated enterprise product.
In more than 30,000 engineering hours our team added exclusive Subversion support, 4x better performance and tons of security fixes (all based on enterprise customer feedback), server-side-mergeable pull requests and maybe the world's most flexible and advanced code review system.
Anyway, I recommend to try out both and choose the one you trust your source code and team's productivity more.
P.S.: RhodeCode Enterprise 3 is free for startups and small teams.
> Kallithea is partly a fork of our old, legacy version of RhodeCode without all the hard work our engineers spent over the last 12 months in turning an open source project into a real, sophisticated enterprise product.
The marketing-speak, it burns.
You turned your back on us. You lied. You and Marcin repeatedly told us that you were comitted to free software. I don't know if you lied to Marcin as well or if both of you knew that the GPL-ness of Rhodecode was going to disappear.
For a while you had an ambiguous licensing situation where you made it seem like Rhodecode was still somehow GPL'ed, but after a while you apparently tried to revoke permissions on everything. You even threatened with legal action someone who used the code under the GPL license you said you were allowing.
Oh, apparently you even went through with your legal threat:
And now you're talking about "engineers" and "enterprise" and "real" and "sophisticated".
bkuhn salvaged what he could without trying to get into the legalities of the GPL revoking you did (which the GPL itself forbids), but still I feel very betrayed by what you did with Rhodecode.
Wow, there is someone really angry and offensive here and not really telling the truth ...
It is sad to see how often forks go downhill if they were purely based on ideologies and not with the user and general good for the project in mind.
But anyway, we welcome and fully support everyone to fork our old GPL versions, the world does not need less but more source code management systems, especially since we lost now one of the key players in Google Code.
As can be seen in my blog post and various talks in the subject, the Kallithea community faced two choices: a fork of only the GPLv3'd components, or a lengthy GPL enforcement battle with Rhodecode, who violated the GPL by changing to a non-Free-Software license for code that combined GPL'd software that wasn't copyrighted by Rhodecode.
If Rhodecode would go back to a pure GPLv3 model for its software and develop the software in pubic again, I think the fork could be easily resolved and we could all work together again. Thus, only one simple act of yours would resolve the fork entirely, sebastiank123, will you take that act?
Meanwhile, I'm sure the Free Software user community can make the easy and obvious choice between a community-run, developed-in-public Free Software project that complies with GPLv3 and a for-profit-corporate run, developed-in-private, semi-Open-Source project that has a history of GPLv3 compliance problems.
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!
It is the third link on the homepage, that says "Sign up for GitLab.com with unlimited free (private) repositories and collaborators.". But we're open to suggestions to make it more obvious. It is hard to communicate downloads and a saas.
I think that's because you are promoting the Gitlab Enterprise edition. It is very easy to miss the third blurb which promotes the free repos. Compare this to bitbucket.org front page (Free private repos are upfront). Github.com frontpage is not as clear but they don't need to
I think what Gitlab.com needs is a template like this
- Free Private Repos - Host it on Gitlab.com
- Need to host it on your servers? Get our open source edition
- Need enterprise support/features? Get our enterprise edition and host it on your servers
Btw do you offer enterprise features on gitlab.com? It was not very clear
Also your pricing page needs to be clear about the different versions. There are at least 3 different Gitlab products (free gitlab.com, gitlab ce, gitlab ee) but the information is easy to miss.
In your homepage, the three blurbs (download and install.., pricing for spport.., signup for gitlab.com..) feel like 3 product features rather than 3 different products.
2. Gitlab.com as a product name is very confusing. When I first checked out gitlab.com my thought was "I'm already on gitlab.com, what's this other gitlab.com" :)
So I have changed it to Gitlab Hosted to make it more clear
Other Potential Improvements
This section - https://cloudup.com/c4vipl-QFBU tries to do everything. Explain features, introduce 3 different products and has a lot of text that could be removed
I would suggest making the entire block about features but in a layered way. i.e first introduce common features and then differentiate the products.
Some text could be removed - Subscriptions blurb can be replaced by "See our enterprise pricing page for subscriptions" or something similar. The way it is laid out now, it seems it is separate from Github Enterprise.
The current feature text blurb is too much text and too little text at the same time :) Too much because it is just
long lines of text. Too little because none of your features are explained elegantly. There is also a "much more" syndrome :)
Just see - https://about.gitlab.com/features/ - Powerful Code review - "Merge requests with line-by-line comments, CI and issue tracker integrations and much more" with a giant image. Text doesn't say much and ends with an ambiguous "much more" and the image is intimidating unless you are familiar with Gitlab.
Images are not much help but they help in avoiding a wall of text and all the sub features are explained
The actual experience of using Bitbucket is not that great but they are doing a good job of explaining features :). Github enterprise also does something similar.
I think you should also move "Better than Github" to a different section like say "Why use GitLab?" Having it right at the top seems very defensive and a bit distracting.
One last thing - Link to some interesting projects using Gitlab and make it easy to find. You can even link to Gitlab.org somewhere. Looking around a repo gives a better feel for the product.
Well for me personally I always head straight to the pricing page of any service I'm interested in and I didn't see any mention of the repository hosting you do there. Is that just for support / enterprise installations? Might be helpful to mention it there.
It is mentioned there but pretty low on the page, "Sign up for our free GitLab.com service if you want to use GitLab without installing it.". What do you think?
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.
Thanks for the suggestion. The first question anyone asks us is how we compare with GitHub, so we figured we answered it right on the homepage. Awesome that you'll give it a spin, I hope you like it.
Wow, way to miss my point. Gitlab might be better. But when the best ___location on the frontpage is a direct swipe at the leading competitor, to me that reads as very weak. You know who doesn't bother to take jabs at their competitors? Winners.
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...
> 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.
The only thing similar between gitlab and github is that they do something with version control. Gitlab is not a place for open source projects.
The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github.
There are many other hosting services like gitlab, what would make gitlab different so that it would deserve a pitch there?
"There are many other hosting services like gitlab, what would make gitlab different so that it would deserve a pitch there?"
Which is why I said the blogpost would be fairer to just post the wikipedia comparison link. I never said that gitlab should "deserve" a pitch on the blog. I did say it was fair for GitLab to pitch their services, as the CEO has done here, but that is different from "deserving" a pitch.
It is hard to objectively determine what is the better hosting, but based on people's individual preferences, they can subjectively decide for themselves, which the wikipedia article helps out by clearly explaining the differences. Everyone who uses google code knows about github anyway, but might not be aware that there are other services.
We saw gitorious, an entirely-opensource service, fail due to lack of revenue. And we've seen Google Code, an entirely-proprietary solution, fail. For those concerned about the longevity of their hosting setup, they may want a hosting provider that both has a steady source of income to help guarantee longevity and that is based significantly on opensource software (maybe for reasons of philosophical principle in that opensource development should use opensource infrastructure, or for pragmatic reasons such that they can always fork the hosting service code). GitLab fills this niche nicely, in that the community edition is based on fully open-source code, while the enterprise edition (that the their commercial service gitlab.com is based on) uses proprietary extensions.
"The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github."
The lack of stars on gitlab projects may simply be due to the first-mover advantage of github, but does not necessarily represent any fundamental deficiencies is the hosting service.
> It is hard to objectively determine what is the better hosting, but based on people's individual preferences, they can subjectively decide for themselves, which the wikipedia article helps out by clearly explaining the differences.
It's quite easy to tell actually. Responsiveness of the UI, featureset, availability, size of the community.
* Gitlab is measurably slower (it takes about 5 seconds to load the commit page of a project, compared to <1 for github)
* Gitlab's lacking many features that github has (many filetypes cannot be previewed, lack of integrations, general inferior issue tracker, no search and much more)
* Availability: github rarely goes down. Right now it tracks at 100% availability over the last month.
* Size of community: there is really no discussion here.
Note: I'm not talking about commercial hosting, but about a place for Open Source projects. There is currently absolutely no objective reason to put a project on gitlab.
Well if we're using "Responsiveness of the UI" as the metric, then I would argue that http://fossil-scm.org/ beats both GitLab and GitHub. Fossil is easily self hosted (just run one small executible file). And it is really fast, because it is written in C with sqlite and is simple and minimalistic. It is not git based, but is a simpler DVCS. Dynamically generated pages on my home computer take less than .001 ms to display. It has all the features most small developers need, with a builtin lightweight wiki, issue tracker, and code tree. Your self-hosted website is available even if you don't have an internet connection, or you can use free hosting service like http://chiselapp.com/. Of course it looses in terms of size of community. But popularity does not determine quality.
You will likely loose arguments on public forums if you make statements like "absolutely no objective reason to ..." because someone just needs one reason to disprove. Here goes: GitLab has a functioning interface for managing git projects and lets anyone selfhost the community edition. Therefore there is an objective reason to put a project on GitLab. QED.
> Well if we're using "Responsiveness of the UI" as the metric, then I would argue that http://fossil-scm.org/ beats both GitLab and GitHub.
Which is why I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project. Github and Bitbucket deserve the mention because those projects are well established.
> "Github and Bitbucket deserve the mention because those projects are well established."
According to Wikipedia article, GitHub and Bitbucket were established in 2008, and GitLab in sept 2011, making it ~3.5 years old and about half the age. Although the precise meaning of "well established" is vague, and while you could say that GitHub and Bitbucket are "more established" than GitLab, I would say GitLab is at least "sufficiently established" (i.e. at least sufficient enough to host projects with %99+ uptime). Quick searches reveal that GitHub is known to go down, with major ddos in Nov 2011 and 2 hours in March 2014, Bitbucket was down sometime 27th April 2014, GitLab.com went offline for a full 8 hours in July 2014. (Someone who cares further can do a more precise comparison of uptime). But they were all fixed quickly, still up, functioning, learning, and improving. While maybe your threshold for consideration an internet service to be "well established" is different from another person's threshold, your threshold is not necessarily more valid and cannot be determined without more specific criterion.
Based alone on the argument that "well established" services deserve mention, then that should mean services established before Github and Bitbucket that are still running reliably should be mentioned as well. But you have specifically said it's ok for github and bitbucket to deserve mention but not others.
> "I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project."
It should not. And as I pointed out clearly in my original comment which I will repeat for emphasis as it has been the core of my whole argument:
"google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times"
While it was appropriate (and arguably a duty as benefactor) for google to post a link to https://code.google.com/p/support-tools/ containing their export tools to github and bitbucket and the sourceforge import, that reference only takes one sentence and doesn't even require the google blog post itself to specifically mention any services. Considering that a shutdown announcement is a serious matter, it should be kept brief and limited to only information relevant to shutdown. All those specific references could have been omitted and the shutdown announcement would still make sense. By specifically mentioning certain services multiple times, the writer of the blog post has opened the door to queries about mentioning alternative services specifically. Had he written in a neutral manner (either by only posting the Wikipedia link or not mentioning any services), then it would have been inappropriate for GitLab to query for a request to be mentioned.
Again, your milage may vary (cache) and I do agree that the commits page of GitHub feels faster most of the time.
GitLab doesn't have preview support for as many features as GitHub, but it has many other features GitHub doesn't have such as protected branches and git-annex support (version large binaries with git).
We understand if people place open source projects on GitHub, they have way more registered users. But some people choose GitLab and their numbers are growing.
> GitLab is faster in on some pages. The commit page probably is slower, but not by so much:
For the initial HTTP request maybe and if you're in the US. Gitlab is painfully slow when loaded from a European network connection and you factor in the time it takes to fetch all resources. Cached or uncached.
> GitLab doesn't have preview support for as many features as GitHub, but it has many other features GitHub doesn't have such as protected branches and git-annex support (version large binaries with git).
Neither of which are important for Open Source projects.
> We understand if people place open source projects on GitHub, they have way more registered users. But some people choose GitLab and their numbers are growing.
I think Gitlab is a reasonable website to use for commercial hosting; I just don't see it for Open Source software.
Right now GitLab is hosted in Germany (AWS Frankfurt) and I was testing from the US (Mountain View). But I sometimes see the same delay you mention. We'll move it to the US east coast over the next couple of months.
I think protected branches are really nice for open source projects too, although I agree that most contributions will come from forks. Right now no open source projects use Git Annex but that might change now that it becomes easier to use, probably it is really nice if you have an open source game with huge digital assets.
On GitLab I could not search for top repositories by programming language. For a beginner like me, it is very important. I could go to Github and search for top repositories in the language I am learning. I usually find top projects, try to figure out how they work, how a experienced dev does a specific stuff (compared to noob like me) and I ask myself how can I "copy" those traits and improve myself.
On GitLab, if I stumble upon any repo I can't figure which language it uses. On GitHub it is very clear. It even shows percentage of programming language used.
Open Source helps in so much for learning about programming for a noob like me and GitLab no way does that as like GitHub. Thats the one reason I don't use GitLab much, though I have an account. And one more reason why GitHub shines over GitLab for open source projects.
Thanks these valid concerns. We would certainly like to improve the discover functionality in GitLab. Right now https://gitlab.com/explore is pretty limited. But the community is actively working on this. This month we introduced a commit calendar and I'm sure that it will improve further over the coming months.
What reasons do you have to you believe this statement? I'm curious.
> The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github.
Really? I'm surprised. I started coding a forum platform and I only amassed 3 stars. On my non-furry personas, I've capped out at about 13.
I don't think popularity in github projects is fairly distributed enough to use that as a refutation of the quality GitLab has to offer. It's a bigger bandwagon, sure, but that's all.
While a big bandwagon can be attractive (it is for me), I don't think it's fair to disqualify a competitor based on this metric alone.
> What reasons do you have to you believe this statement? I'm curious.
Did you use it? Gitlab has barely any open source projects let alone developers on it. Say as much as you want, but for many open source projects community is a big deal.
Currently there is absolutely no reason to use Gitlab. Neither does it do things better than Github or Bitbucket in any way, nor does it have a larger community. It's "just" another github clone.
> Really? I'm surprised. I started coding a forum platform and I only amassed 3 stars. On my non-furry personas, I've capped out at about 13.
> Since you used the words, "absolutely no reason", here's a counterpoint: as part of an anti-censorship hydra effort.
I don't see how this is relevant at all? First of all github did not remove that content, it IP blocked it. Secondly what do you think that gitlab would do if they would be hit by this?
Do you think it's better for github to go down for Russia entirely? Imagine that would be your proposal for what gitlab should do. Then it would even stronger enforce that gitlab is not a place to go for an Open Source project.
Why should your project suffer and become unavailable because some other project violated Russian law?
Bitbucket is also mentioned even though they don't have a lot of public projects.
GitLab is open source, has a great interface, many features (protected branches, git-annex support) and we offer unlimited (private) repositories on GitLab.com
We did not move anybody. People imported their repo's themselves. Another project that moved is F-droid https://gitlab.com/u/fdroid that was before the acquisition.
Yes, we certainly strongly suggest it to people. Just wanted to make sure everyone understands that the move is initiated by people themselves, we didn't move anyone.
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 migrated all my projects to Bitbucket when GitHub decided they do not want to host release downloads (they reversed the decision after that). I also use other Atlassian products and I trust the company to maintain the product, much more than I trust GitHub.
Bitbucket has much better review tools - hierarchical comments, approve button, side-by-side diff (GitHub has added that recently).
You can see commit log as a "graph", not just a simple list. It's easier to identify merges.
And it does not charge for personal private repositories.
GitHub decided they do not want to host release downloads (they reversed the decision after that)
AFAICT they haven't, at least i don't see any way to upload release tarballs. they certainly let anybody download tarballs generated for any annotated tag. but those tarballs are not immutable! once in a while, these tarballs start coming down with different hashes, presumably as github changes the code which generates those tarballs. that makes them less than ideal as package sources.
I really love the branch-level access control on Bitbucket. Being able to say that developers A,B,C have access to the repo, but only A can push to master, is incredibly useful.
I use GitHub, but I concede Bitbucket has cooler features (free private repos, password protected repos, etc). It can't beat GitHub's UI/UX and community though.
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.
Ah, good point. That could very well be it. Of course, the last issue I found was a security hole in google's core data api. Their review team admitted it was an issue, but rejected fixing it or rewarding a bounty, because they decided it was too esoteric. Even though it is literally a huge api key check that just doesn't happen. I've had bad experiences with filing bug reports to google :)
Honestly, while it makes sense to shut down Google Code, it is mindboggling that Google destroys information. Public projects on Google Code ought to be archived and the archives and redirects ought to be kept up in perpetuity. People may not be reached by the announcements. Some projects, the authors may be dead, in a coma, etc. Some may just not care.
This is the #1 reason I fear the cloud. When Google shuts a project down, unless you act fast, you lose data.
Would it be rocket science for Google to set up a service which provides:
1. DNS hosting
2. Static page redirects
3. Static page hosting
4. Secure static page hosting (available only to authenticated accounts)
in perpetuity? This would be a read/delete-only service.
When Google Reader shuts down, I could access my data forever. When Google Code shut down, the project archives would stay up as read-only. Etc. No maintenance, and a one-time migration with Google Takeout for each dying service.
GitHub's success is due, in no small part, to their excellent interface. Google Code was, by contrast, always ugly, hard to navigate, and hard to understand. (This, of course, ignores the many features that GitHub offers, which Google Code doesn't.)
I know of many companies that learned about GitHub via open-source projects, which GitHub hosts for free, and decided that it was so good that they should pay money. Hosting such open-source projects was a brilliant marketing move.
Google Code, by contrast, didn't seem to have a clear purpose other than hosting open-source projects. It was a kind of souped-up SourceForge, rather than a serious GitHub competitor. Google certainly had the resources to improve it, but didn't have the motivation that GitHub did -- and we see the results.
I can't say that I'm mourning Google Code, and I think that the way in which they're sunsetting it is perfectly reasonable. But it demonstrates that free services are only going to stick around so long as it is serving another purpose, and that without such a purpose, you can't reasonably expect it to stick around.
"Google Code was, by contrast, always ugly, hard to navigate, and hard to understand."
It's really funny to hear this.
If you look at press/reviews/OSS forum comments of it around launch time, people thought it had an excellent interface, because it was being compared to sourceforge.
Then github came, and by comparison, the interface looked like crap.
But you end up with this kind of weird history rewrite where the view becomes "it was always ugly", when it was probably best-around for at least 2 years, maybe more (depends on your view of early github)
"Google Code, by contrast, didn't seem to have a clear purpose other than hosting open-source projects. It was a kind of souped-up SourceForge, rather than a serious GitHub competitor. Google certainly had the resources to improve it, but didn't have the motivation that GitHub did -- and we see the results."
It was in fact, meant to be a better-than-sourceforge alternative, because Google viewed sourceforge as a harmful-to-opensource monoculture, and competition was desperately needed. github is a monoculture, but it doesn't seem, at least right now, to be harmful.
As for "serious github competitor", it was never meant to be that.
It predates github by over 2 years :)
Google Code was such an improvement over SourceForge. I think the real problem of Google Code was that it took them too long to support git. When GitHub started Google Code was still SVN only and later they only added Mercurial support. This made people look at GitHub and GitHub could shine with some new ideas, like making code contributions extremely easy and placing the code first. Which of course further increased the popularity of git and so on. By the time Google Code added git support many major projects had moved and GitHub was simply the place to be.
" I think the real problem of Google Code was that it took them too long to support git."
Yeah, this is true. Part of it was that it was going to require a ton of work to fit Git's concepts and protocols (remember, git only started supporting smart http in 2010) into the infrastructure we had.
It wasn't until the storage backend for code was completely rewritten, and better http support was added to git that it really became feasible.
(Note that Google code has a completely replicated storage backend infrastructure. It's not just a ton of git/mercurial/svn setups)
> Google Code was, by contrast, always ugly, hard to navigate, and hard to understand.
Er, do you remember 2006? Google Code was a breath of fresh air, and a huge huge improvement over what was available at Sourceforge. This isn't damning with faint praise either, it really was clean and fast and easy to use as a developer and user. It didn't do everything you wanted it to, but it did what it did so much better than basically anything else at the time.
The problem was that its interface was never given any attention, and the web is a very different place than it was in 2006, and then things you wished it did back then you still wish it would do now. Its not surprising at all that it now feels clunky and slow. Online interfaces for code hosting is not a solved problem yet, so while it would have guaranteed nothing, it's certainly necessary for a code hosting site's continued success that someone is actually continually working on improving it.
> Er, do you remember 2006? Google Code was a breath of fresh air,
Yet the product interface was stuck in 2006. It feels like a project that was "okayed" by some management but then "we don't want to put a cent on it".
"It was a kind of souped-up SourceForge, rather than a serious GitHub competitor."
You have no idea how much better the user experience of Google Code was compared to SourceForge. Especially from the project maintainer side.
I have no idea if SF still does this, but not too many years ago to upload your files you had to upload them using SSH into a folder shared between all projects, then select your download file out of those when creating the download link.
What's the median lifetime of free cloud services? It seems to be around 5 years. Someone probably tracks that.
With SourceForge putting ads in installers, they're no longer a good option. This leaves GitHub in a monopoly position, which is worrisome. Especially given the terms:
"GitHub, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, or any other GitHub service, for any reason at any time. Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account. GitHub reserves the right to refuse service to anyone for any reason at any time."
That could be a problem if GitHub's investors want more revenue generated.
We need some way to distribute open source projects so they're on at least two services simultaneously, synched.
We use GitLab Mirrors[1] to keep running syncs of our public repos on GitHub mirrored into our self-hosted GitLab server. Works really well and I highly recommend it.
That's unfortunate. I still regularly come across things on Google Code that are useful, usually just there because they were written before GitHub. There's very little chance the authors will bother moving after all this time and the resources will just disappear.
Heck, I even have several projects on there like a virtual pet one that's a good demo of how to color game sprites dynamically in Android and another that's a good demo of using the YouTube APIs. I doubt I'll both moving them, but it's sad other people won't be able to use my code any more so that Google can save a trivial amount of money.
Once we saw that Go had moved to Github, we decided Google Code was probably being shut down soon. And now, a week after we moved our own project from Google Code to Github, it gets shut down. Feels good to have called it :)
I'm sticking to self-hosted fossil-scm. Very simple, lightweight, C, but has full wiki and issue tracker and code trees.
The one thing self-hosting lacks is the social network. What is really needed for self hosted sites is a federated network (maybe with something like pump.io and openID) to allow coders from other self-hosted or sass hosts to seamlessly login and contribute and display their profile, and to help mitigate spam.
It's easy to migrate to some other repo, but I'm thinking about the tons of abandonware projects currently hosted there, that will probably disappear.
Every once in a while, googling for a solution, I find something on google code. That looks like it's no longer maintained, but is still useful for me to see how they've done it or copy-paste code (if licensed appropriately).
I knew it ... what a shame. You know what killed that product? BAD basic UI/UX. it was horrible to use an naviguate in,so people moved to something with better UX, better design and better visual. Google puts 0 efforts in these things, at least in the browser. Funny how then Google comes with "material design" , but can't update a few CSS on its old apps...
Github didn't get popular because it was written in Ruby(though it allowed them to iterate fast),it became popular because devs actually put some effort into the UI/UX and it made it easy to use ...
You know what else sucks? google app engine console , google apis console ... look at Heroku console , simple clean and usable, are you going to drop app engine too ?
So what's next after Google reader, and Google code? Google app engine ?
While I agree that Google Code, as it is right now, isn't needed anymore, I believe there is still room for innovation in this space and I wish there were more players than github, pushing the boundaries harder.
As a software developer is a tool that we use all day.
Among others, there's gitlab.com and bitbucket.com (and also mercurial, as an alternative to git itself -- though the two can push/pull between each other's repos with the right plugin).
Yes, I've installed a gitlab for my company and I'm extremely happy with it, I feel like I've much more control: authentication, authorization, how our projects are organised, etc. We are currently using both private repos on github and gitlab on aws.
Regarding mercurial, I used it a lot and hosted lot of things on bitbucket 4 years ago, but now I use git a lot more, just because it is what most of the libraries and opensource projects I use are using.
They could atleast work together with the internet archive to conserve it, but no of course not that would require be a bit of an effort, google can't do that, because google doesn't care if thousands of open source projects are going to be lost forever to the world. Don't be evil my ass. Archive team is now our last hope as usual.
I predicted this a long time ago and I've moved my projects off.
I would recommend migrating to self hosting to prevent an issue like this in the future. It's not too much of a hassle if you only have a couple of projects but when you have 10+ migrating to another source code hosting service is a real pain.
I tried rhodecode - it's very basic but upgrading was always a pain (~1hr/upgrade). And when I did manage to get an upgrade to go through there was always some problem.
Gitlab looks interesting but their community edition is lacking.
The one benefit of indefero/srchub is that it supports SVN, hg and git and private projects. So people can request a project in whatever SCM system they want and it's all managed from the same place. Also it's fairly easy to setup and maintain - no real external dependencies such as rabbitMQ or something. I have read of people even installing it on shared hosting.
I've personally tried http://phabricator.org/ but after installing it - it seemed like it was missing major features that you would assume would be there.
I think I was looking for a way to "hide" a project/make it private. And after about 30 minutes of clicking around trying different settings/features I felt like it was too bloated for me. For me - I love the simplistic nature of Google Code.
GitHub has a user GoogleCodeExporter that is publicly logging all of the repositories that are being transferred from Google Code to GitHub. The number of commits might break GitHub!
This is why http://redecentralize.org/ and other similar efforts are so important - the centralized model is functionally unfit for long term usage or relying upon. How to capitalize these newer decentralized technologies are key for next leap in the web industry.
This makes me question: how important does Google see developers as being as part of their ecosystem?
I mean, I understand all the rational logic of what they are saying. Sure, there are other services etc etc, the world will keep turning. But doesn't Google see any kind of benefit from having developers using their service? In terms of mind share, having developers think positively about Google, having them regularly come to and work with a Google service? Even in purely commercial terms, it would be something that Google could leverage to expose developers to their cloud services and other platforms. Traditionally, staying close to developers in any way they can is something platform companies strive to do.
But it seems like Google doesn't see any value in any of that. So my basic question is, does Google still care about developers? Or have they simply moved on as a company?
Google wants developers contributing to their projects, so they go where the developers go. The developers have moved onto GitHub and have effectively abandoned Google Code, therefore so has Google. Stubbornly maintaining their own service no one wants just breeds confusion and and a division of resources.
As the article says:
> To meet developers where they are, we ourselves migrated nearly a thousand of our own open source projects from Google Code to GitHub.
Nearly a thousand open-source Google projects have been migrated to GitHub already.
That all sounds weak to me. Google largely abandoned Google Code before all the developers fled to Github. One of the reasons people went to GitHub because it was clear that Google was no longer investing in Google Code. You're painting a picture where Google is just a passive entity that has no control over what developers do, it just meekly follows them around. That is hardly giving an impression that developers are a high priority to Google. If they were a high priority, Google would want them all using a Google service, and be willing to invest in that to keep them there, not cede them to third party.
Between this and gitorious, I forsee a lot of dead links in the future.
Hasty times we are living; a lot of useful information will be lost in the cloud age as services shut down. Of course, that information wouldn't probably have been available at all if it weren't for those services, but it's still sad.
A canary in the mine moment - relying solely on a single third-party for your hosting is always a risk - you are there at their grace, nothing more.
Migrate to Github? Hmm... they are becoming the defacto single monopoly platform - and no one seems to notice or care?
I think this will invite comparisons to, e.g., killing off Google Reader, but they won't be deserved in my opinion. Google Reader was the leader in its niche, and when they announced the shutdown everyone had to scramble to find alternative services before all their stuff disappeared. By contrast, this is a niche where the community has clearly moved on to other things that everyone acknowledges as being better in basically every respect. There's just no need for Google to continue to provide this service.
So the move to GitHub by Google's open source code is the next step? I kept hearing from people "in the know" that moving to GitHub was a real possibility a long time ago.
If you ever read any of my comments and down votes from Hacker News it was always this. The code on GitHub is a mirror and not an actual GIT repo that is accepting merges and being worked on.
This is true for some projects, like Chromium and golang, but AFAICT not true for the majority of projects on that page. e.g. the currently most recently updated repo that doesn't have a "mirrored from..." subtitle is [1], and you can go see all the pull request activity on it (though I'm sure there are also lots of code dump repos in that list).
Depends on the project. github.com/grpc is being developed github first (and accepting contributions), as are several of the projects on github.com/GoogleCloudPlatform.
I think we all saw this coming when Google started moving their projects over to Github away from Google Code. This is definitely the right move to make. However, I find it quite disturbing that Google is closing the service down entirely. Surely it would be more beneficial to keep the site in read only made for a good while longer given how deeply linked some parts of the web are to Google Code repositories. Perhaps somehow clean up the platform and hand over the reigns to the Internet Archive instead so it can be preserved and then 301 redirect any request to the archive.
Google really needs to get some kind of procedure in place for retiring their applications and services. Surely they realise that being the largest Internet company out there they have responsibilities to do the right thing by the millions that rely on their services daily? You can't just throw something away even if many moved on to Github and Bitbucket quite some time ago. Why not some kind of automated service that attempts to redirect to projects that have moved to Github and Bitbucket? Google has a trove of data, surely they can achieve something like that with pretty close accuracy and then use their manual approach for the projects that they could not automatically link.
While I've been sad to see a lot of Google projects come to and end I think this one is justifiable. I don't know of any active projects still hosted there.
I think my only serious concern is that even this year, I've downloaded several projects off Google Code. I am worried that a lot will be lost if they are not archived somewhere.
Here are a few: vim, waf, ttrss-reader-fork, gperftools, include-what-you-use, googletest and googlemock. All have had commits in the last few weeks, some in the last day or two.
These migrations would be much easier if we specified dependencies by content, not ___location. Obviously not Google's fault, just something to think about as we build future systems.
Anyone know how this will effect Google's Project Zero, or where they will post their findings in the future? GitHub doesn't offer the flexibility that Google Code has for marking issues as public/private which Project Zero relies on heavily.
Honestly, I thought plans to sunset it had already been put in place. I hate every moment that I want to check out a project and find that it's hosted on Google Code. The web has moved extremely fast in the last decade (and will probably move even faster in the next decade), and I can tell that I'm looking at 2006 code. There was never a push to give it the love it needed to compete with Github.
I hope there is some level of cooperation with those who want to archive it. It's important enough to be archived. The UX is not up to standards in 2015, though, so I will bid farewell to it with some amount of satisfaction and some amount of regret.
Does anyone know of a way to make the landing page at GitHub look less confusing than the default? That is the #1 reason I went with GC. I want first time users to see descriptive text not an activity log.
A redirect should send the right signals to search engines to move ranking with work. We actually do a lot of work at google to help people find things even after a move. (independent of our own projects/products, esp..)
This doesn't come off as much as a surprise, because there are better alternatives because google code stagnated and wasn't a priority. Google code still has very old looking interface (especially when contrasted to their active products like G+ and gmail), google code only declined because google didn't want to work on it.
This doesn't do google any favours, as with every product they launch I'll be asking myself if it's worth investing time or money into just for it to stagnate.
Hi, Sebastian from RhodeCode here. We do a fully-featured, behind-the-firewall SCM for Git, Mercurial and SVN - used by some of the world's largest organizations and also some well known Silicon Valley startups.
If you want to host your source code on your own (virtual) server then please contact us at https://rhodecode.com and mention Google Code - we are giving away free licenses for startups and smaller teams.
I was surprised to find my old project there from 2009: a simple lib for utf8 font rendering with OpenGL. I exported it into github, only to find that it never had any source hosted in source control - all my source was in a tarball inside "downloads".
I guess there are many authors like me who don't even remember they are hosting something there - it would be sad to loose all that code.
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.
I wonder if there will be a feed for the list of projects currently inside Google Code. I would very much like to grab the lot and preserve them inside searchcode.com
Anyone know if this is possible? Last time I checked it didn't have a public API other then the tracker and I was performing some rather ugly crawling/scraping to get a list of projects.
The email I received made me look at some long lost repositories of mine that I did while learning in school. It's always fun to be able to look back on work you did when you were less experienced.
It's unfortunate how transient the internet can be. How much information is created and lost over such a short period of time.
Sure, services like GitLab and BitBucket are cool, but GitHub is the superior option. Take away the fact that they are open source/have unlimited free repos, and there isn't much else.
GitHub has a superior UI, a waaaaaay bigger community, a great API, offers student discounts (5 free repos), and other goodies.
The GitLab UI is improving at a rapid pace, have you tried it recently? Is there anything you miss from our API? http://doc.gitlab.com/ce/api/ With GitLab.com your free repos will never expire.
The article gives the impression that they were combating some sort of systemic (malicious?) abuse. I don't doubt the statement, but I'm having trouble picturing exactly what they're going through. What kind of abuse do project hosting providers face on a recurring basis?
I find the consolidation in repository hosting surprising. It feels like it should be the kind of ecosystem that supports lots of competing repository hosting providers that cater to various niches. This may be because I quite like bitbucket.
Is there any alternative that supports issue attachments? That's the one feature that I really need to live for iTerm2 but github and gitlab don't support it except for images.
GitLab developer here, and happy to let you know that support for arbitrary attachments to issues and comments was contributed by a member of community earlier this month, and will be included in GitLab 7.9, due to be released on the 22nd :)
GitHub wins! I think it's good that Google indirectly admitted their service is not as good as Github, now they need to do the same thing about Google+. Google, you are an amazing company but sorry you can't possibly be the best at everything.
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.