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.
how do you (google) get away with being such asses? i know a bunch of developers will come to your defense, and say things like it is a free service, but it's not really, because for google, users are the product, and you guys have developed a rep for constantly shutting those users down. switching costs are very real, and people just don't trust you anymore. i don't care about google code in particular, but i hate google by this point. just hate you.
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.
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.
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.
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..
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.
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.
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.
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?
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.
> '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 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.
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.
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?
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 ...)
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
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.
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.
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.
"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:
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.
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.
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.
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!
> rather geeky and sometimes unreliable internet site called SourceForge
Wtf. SourceForge was for a long time very decent. It wasn't geeky nor unreliable, it offered CVS and later Subversion, web hosting, mailing list hosting, forums and downloads.
GoogleCode itself was geeky with its very basic "Wiki", but it had a leaner "GMail style" UI, with only basic features so newer projects used it over SourceForge.
"Bidding farewell to Google Code", that's a rather nice wording for closing down a web service. Please archive orphan open source projects to a read-only SVN/GIT repo or donate the data to archive.org.
It reminds us that more open source projects should host the code on their servers, e.g. using Gitlab. In some years SourceForge and GitHub may get closed down too. Some orphan project of great value may get lost of the digital dark age.
If any open source projects want to self host with GitLab CE we will be glad to provide free consulting to help them migrate and provide a free instance. Contact me at sytse@gitlab.com to get started.
I haven't read the source article, but SourceForge at some point was real slow. Like, it would takes minutes alone to Log In at SourceForge, let alone checking out SVN repo. Accessing website hosted on SourgeForge was real slow too. I think during that year (not sure which year), tons of projects migrate either to Google Code or to GitHub. It was later that sourceforge improve.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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 :)
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.
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.
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.
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.
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...
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
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.
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.
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.
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.
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.
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?
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.
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?
"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.
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.
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?
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.
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.
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.
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 :)
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.
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.
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.
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.
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...
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.
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.
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.
427 comments
[ 5.2 ms ] story [ 363 ms ] threadWired 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.
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.
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.
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.
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.
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.
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.
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.
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.
Glass is clearly very much alive.
Glass is still very much alive.
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?
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.
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.
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.
In the end, they are a for-profit business. Not a charity.
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.
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.
code.google.com was around for 7 years. What more do you want?
It was launched at OSCON in 2006.
'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?
That's because users paid for it.
Google gave the world high-quality, free open source code hosting for eight years. I don't see how that's anything but a net positive.
https://en.wikipedia.org/wiki/EComStation
I'll give you three guesses as to how much those companies still running OS/2 were paying for support in 2006.
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.
The large companies are made of small clueless people just like every other company on the face of the Earth.
(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.
“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?
E.g. MIT:
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?
(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 ...)
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? "
https://developers.google.com/speed/libraries/devguide
They should be linking into Google's Hosted Libraries, which are separate and will continue AFAIK:
https://developers.google.com/speed/libraries/devguide
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
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.
https://microsoft.github.io
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.
[1] https://github.com/google/trace-viewer
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:
https://news.ycombinator.com/item?id=6210282
There are several compelling (also free) alternatives (GitHub/etc.), so this isn't like Reader (which had previously killed a lot of viable/non-free competitors in its market).
They even have automated migration setup.
Looks pretty well done.
Kudos, Google!
I 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.
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.
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:
https://github.com/jleclanche/bugzilla-to-github/
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 !?
Thanks, Google. It's been a good run!
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.”
"Better than GitHub"
That's quite a motto.
Just say you're the best git host. Don't mention your competitor.
I'm going to go create an account on it now. Good luck, guys!
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
http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html
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.
:)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.
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.
[1]https://github.com/samrocketman/gitlab-mirrors
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...
------------
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.
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.
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.
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?
https://www.youtube.com/watch?v=oCZMoY3q2uM