Bidding farewell to Google Code
google-opensource.blogspot.com
google-opensource.blogspot.com
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.
“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.
What will happen, if those projects are not migrated because their developers have simply forgotten about them?
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.
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.
"What will happen to things that are hosted on google code, like jquery and the google font set? Thousand, if not millions of pages link to these directly - will they all be invalidated? "
They should be linking into Google's Hosted Libraries, which are separate and will continue AFAIK:
For instance if you want to file bugs for AppEngine the official way is through Google Code
https://code.google.com/p/googleappengine/issues/list
What are the plans on moving this and other issue lists for different Google products out of Google Code?
We have plans for this, we're just not ready to talk about them yet.
https://code.google.com/p/apsw/
Google Code did one thing very well - each project could have one wiki and issue tracker, but any number of source code repos. This is fantastic for projects where there are multiple parts - eg an Android client, an iOS client, multiple server parts etc. Github for example only lets you have one source repository per project, and as a result the wikis and issues are useless since they are almost always filed against the wrong sub-project.
Every startup I have been involved in over the last many years used Google for business (users, groups, office stuff etc), but then for code hosting we were forced to go elsewhere, needing yet another set of user accounts, groups, admin, billing etc. There was a ticket begging to let folks pay for google code, but it never came to pass. All the startups would have gladly paid, especially to avoid dealing with multiple accounts, sites and admin. Some features like the issue tracker were quite good. Heck you could even prioritise issues - something github still didn't have the last time I looked.
For an example of what this looks like: http://code.google.com/p/iosched
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.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.
> rather geeky and sometimes unreliable internet site called SourceForge
Wtf. SourceForge was for a long time very decent. It wasn't geeky nor unreliable, it offered CVS and later Subversion, web hosting, mailing list hosting, forums and downloads.
GoogleCode itself was geeky with its very basic "Wiki", but it had a leaner "GMail style" UI, with only basic features so newer projects used it over SourceForge.
"Bidding farewell to Google Code", that's a rather nice wording for closing down a web service. Please archive orphan open source projects to a read-only SVN/GIT repo or donate the data to archive.org.
It reminds us that more open source projects should host the code on their servers, e.g. using Gitlab. In some years SourceForge and GitHub may get closed down too. Some orphan project of great value may get lost of the digital dark age.
Would it be possible to get a list of all the projects inside Google Code? I would very much like to grab the lot and preserve them inside searchcode.com
Codeplex provides this sort of data and GitHub and Bitbucket have an API. I could write a crawler/scraper to do so but I would probably miss something.
Please don't let this become similar to Geocities and have it all lost forever.
Honestly, I'll probably just download the archive and take it offline. I don't want to think about this shit.
No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate.
What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth overhead) by publishing static files over HTTP. With the addition of a static export of the Google Code pages (mostly doable by crawling; some pagination issues would need to be worked out), Google could host the site going forward on a simple HTTP server without needing to maintain its server-side codebase. And Google is lacking in neither HTTP servers or bandwidth... Belated abuse complaints would remain a problem, but it's easy enough to delete things on request.
Google is obviously not legally obligated to keep the site up, and under current mores I suppose it's not socially obligated either. But I think that when the owning company continues to be highly financially successful and maintenance is easy enough, there should be a social obligation for some kind of archival.
Or at least redirect the subdomain to whatever Archive Team comes up with...
> Lately, the administrative load has consisted almost exclusively of abuse management.
They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.
As for the deep links, one of the Google Code devs did mention[1]:
> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.
His comment also contains a link to a wiki with more information on how to opt-in to this service.
http://google-opensource.blogspot.com/2015/03/farewell-to-go...
And this is an opt in service, nothing is automated. They could ,AT LEAST, partner with Github or someone else to have the whole thing automated... Seriously... the really want to put 0 money in that stuff,they don't give a damn.
There are seriously good projects that will be lost no question.Open source code is a community wealth,even in funky languages nobody use anymore. What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".
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
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.
Hell tools like https://code.google.com/export-to-github/ even exist.
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.
Actually closer to saying they are evil for destroying humanity's only copy of the recipe.
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.
If it's their archives, yes.
And if those are the only archives of Usenet in existence, then it's not Google's fault no one else cared to back it up.
(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...)
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.
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.
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.
Researchers would kill to have the balled-up scraps of paper that (e.g) Shakespeare threw in the trash.
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/
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 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.
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.
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.
> 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.
A part of me wants XKCD #1361 to come true.
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".
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.
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.
What do you really expect them to do here?
I guess robots will soon make decisions in Google too ;)
Perhaps they should stop offering products to humans then?
Seriously, why would _anybody_ use/recommend a Google product, when the expectation of "customer service" is "maybe some other poor schmuk on some poorly maintained and difficult to search Google group once had the same problem and they (or some other non Google person) worked out a fix and bothered posting it".
Yeah, you're not paying for it - it's worth exactly that when anything goes wrong. (Unless you're running 5 or 6 digits a month in Adwords spend, then they're _remarkably_ good at CS...)
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?
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?
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."
(a) a project's issues and wiki will be preserved in some form, in addition to the repo(s) themselves;
(b) code.google.com links will be redirected to this googlesource archive (for projects which have not opted in to the custom redirect thing).
If the answer is yes on both, then I'm a happy camper.
For (b), that's not a bad idea, but I don't know if we'd talked about that. I'll poke it in our bug tracker. Thanks!
I think Google and others should feel free to experiment, shut down closed experiments once the time is right, and not have to be obligated to spend resources on archiving things. As long as migrating is easy.
Admit failure, provide plenty of notice (like they're doing), and close up shop so resources can be spent on more impactful projects.
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.
Google Code isn't that great of a product, it has a small userbase, and there are many alternatives.
A party isn't a failure just because everyone eventually has to go home. It just means even successful things have ends.
Google Code had a few good years, and I am grateful that it happened. However, it did fail to win the software forge battle as the space heated up. It failed to evolve enough to keep up. It failed to keep the mindshare it built in those two initial years as Github and others blew past it over the next six.
So call it for what it is: A project that had two good years out of eight. Like many failures, there were successful moments and positive impacts on the greater community. But closing down due to losing constitutes failure.
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.
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.
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.
I don't see why they don't put stricter requirements on starting a project page or contributing instead of making this move.
FWIW. Mercurial can use Git as a backend which would ease the tension for those not enamored with it.
Github is really great for the social experience, but I've been debating switching over to GitLab for all of my development projects.
That's a bit disingenuous. GitLab purchased Gitorious--of course people are switching.
> “Gitlab is an excellent option….. not only more user friendly than Gitorious but also easier to install.”
Just say you're the best git host. Don't mention your competitor.
I'm going to go create an account on it now. Good luck, guys!
IMO not mentioning competitors and not providing a detailed comparison to competitors means that marketing is winning and the market is failing.
Kudos to gitlab for providing info which helps the market work. Opposite of petty! :)
GitLab is objectively better. They even list their reasons on the page.
If you disagree you could, you know, refute those points instead of dismissing the whole thing in a petty manner.
I don't think it is always bad to compare yourself, but it should always be based on facts. I think Wealthfront is a winner and they posted https://medium.com/@adamnash/broken-values-bottom-lines-3d55...
But I heartily recommend people look at Gitlab...
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.
Disclaimer: I am RhodeCode's co-founder.
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
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.
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:
https://github.com/moparisthebest/unlimit-code/blob/master/r...
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.
edit: more details of the debacle
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.
That you haven't yet is mindboggling.
(if you'll get in trouble for this please say so here or via sytse@gitlab.com and I'll remove it ASAP)
Gitlab is not.
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?
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
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.
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.
The second biggest project on gitlab has 36 stars: https://gitlab.com/explore/projects/starred
The 9th largest already has less than the 13 stars you mentioned on your personal project.
http://techcrunch.com/2014/12/05/to-get-off-russias-blacklis...
Since you used the words, "absolutely no reason", here's a counterpoint: as part of an anti-censorship hydra effort.
All X is Y.
At least one X is not Y.
^-- contradiction
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?
Maybe "generally no reason" would be better?
I'll drink to that :)
> However so far I have not hear any non nebulous reasons why an Open Source project should be on gitlab.
Heh, that's okay. I'm not here to convince anyone of anything.
That's not a reason to use the hosted gitlab version, that might be a reason to self host gitlab.
If I find a bug in GitLab I can feasibly submit a patch for it.
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'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.
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.
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.
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.
GitLab is faster in on some pages. The commit page probably is slower, but not by so much:
wget https://gitlab.com/gitlab-org/gitlab-ce/commits/master master.1 [ <=> ] 66.40K 382KB/s in 0.2s
wget https://github.com/gitlabhq/gitlabhq/commits/master master.2 100%[=====================>] 183.50K 662KB/s in 0.3s
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).
There are less integrations than GitHub but I would not say there is a lack of them https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/mode...
We think the issue tracker is good, working with labels can be improved but getting a milestone overview across projects is pretty sweet.
Availability of GitLab.com is over 99.9% at the moment http://status.gitlab.com/
Over 700 people have contributed to GitLab http://contributors.gitlab.com/
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.
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.
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.
Speaking as a European, it would be nice if you could keep it performant over here too ;)
We think the east coast of the US is the best compromise considering our user base. Can't solve speed of light :/
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.
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!
Figured I'd find it on the home page or under pricing or something.
But beyond that I dunno.
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.
I've changed the homepage according to your feedback in https://gitlab.com/gitlab-com/www-gitlab-com/commit/3a09175f...
https://about.gitlab.com/gitlab-com/ mentions that it runs the enterprise edition in the middle box
The pricing page is a hard one, we'll look into that.
Any idea how we can make the three blurbs on the homepage feel more like different products?
1. For the blurbs - remove the icons and add headers. Something like this - https://cloudup.com/cGSjRmrWGkU
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.
Compare that to Pull requests section of stash "https://www.atlassian.com/software/stash?utm_source=bitbucke...
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.
We'll try to improve the rest too and track it in issue https://gitlab.com/gitlab-com/www-gitlab-com/issues/271
Thank you very much for your kind comments.
I would love to see the option to move from Google code to GitLab.
And for the whole community's benefits, we need another choice other than GitHub.
I am.
For all the touted distributed version control advantages we now have one world global centralized repo. Yeah, yeah, I know you can clone it locally. But of course if all the issues, and testing, and build tools are tied to Github. Isn't it a bit disconcerting?
Maybe I am just paranoid. And not saying that Google code was going anywhere, I saw more and more projects switch to Github and Google code receiving less and less attention.
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.
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.
What to do about it?
* Use other would-be global centralized repo to create competition, eg Gitlab.com (or if you demand 100% FLOSS, maybe notabug.org though it is a very long shot for achieving such centrality)
* Discount centralization benefits and self host, eg using gitlab, gogs (which notabug runs), kallithea, or various other FLOSS code hosting applications
* Work making migration between hosts easier (eg issue and other configuration import/export)
* Work on harder problems of federation among code hosts; distributed bug trackers have been reinvented many times but never taken off, but maybe just the right approach hasn't taken off yet, or maybe there is something in federated social web approaches
* Do one or more of the above and treat Github as marketing and backup for your main platform (or vice versa), analogous to what the indieweb people recommend for dominant social networks http://indiewebcamp.com/POSSE
4 years ago someone might've said the same about Google Code.
Expectations change, and then Github might go away.
http://git.suckless.org/ works
issue list? the mailing list
pull requests? which are imo quite painful in github still, are just patches sent to the mailing list. no login or special tooling required.
kiss,
There are several compelling (also free) alternatives (GitHub/etc.), so this isn't like Reader (which had previously killed a lot of viable/non-free competitors in its market).
They even have automated migration setup.
Looks pretty well done.
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.
Kudos, Google!
I'll be moving my code and forking a few analytical projects I use appreciate but I hope they would leave the site up in read only or archive mode for longer then a year as i'm sure many authors have moved on and may not even be aware of this change.
Google is never the safest place to store anything, unless it's your personal data. Google sunsets products constantly.
My point is that Code has been running for quite a while, and at one stage it probably did look like the safest way to keep a project online. Can't blame people for choosing it earlier on.
I'm expecting Google to purchase GitHub next in order to improve its deficiencies. In particular code search, which is really poor. Google Code search is good, so Google can then apply its search expertise "in-house".
https://code.google.com/p/chromium/codesearch
Maybe it's just habitual, but I prefer the issue tracker on Google Code as well.
"How to export Google Code issue tracker data to other services" https://code.google.com/p/support-tools/wiki/IssueExporterTo...
Here is an example of a project we imported from Bugzilla:
https://github.com/translate/pootle/issues?page=47&q=is%3Ais... (all issues below id ~3200 are imported).
Here is the tool I wrote for the occasion:
The chromium bugtracker is very active and the chromium developers are very open and helpful on it.
So basically this is our 5 year warning on GitHub closing down !?
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.
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.
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 :)
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)
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.
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".
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.
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.
google "git sync mirror" and a bunch of solutions appear.
If only we had some sort of version control system that didn't rely on a master copy somewhere, a 'distributed' version control system if you will...
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.
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.
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).
Thanks, Google. It's been a good run!
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 ?
The App Engine UI is getting an overhaul; App Engine as a product is probably going to stick around.
Yes, SourceForge(t) is still around, but with the talk of them injecting adware into downloads, I'm sure many wouldn't use them.
This leaves, what, BitBucket and running something yourself?
As a software developer is a tool that we use all day.
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.
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.
If you are looking for a good list of what's out there check out this stackexchange post: http://softwarerecs.stackexchange.com/questions/3506/self-ho...
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.
Disclaimer: I am the forker/owner of srchub.
https://secure.phabricator.com/book/phabcontrib/article/feat...
https://github.com/GoogleCodeExporter?tab=contributions&from...
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?
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.
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.
https://github.com/GoogleCloudPlatform/oauth2client and https://github.com/GoogleCloudPlatform/kubernetes, just to list two that I deal with.
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.
https://github.com/google/gumbo-parser
(Ironically, when posted on Hacker News, one of the first comments was that it was ironic that it was posted to GitHub and not Google Code:
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.
Sure I can move my own old projects, but there is plenty of stuff out there that will be lost.
Part of what makes modern coding efficient is being able to not just look up working libraries but also to find old solutions to similar problems.
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.
Or just have a good Readme.md and hope people scroll down.
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.
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 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.
------------
It's not about Mercurial vs Git.
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.
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.
It's unfortunate how transient the internet can be. How much information is created and lost over such a short period of time.
GitHub has a superior UI, a waaaaaay bigger community, a great API, offers student discounts (5 free repos), and other goodies.
This is not the right way to bid goodbye to a lot of open source code that will disappear from the world forever.
Perhaps Google could partner with Internet Archive to preserve this history before it is lost forever?
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?
You don't say?
After pulling the plug on all the products I liked, I'm worried too.
I don't really want to have to redo the whole wiki manually :(.