Hacker News new | past | comments | ask | show | jobs | submit login
Bidding farewell to Google Code (google-opensource.blogspot.com)
880 points by cdibona on Mar 12, 2015 | hide | past | web | favorite | 409 comments



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.

Wired did a nice story about Github that touches on the shutdown: http://www.wired.com/2015/03/github-conquered-google-microso...

I'll be hanging around answering questions, but the short form of 'why' is that it just isn't used much anymore, ourselves included, in favor of Github or bitbucket.


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.

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.


Google Code already has an option to flag a project as moved. From your project: Administer > Advanced > Project Moved

For an example of what this looks like: http://code.google.com/p/iosched


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.


They said they would on the blog post

    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.


They also should be returning a 301 and the new URL so crawlers can follow it and delete the old site from their records...


Why would they make it easier for someone else to properly index the web? They've got that covered.


Thanks - I never knew that existed. The admin ui and result aren't particularly nice sadly.


> 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.


You can reference issues in any repo with "ref username/repo#73"


Hi cdibona! I'm primary on-call at GitHub today, and I wanted to say thanks to everyone that worked on https://code.google.com/export-to-github/ and worked with us to load test it before this announcement. It's really cool to see so much work put into making it easy for folks to easily move their data.


While true that no one uses Google Code. Every now and then, I bump into some obscure but a little useful project being hosted on Google Code. Maybe, makers of those projects have grown out of them and don't wish to put any more effort but still, there is a bit of value, I am able to derive from them.

What will happen, if those projects are not migrated because their developers have simply forgotten about them?


We are planing on taking the majority of these legitimate, open source, 'abandonded' projects and putting them up in cold storage in a git repo on googlesource.com


Will it keep existing deep links published in books and research papers from breaking? What prevents Google from setting the whole site into read-only mode as-is? Keep it working as it does now and disable changes.


Was that a rhetorical question--how could any third party possibly prevent deep links from breaking?


What is the criteria for "legitimate"? A project useful for me may not be "notable" enough for most to consider "legitimate".


Presumably, not abusing Google Code as a hosting site for pirated content.


Or for personal data. I've seen some people using Google Code as a pseudo-Dropbox. Clever, but ultimately not what the service was intended for.


Thanks for this, Chris.

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.


I suggest letting developers to specify projects they find useful to be included in this cold storage.


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.).


If someone wants to make an actual serious effort on this, feel free to contact me.


[deleted]


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 ...)


Agreed. and that's what the DMCA was ostensibly intended for anyway. Someone who claims copyright could always make that claim in the normal fashion.


Perhaps archive.org will take it upon themselves to archive all the projects.


This is the one thing I'm a bit worried about. I've downloaded several Google Code projects this year so far alone.


Find those useful projects and post them on Bitbucket or GitHub


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.


It's true that Google does not use Google Code for any coding project anymore, but it's still used as a support interface.

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?


PM on App Engine here. We'll continue to be using (and monitoring) the Google Code issue tracker until we have a robust alternative available.

We have plans for this, we're just not ready to talk about them yet.


Is this a plan just for AppEngine or for all other Google Products that use Code as an external Issue Tracker?


Not sure about other products


One thing that might be nice to do - if you see a project with high recent download stats (I'm sure there are a few) but their developers seem to have abandoned them, will you please do a courtesy backup to github, or perhaps notify people who starred it that the owners didn't mograte it to GitHub and the data will be lost unless someone does.


Have you considered that Google Code hosts amount of code that is related to the research papers and are not actively maintained (many probably since uploading). This wast valuable resource will be gone forever.


Mabe someone will finally get it. You can't trust third-party sites to keep your stuff up. Host it yourself if you want to be sure it's around somewhere. Use free hosting as a backup plan.


Looking at my own and others actual behavioral patterns, I'd say the opposite is more closer to the truth. Dead links often go to someone's old server that they at some point probably planned to keep online forever. But you are of course right in that redundancy is a good thing!


From the comments

"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:

https://developers.google.com/speed/libraries/devguide


That's Google CDN, not Google Code, as the follow on comment says


Apparently it's called Google APIs or something

https://developers.google.com/speed/libraries/devguide


This wired article tries to rewrite the history:

> 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.


Hi Chris,

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.


Would git-annex (avaiable on gitlab.com) together with vcsh and mod-organizer cover you?


I can BARELY figure out how to work Git itself, I'm guessing combining it with 3 other systems is not going to be a good idea.


I've just remembered that github does offer access to its repositories via the svn protocol. what aobut that?


Doesn't github provide svn access? Bitbucket too, I think.


Does it? I dunno.

Honestly, I'll probably just download the archive and take it offline. I don't want to think about this shit.



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.


Consider it done. http://i.imgur.com/Xdmlj6v.jpg

In all seriousness, though, I started my own open source project hosting website back in the day. It was the first to offer public Mercurial and Git hosting.

Google Code existed then and the interface and functionality has not really changed since I released the first version of the site.


As someone who used Google Code a while back (and did indeed end up moving to Github): it's a pity it had to end, but thank you for hosting it while it lasted. In its day, it was a service of unequaled quality.


I had my hopes up that you guys would update Google Code to be more of a contender with GAE and Compute integration.


I have a secret desire to reuse the code domain in this manner.


Well...it was a secret.


Thank you for taking questions. Can you give me a rough idea when you'll have the bitbucket migration tools in place?


Would you migrate Chromium Project to Github?


What will happen to the bug trackers of large Google projects like android, chromium, app engine, etc?


[flagged]


I might be feeding here, but the lesson is that you can't count on things Google releases to be around very long. Even APIs for popular products, like Google Maps. Just don't expect anything they release to have a long shelf life. It's annoying and it sucks, and it is now laughable when they tag things with phrases like "free code hosting forever" and so on.

For them to change, they'd have to either: 1) Support everything into eternity, which given their propensity to release new things frequently would grow to be impossibly expensive, or 2) Be more disciplined in what they release, so that it can be supported in perpetuity. I don't see either happening, so we end up where we are now. They have to keep innovating or they'll stagnate and die.


They kind of get a bad rap for this because of how large and visible they are. The funny thing is that many of the people here on HN have worked on projects that had very finite lifetimes as well, often closing them down for some of the same reasons.

Someone has to invest the time and money to keep services running, even if only limping along. Google likes to experiment and test the waters. It's part of why they've been so successful. I hope they keep killing off their underperforming/underused services so they can keep on pushing other things forward.

However, closing down stagnant projects is very different from locking down access to previously open APIs (Google Maps). Since we're discussing the closure of Google Code, I won't get distracted with that controversial topic.


I also find a certain level of humor in the oft-espoused "release and pivot" ideology, accompanied with the pleas for mercy found in these Google product shutdown threads. What is different? Why is Google not supposed to release and pivot like everyone else?


It is puzzling, but I think their rapid ascension has led to some people setting their expectations for Google too high. Others seem to hold them to some golden moral standard (of their own design), for some reason.

In the end, they are a for-profit business. Not a charity.


Because at some point you stop being a feature of the landscape, and you become the landscape - or a big part of it, at least.

That's where GitHub is now. If GitHub closed in the same way, that would be... unfortunate.

That seems to be where Google Code was trying to go. For whatever reason, it never quite made it.

But if you're part of the scenery - and Google Code was, for a while - and not just a shack hardly anyone visits, a burden of responsibility goes with that.


At least from my perspective, the problem is that Google sometimes releases into already-existing fields at a price point no one can compete with, absorbs the entire market, then pivots away. This is pretty destructive behavior, and I think fundamentally different from entering a field in which you intend to try to run a business (as opposed to subsidizing your entry into the field with profits from elsewhere in the company in order to undercut current players).


Except in this case they didn't absorb the market and then pivot away. The market moved away from them and consequently they shut down a service that nobody really uses anymore.


Sorry, should have made it more clear that I wasn't talking about Google Code specifically, but was responding to the parent comment regarding "release and pivot".


I think it is because of the side effect (can it be called an externalized cost?) to developers wanting to use existing open source code and not being able to find it. Google code is used by a lot of people.

Whereas an early start-up with 100 users selling a product with not much lock-in can pivot without too much side effect. The users know they are dealing with a start-up and may expect it.


Yes, and the projects that people on HN have worked on that have had very finite lifetimes get a very negative reaction on here too, for much the same reason. In fact I regularly see people suggesting that it reflects badly on startups as a whole and that you shouldn't trust them with your data whenever one pulls a stunt like this.


> Support everything into eternity

'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?


> IBM supported OS/2, released 1992 and a marketplace flop, until the end of 2006.

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.


> '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.


And for OS/2, IBM even allowed it to live on by licensing it to a third party:

https://en.wikipedia.org/wiki/EComStation


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.


you can't count on things Google releases to be around very long

code.google.com was around for 7 years. What more do you want?


FWIW, it was 8+ years :)

It was launched at OSCON in 2006.


Why limited to google? You can't count on anything being around forever. But that is hardly revelatory.


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.


> partially because it's assumed that those companies understand the far-reaching consequences of their actions

The large companies are made of small clueless people just like every other company on the face of the Earth.


There is two alternatives that I can think of.

(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.


This is the problem with proprietary cloud services. As long as they're hosted by and run by a single company, you can't be sure they'll stick around.


Yeah, like http://www.codehaus.org/ is living forever? ;-)


Edit: The parent comment was flagkilled, but he was ranting about how Google should be expected to keep Google Code (and their other failed services) on life support indefinitely out of the kindness of their heart, because negative public perception.

This is pretty ridiculous. It is a free service, sustained only by how long corporate wants to foot the bill. This is why it's so important to keep in mind how sustainable your dependencies are longer term (if having to move away from them would be such a big deal).

Not only that, but Google Code lost the mindshare battle and hasn't been getting much development attention for some time now. It has fallen way behind, is now sub-par, and there has been a mass exodus of projects away from it. It had a nice year or two, but it's time to put it down.

It's simple: Stop wasting developer manpower, money, and time on something that no longer offers much utility. Close shop, figure out how those resources could be better spent doing things that are useful.


Honestly, I think he was right. Google has a really bad image problem right now where lots of people don't want to get involved with their projects because Google will most likely kill the project just like Reader and Glass.

See my couple of wasted Google Glass devices that will never see an Android update again. Do you think I'll ever buy a Google Android product after they wasted $3k of mine? Do you think I'll buy any more of their tech device blunders like cars or thermostats or other devices? Likely not. It's well established they'll just drop them soon after release anyway.

They are getting the same reputation for software services. There are lots of startups that would have been happy with Reader's usage numbers besides, so they aren't even making decisions everyone would agree are good kills.

With my Android apps, any time someone sends me a bug report or a complaint, I refund them immediately and thank them for the feedback. Does this make me the most money? Hell no. But I have a lot of friendly users who email me constantly with improvements and who aren't mad I'm ripping them off or screwing them over. That's worth a lot too. Google is saving money to screw over users with this Google Code decision and it's definitely not one I agree with.


> Honestly, I think he was right. Google has a really bad image problem right now where lots of people don't want to get involved with their projects because Google will most likely kill the project just like Reader and Glass.

Again, these are two very niche projects. Reader was a niche within a niche. Glass was an experiment that a tiny subset of the population ever even touched first-hand. It never even reached a "1.0".

As early adopters and as technologists, it's easy for us to get upset when our favorite pet project gets killed. But in the end, Reader failed to get any kind of traction beyond its niche. Glass ran into a buzzsaw of negative perception, legislation, and media twisting, in addition to technical challenges. The lessons learned from Glass will be applied to present and future efforts.


Killing reader was a bad idea imo. Yes, it was niche but it was social, attracted influencers and measured relevance.

Glass is clearly very much alive.


Killing reader was a terrible idea. That cut my daily google usage in half and was obviously a key social and relevance asset.

Glass is still very much alive.


> Killing reader was a terrible idea. That cut my daily google usage in half and was obviously a key social and relevance asset.

It sucks for our niche, but ultimately Google Reader was a product that didn't have any appeal beyond said tiny niche. The original goal was to make RSS more accessible beyond technologists, but it failed to reach any kind of mass appeal. Some of this was more to do with RSS/Atom feeds having some ergonomic issues that weren't solved before the social media frenzy took hold.

Failure is when results don't meet expectations, which is what happened to Reader. I don't fault them for closing it, despite it being inconvenient for me to switch. What does a for-profit company have to gain by dumping time and resources into a failure whose window of opportunity has passed? Some goodwill from a tiny, miniscule subset of their userbase?


If you joined Google's Glass Explorer program (twice?!) expecting anything but a beta-level device with a short shelf life then more fool you. I don't think they could have been any more explicit about the goals of their program.


I think his point stands though, that Google cannot be trusted to keep services going. This will adversely affect their appeal in many minds, including mine. I have used Google since about 1998 (?) and you'd be amazed how many products have come and gone in that time.

Apologies for the rantiness of the post below, it isn't meant aggressively, just more frustration at no apparent direction seen within the Googlesphere.

The removal of features that people use with no warning and non-implementation of features immediately after release is really really annoying. It makes their stated goals ("index everything") meaningless/temporary/untrustworthy, and dissuades me from buying services from them. Freeloaders use their products a lot (I do!) but I would think twice about ever ever ever paying for software from them, or for a service because you have no idea when it'll shut shop. Even products they still produce appear to be completely disjointed (see the Play Books app on Android and the complete disparity found with their web interface...)

Here's a list of annoyances in products they've released to much fanfare, then apparently just not bothered developing anymore:

1. Google+, yes all of it. And I use it! (where is it going now that Gundotra has left?)

2. Maps: My Maps now isn't integrated into the Android app (they spun it off??), Latitude is gone, Google Local is gone but apparently still there (you can read reviews but hidden and secret GUI controls are now the order of the day for working out how to do anything in Google Maps)

3. Google Drive desktop client: will it ever tell me how far it has got in uploading a massive file? The web client does, the desktop one doesn't. Surely that's an OBVIOUS feature in a filesync utility. Don't ask about their promised Linux version. Couldn't they write it in Go or something?

4. Google Hangouts Android client: the forced update from Talk with the removal of features (is someone actually online? a presence feature seen since MSN Messenger that somehow escapes Google's notice)

5. Google Chrome OS: why is it even here? There was much talk of being stiff competition to Windows and OSX but it's like an Etch-A-Sketch toy operating system. I think TinyCore Linux does more?

I'll stop now because it's coming up to lunch time and I'll get indigestion.

I am a big fan of Android, but their incessant removal of features within their core apps and then rereleases of similar-but-ever-so-slightly-different apps ever year at I/O is getting wearisome.


Although you are correct, it's more a matter of perception / PR image. If we are looking at Google that shuts down pretty popular projects (Reader, Code, and now G+ seems to be shifting) or pretty innovative projects (Wave, Glass) then how should we feel about becoming dependant on/involved in Google products? What if Gmail switches to paid-only model? What if the next-big-Google-thing will be closed down after a year, again? What if free Google Apps will close down, and only paid version exists? What's the point of getting involved into any free Google stuff? What's the point of using Google at all?


> Although you are correct, it's more a matter of perception / PR image. If we are looking at Google that shuts down pretty popular projects (Reader, Code, and now G+ seems to be shifting) or pretty innovative projects (Wave, Glass) then how should we feel about becoming dependant on/involved in Google products?

You just listed a bunch of projects that failed to get traction or lost mindshare battles. I expect an innovator to move on from failures, which is what all of your examples are. Reader: Failure, Google Code: Failure, G+: Failure, Wave: Failure. The reasons for each failure differ, but said reasons are irrelevant to this discussion. The fact is that Google attempted something, maybe enjoyed a little bit of success, but the results didn't meet their expectations. Rather than continue running these things with skeleton crews (to what effect?), they've done the right thing and closed them down.

The only exception is Glass, which was an experiment that already is impacting other current and future products. It never had a guaranteed future. It never reached consumer "1.0".


> I expect an innovator to move on from failures

That's great if you are an investor or employee, but if you are a user it kind of sucks.

Google just needs to be up front about it (and maybe they are): We make no commitment to supporting this application or maintaining it as is. We might make radical changes, we might shut it down. If we do shut it down, we'll warn you at least 9 months ahead of time.

I'm not going to invest much in those applications, but others might.


I gotta be frank here: If you expect anyone in the tech world, Google or otherwise, to support a non-paid product past the point it's obviously declining in user base (IE obvious to not just internal users, but to external ones), for more than a few years, you are just not going to use anyone's products ;)

Google code is mostly irrelevant to this calculus, because it was not ever meant to make money for anyone, but i think you are a little harsh here.

Don't get me wrong, as a user, I would love to have the stuff i want to use supported forever. But it's unrealistic.


The problem is that Google represented itself as an altruistic supporter of open-source. People trusted it because it deliberately cultivated the impression of being more responsible than the default 'duh capitalism' mentality it now represents.

Google is suffering the reputational damage it deserves - not because it is now behaving any differently from other corporations but because it has betrayed the promise that it would.


> Google just needs to be up front about it (and maybe they are)

Nobody launches a new product and guarantees "If this doesn't work out, we'll keep it around indefinitely on life support". You don't start a new effort expecting failure. If it doesn't end up working out, it'll be closed down. Google's failures are just a lot more public than whatever side business many of us may take a stab at.

This isn't unique to Google. Failures need to be learned from and culled. We as a small business/startup oriented crowd should understand that more than most. I've had to kill off more projects than I'd like to admit because I didn't want to spend the time/money on what I perceived to be failures.

Not that failure is bad. Like Google, I've learned a ton from my unsuccessful projects.


In fact, many vendors, especially in the enterprise market and physical goods, stand behind what they sell through their products' lifetimes. As I mentioned elsewhere, IBM supported OS/2, a marketplace failure, for ~16 years. Buy a washer from Sears; even if that model doesn't sell well, they will support yours.

Consumer and 'free' software is the exception, and it's a recent exception with rapid release schedules. It's just shifting the costs from the vendor (maintaining old products) to the consumer (changing/upgrading).


> Consumer and 'free' software is the exception, and it's a recent exception with rapid release schedules. It's just shifting the costs from the vendor (maintaining old products) to the consumer (changing/upgrading).

It's important to note that in many cases, the vendor pays for what is otherwise a free service (Reader, Wave, G+). In the case of some services, they may gather some data from which they can profit from, but that doesn't always pay the bills.

So yes, the customer may have to switch services or upgrade, but unlike enterprise software, they aren't paying four to six figures to use said services.


I don't think "free" has anything to do with it. In fact, the reason this is not a big deal is specifically because there exist at least 2 superior free options.


This is one service that needed to be shut down.


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..


Ugh.

No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate.

What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth overhead) by publishing static files over HTTP. With the addition of a static export of the Google Code pages (mostly doable by crawling; some pagination issues would need to be worked out), Google could host the site going forward on a simple HTTP server without needing to maintain its server-side codebase. And Google is lacking in neither HTTP servers or bandwidth... Belated abuse complaints would remain a problem, but it's easy enough to delete things on request.

Google is obviously not legally obligated to keep the site up, and under current mores I suppose it's not socially obligated either. But I think that when the owning company continues to be highly financially successful and maintenance is easy enough, there should be a social obligation for some kind of archival.

Or at least redirect the subdomain to whatever Archive Team comes up with...


Google hates anything that requires a human's touch, and per the article:

> Lately, the administrative load has consisted almost exclusively of abuse management.

They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.

As for the deep links, one of the Google Code devs did mention[1]:

> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.

His comment also contains a link to a wiki with more information on how to opt-in to this service.

http://google-opensource.blogspot.com/2015/03/farewell-to-go...


> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.

And this is an opt in service, nothing is automated. They could ,AT LEAST, partner with Github or someone else to have the whole thing automated... Seriously... the really want to put 0 money in that stuff,they don't give a damn.

There are seriously good projects that will be lost no question.Open source code is a community wealth,even in funky languages nobody use anymore. What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".


On what planet is shutting down a service, with months and months of notice, evil?

I get it, we all hate Google on HN (for reasons unclear to me) but this is ridiculous. If these projects are truly important than donate some time and move them over yourself. To demand that google invest time and resources into the migration of these migrations or to keeping this running forever is just silly.

Hell tools like https://code.google.com/export-to-github/ even exist.


Shutting down Google Code is equivalent to destroying a storage full of handwritten articles, some of which exist only in a single copy and some of which are incredibly valuable.

Why valuable? For example computer science researchers had been using Google Code to host supplement code for their research publications for years now. These repositories are not maintained by these researchers any more, yet the code some times is incredibly valuable, because it allows to reproduce research results. The reason why researchers were using Google Code, is because it was supposed to be as stable as the underlying company. Yet now, in 10 months, these repositories will be destroyed.


If the code is that valuable, then perhaps they should put some time into maintaining the code, moving it to another provider, or convincing somebody to pay for hosting.


Example. A cancer researcher, publishes a paper in Nature Genetics. Like this one: http://www.nature.com/ng/journal/v42/n3/abs/ng.522.html

In that paper she publishes a link to a Google Code repository as supplement materials. For example, in the aforementioned paper there is a link to the following repository: http://code.google.com/p/glu-genetics/


Given she published the paper and link, she should either a) take responsibility for the general availability of the materials, and b) make sure that if people email her for the materials (after finding that they're not available on Google Code) she shares them.

Don't get me wrong, I'm all for retaining the materials and knowledge, etc etc. I'm just having a hard time understanding why you expect Google to do the work and maintain it? What if she uploaded her materials to Megaupload, or any of the hundred other filesharing sites - would you hold them to the same standard? Why doesn't the journal that published the paper (which, has a revenue stream) host the material, given that it directly supports their work?


Megaupload did not hold itself out as a repository for original work.

Megaupload is not run by Google, with the stated mission of organizing the world's information.

Megaupload is bankrupt. Google is one of the richest technology companies in history.

This is not Megaupload throwing away its hoard of 90's B movies. This is Google, knowingly and literally throwing away coding history. We don't even know what might be thrown away.

What if some currently unknown researcher wrote his first code and uploaded it to Google code and forgot about it, and turned out to be the next Zuckerberg or even Turing?

What if some valuable research that was entrusted to Google from a deceased researcher suddenly disappears?

There are likely many more unintended consequences stemming from such an act, and I don't think we should give Google a pass, especially since Google controls possibly the largest collection of computers on the planet. (besides, source code tends to compress pretty well!)

Seems like the least they could do is stick it in an 'unlimited' Google Drive and lock it as read only.


Great example. In 2-10 years from now, someone will want to find that repository.

Does anyone know of an effort to maintain this, like is done with sequencing data at the NIH? Something like PubMed Central?

I have first hand experience with this on the biology side, looking for reagents or even protocols from a 10 year old paper...and coming up completely dry. It's kind of a travesty, but the world collectively shrugged.


Handling and archiving supplementary materials should be the responsibility of the journal (like distributing and archiving the article itself). They should discourage linking to 3rd party websites where the author published his/her work.

I'm pretty sure that Google Code had a TOS where they stated that they don't guarantee that your repository is safe there forever.

There could be several reasons for closing a repository including Google going bankrupt. The availability of a scientific article should be much longer (ideally infinity) than the lifetime of any company.


It may not be valuable to the author. That does not mean it's not valuable to some future searcher.


Right.

Researchers would kill to have the balled-up scraps of paper that (e.g) Shakespeare threw in the trash.


Are we supposed to believe that Google does not understand the value of CITATIONS and PERMALINKS?


In actuality, I've found most HN users seem to love Google. To the extent that almost any criticism of Google gets downvoted to death.


Case in point, this comment just dropped three points. ;)


Don't sweat it. Don't let imaginary internet points make you feel bad... or good.


FWIW, Google were happy for a lot of other people to invest time and resources into putting their projects there in the first place - you don't think there's some reasonable expectation that Google would expend some extremely minimal resources at their scale - to ensuring those peoples effort wasn't wasted/lost?

Having said that, I'm not part of any movement to "demand Google do something different", but I've been a longtime member of the "Warn friends/family/colleagues about the dangers of participating in Google services in any way that'll have any downside when they close it down, because they've got a strong track record of doing that" movement.

If _I_ were the person making this decision at Google, my announcement would have been more along the lines of "blah blah shutdown blah blah apologies/excuses blah blah, so we're going to donate enough to archive.org to ensure everything on code.google.com gets archived permanently, and automatically redirect all future code.google.com requests to that permanent archive".


> On what planet is shutting down a service, with months and months of notice, evil?

The current planet? Open source projects have a lifetime of years so five months is not that long in the scheme of things. People put there code on there and participated (providing Google content that they were able to use and drive traffic) with the expectation that it would be there for the long term.


This is a rather watery definition of evil. It is fairly close to saying a restaurant is evil for not keeping a menu item you like.


Would it be ok for Google to delete Usenet archives?

Or a library to burn down its own buildings? Or Google to delete all scans of old books?

History matters, because citations to "old" research/code may become more valuable with new requirements and research. Surely a company that "organizes the world's information" needs no explanation of these topics.


>Would it be ok for Google to delete Usenet archives?

If it's their archives, yes.

And if those are the only archives of Usenet in existence, then it's not Google's fault no one else cared to back it up.


Somebody else did have a usenet archive - Google bought them, mashed up a bunch of other nn-usenet Google stuff into it, then let it bitrot until it was effectively useless, and then removed the only search features that worked...

(Admittedly, if I recall correctly, Dejanews had already gone broke trying to maintain that archive before Google bought it, so arguably Google didn't kill it, they just bought the dying corpse and kept it animated in a zombie-like state for a decade or so past it's natural death...)


And in the intervening years, no one running a news server thought to back theirs up, no one crawled Google and made torrents?

This is software, not ancient manuscripts written by scribes on now crumbling vellum - there is no excuse for there to be one canonical copy of anything. Every pornographic movie ever made has multiple redundant backups on decentralized peer to peer networks and darknets.

I understand the importance of maintaining references, but realistically, expecting URLS to be permanent is shortsighted at best, unless you own that domain and the server it's on and expect to have the money to keep the rights to it in perpetuity. You can't expect a third party host to be willing to keep the servers on forever.

But as far as the historical record and the data itself - Google's given warning, people can move their data or lose it. Fork and move on.


Why would they run their own Usenet archive? Google had the Usenet archiving business sewn up, and by the time they started showing signs of being untrustworthy it was too late and much of the 80s and early 90s stuff only exists in their archives. (Oh, and as a side note apparently a lot of the interesting porn from that era has been lost to history too.)


Trusting any one service to be the bearer of internet history carries the same risk, that the service can go down at any time, and take its data with it. If this information is to be preserved it has to be hosted somewhere, preferably multiple places. If it's to be accessible online, then someone has to pay for the servers and the power and the maintenance.

Google's an ad company, they don't have an obligation to be the arbiters of human history, whatever their slogans might be regarding 'organizing the world's information'. They care about the information that makes them money.


Porn is never lost... Only siloed. Some old guy in Missouri has ALL of that.


> It is fairly close to saying a restaurant is evil for not keeping a menu item you like.

Actually closer to saying they are evil for destroying humanity's only copy of the recipe.


After shouting loudly they are going to destroy it and waiting months for anyone to come copy the recipe.


It would be the open-source world's equivalent to Geocities shutting down. There are still times when I'm trying to search for something (usually some obscure programming or hardware hacking topic) and the only source of information was a Geocities site. I can't imagine how much of a royal pain in the ass it will be if Google Code experiences the same fate.

> I get it, we all hate Google on HN (for reasons unclear to me)

The reasons should be clear to anyone with historical context; this isn't the first time Google has spontaneously pulled the plug on some "non-core" project it decided wasn't making quite enough money, in complete disregard of said project's use by the real world. It's these sorts of things that make me very reluctant to invest heavily in Google's ecosystem; I've personally been burned in the past by these sorts of things.

A part of me wants XKCD #1361 to come true.


I like how that project is hosted on Google code


It's not a googlecode-hosted project: there is no /p/ in the middle, and you can't see its source (not that there'd be much to see). It's a tool made by the googlecode team to help migrate.


I seriously doubt Github would ever agree to that automation. First, what accounts would all these orphan repos go under? Second, how much spam would they be agreeing to host by saying yes to that?

This is a much better job for The Internet Archive or a read-only google code in perpetuity.

edit: in fact, it looks like they're planning on making a read-only version, but the definition of "legitimate" is going to be very important to nail down:

> cdibona: We are planing on taking the majority of these legitimate, open source, 'abandonded' projects and putting them up in cold storage in a git repo on googlesource.com

https://news.ycombinator.com/item?id=9192554


> What Google is doing makes sense from a business stand point but totally shameful from a company that boasts itself doing "no evil".

Oh come on! I'm not a fan of everything Google does, and I can see, and in part agree with, the point you are trying to make, but this is just grasping at straws. You just lost all credibility with this comment.

Yes, I can see unmaintained code being lost here, and that is unfortunate. But Google provided this service for free, a service they started to promote open source software development. They noticed that there was a big move to other hosting platforms, that they themselves also believe are better than theirs. This has led to support for this platform to be little more than dealing with abuse cases, and they feel that the benefit to the community no longer outweighs the cost of the platform.

They have gone out of their way to provide ways to migrate code from Google Code to these other "better" platforms, and they are giving people over 18 months to migrate their code:

> January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.

They really didn't have to provide any of this.

None of this is "evil". There are plenty of acts that Google do that border on "evil", but this is really just the wrong one to choose to call them out on.

What do you really expect them to do here?


> that will be lost no question

We have over a year. There will be backups of all of google code made, and even then the Internet Archive will certainly have a backup of all the software projects on it. I doubt any code will be lost - active participation might be, from developers who don't want to relearn how to do things on github.


A sibling comment already pointed this out, but the existence of https://code.google.com/export-to-github/ and its explicit mention in the post along with the clear language that they did work with GitHub and Bitbucket, leads me to believe that you did not read the post.


But the parent comment gave a very plausible suggestion for how Google can do this in a very low maintenance way. Yes, there is abuse management, but now that they're read-only I'd expect this to fall off pretty fast.

Google's first business is access to information about links. You'd think they would be more careful about propagating link rot.

Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?


Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?

That does make sense - the more people who stumble upon broken links an choose to use them to find information, the more traffic they get and can earn from ads with. Remember their experiments with Chrome hiding the URL(!) last year?


> Google hates anything that requires a human's touch

I guess robots will soon make decisions in Google too ;)


"Google hates anything that requires a human's touch"

Perhaps they should stop offering products to humans then?

Seriously, why would _anybody_ use/recommend a Google product, when the expectation of "customer service" is "maybe some other poor schmuk on some poorly maintained and difficult to search Google group once had the same problem and they (or some other non Google person) worked out a fix and bothered posting it".

Yeah, you're not paying for it - it's worth exactly that when anything goes wrong. (Unless you're running 5 or 6 digits a month in Adwords spend, then they're _remarkably_ good at CS...)


Chris diBona says Google will be keeping a public copy of all unmigrated repos:

https://news.ycombinator.com/item?id=9192554


That's good to hear, although I'm not sure based on the comment whether:

(a) a project's issues and wiki will be preserved in some form, in addition to the repo(s) themselves;

(b) code.google.com links will be redirected to this googlesource archive (for projects which have not opted in to the custom redirect thing).

If the answer is yes on both, then I'm a happy camper.


So for (a), we're going to build tarballs that include the issues, and wikis are already just in a repository.

For (b), that's not a bad idea, but I don't know if we'd talked about that. I'll poke it in our bug tracker. Thanks!


Can that be relied upon as an official Google statement?


Chris DiBona is Google's Director of Open Source and the author of the blog post announcing the deprecation, so I'd say yes. But he's "planning", not guaranteeing it.


I think, when people give you something of value for free, it's not okay to respond with "But you should have given me more!" If that's not obvious to you, think of it in game theory terms: you're basically responding to cooperation with defection.

The proper response to something like this shutting down is "It's a pity it has to end, but thank you for running the service all those years."


Can you explain the game theory behind that? I would've expected that, in this case (where the worst case for a user is what will currently happen), responding with a request for more rather than cooperation is actually the rational behaviour.


No, the best case for the user is what would have happened anyway. The worst case is the people who provided that free service, and maybe other people who see the thanks they got, end up thinking "well, damned if we're going to give those ungrateful bastards anything else for free."


Par for the course as far as Google's concerned. This is the one caveat I give all my clients before going ahead with using any google service beyond gmail, since you can easily get the rug yanked out from underneath you. It's not usually the discontinuation of an entire service, but they drop major features from many apps, and give the users as much warning as a Vogon would.


I disagree with your comment. I'm sharing my disagreement via this comment rather than down voting (because I don't do that).

I think Google and others should feel free to experiment, shut down closed experiments once the time is right, and not have to be obligated to spend resources on archiving things. As long as migrating is easy.


I'm sure some are going to immediately say "Yet another Google casualty", but I feel like this one probably needed to happen. It's been stagnant for years, and they have been on the mindshare decline since the first two years. I dread having to deal with open source software that is still on Google Code.

Admit failure, provide plenty of notice (like they're doing), and close up shop so resources can be spent on more impactful projects.


How is this even a failure? Google Code was the best at what it did for several years. Now it's not. That doesn't eradicate the time in the past where it provided real value to millions of users.

A party isn't a failure just because everyone eventually has to go home. It just means even successful things have ends.


> How is this even a failure? Google Code was the best at what it did for several years.

Google Code had a few good years, and I am grateful that it happened. However, it did fail to win the software forge battle as the space heated up. It failed to evolve enough to keep up. It failed to keep the mindshare it built in those two initial years as Github and others blew past it over the next six.

So call it for what it is: A project that had two good years out of eight. Like many failures, there were successful moments and positive impacts on the greater community. But closing down due to losing constitutes failure.


It actually can be considered a success in the style of the original intent of Chrome, Fiber, the Nexus line, and who knows, maybe the upcoming MVNO: to spur innovation and increased investment in a stagnating product area.

When Google Code came out Source Forge was horrible, and Github didn't exist. Google Code helped both open source software and the market for code hosting. Now there's a dominant, but so far so great, offering with Github, and several very good competitors.

Google Code wouldn't have even launched today, it's both necessary to projects and to Google.


Yeah, it's tempting to take a small bit of credit for the existence of the new generation of project hosting services. Google Code showed that there was room for new players, so it did open the door, but you have to give credit to GitHub for the concept of social coding. I never understood it and it goes against my personal OSS DNA, so I would never have made that leap.

Another way to (very charitably) count Google Code's success is to look at the role it played in Google. One of the largest users of Google Code has always been Google itself. In 2005, Google had released like 8 project tarballs on SF, kind of tentatively. Having Google Code as a home field endorsement allowed that to grow into the thousands. Now, OSS releases seem pretty routine for Google and feel more integrated with the community than ever.


> However, it did fail to win the software forge battle as the space heated up.

This is just the wrong metaphor entirely. It's not a battle because battles, and even wars, have ends.

But you're implying that somehow today is special and marks the end of the battle and therefore GitHub "won" because it's the most popular right now. But will it be in twenty years? If not, will you have to go back and edit your comment?

There's no winning and losing here. It's just an endless continuum of time where popularity waxes and wanes, where things end and new things begin. Google Code had a good run. So did SourceForge before it, and CVS and FTP sites before that. Something will come along to replace GitHub eventually.

The computer world is new enough that we haven't gotten used to the idea of software technology having a finite lifespan, but it absolutely does. That's OK. The goal of every product on Earth doesn't have to be to live forever.


Basically, this. In case others didn't read the post, you'll have almost a year to take your projects off. We wanted the handful of projects that were still active to have plenty of time to migrate.


Is it possible, when code goes cold, to redirect URLS to archive.org rather than 404ing them?

I have been known to make use of ancient, forgotten code from geocities pages, and keeping the integrity of hyperlinks together matters to me. Think of the blog posts that currently link to Google Code pages; those will never be updated.


There are thousands of independent/homebrew projects that call Google Code their home that will probably vanish overnight. And not everyone likes using Git to begin with.

I don't see why they don't put stricter requirements on starting a project page or contributing instead of making this move.


> And not everyone likes using Git to begin with.

FWIW. Mercurial can use Git as a backend which would ease the tension for those not enamored with it.


I agree, a lot of google shutdowns are really awesome products that just have a small userbase. Stuff like Reader didn't even have good alternatives when it shutdown.

Google Code isn't that great of a product, it has a small userbase, and there are many alternatives.


Yeah. I don't think anyone is surprised by this, and it's very different from a Google Reader situation. The writing was on the wall when Google projects started moving off of it and onto Github.


Hi Chris, GitLab CEO here. What do you think about mentioning Gitlab.com as an alternative for people to move to? It has unlimited (private) projects and unlimited collaborators. It is based the open source GitLab project.


It is a very nice system, but the stuff that goes into a shutdown had me fighting to keep the message as tight as possible. I wanted to go on about Bitbucket, gitlab, and put in a long discussion about how this doesn't effect the scalable git team at google at all (we host android and chrome and a ton of internal teams on a git backed on our backends here) , but had to keep the message pure...

But I heartily recommend people look at Gitlab...


Hey look! You get to put "I heartily recommend people look at Gitlab - Chris DiBona, Google" on your homepage.

That you haven't yet is mindboggling.


Totally agree. And even better, we put your quote about Chris his quote on there together with you HN profile :) See https://gitlab.com/gitlab-com/www-gitlab-com/commit/7eb4ced6... and https://gitlab.com/gitlab-com/www-gitlab-com/commit/b9342fd5...

(if you'll get in trouble for this please say so here or via sytse@gitlab.com and I'll remove it ASAP)


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.


Thanks cluenerf, this wasn't as funny as I thought yesterday. Using their employer is not cool. I've removed it . Thanks for helping me realize. I removed it https://gitlab.com/gitlab-com/www-gitlab-com/commit/5398cb57...


I think you should wait, get permission from both and put it. You have put Sachin's company name and position also...


Yeah, in hindsight we should have asked permission. I thought it was funny but this was over the edge. I removed it https://gitlab.com/gitlab-com/www-gitlab-com/commit/5398cb57...


Just to be clear, I asked the person that was quoted what he thought about it as I posted it and he seemed pretty relaxed https://twitter.com/sachinag/status/576145655120277504 but I still thought it was better to remove it.


Thanks for the honest answer! I know a lot of geeks wont agree with this, but the reality is when you are doing PR (or anything else, including/especially software engineering) you need to be as simple as possible.


Rather than recommending a specific Git hoster such as Github, you should have listed out alternatives... especially as Google Code also supports Subversion and Mercurial.


But, they wrote a Google Code to GitHub exporter tool. They felt the need to make a customer friendly egress tool, but not write a dozen of them. I think developers kinda know where they want to land already, and if they don't, they could do a google search, which would ultimately result in them using Github or Bitbucket, in all likelihood.

From a user action perspective, if you give a user who doesn't know what their options are too many options, they won't take action. They'll feel the need to explore all the different paths, and feel anxiety about making the right choice. I think giving users fewer things to think about is actually better a lot of the time.


Yes, good for customers to have a friendly exit path, but I'm sure Google are capable of writing a Google Code to AnyGitHostingCompany exporter tool :-)


Subversion & Mercurial? Then actually just RhodeCode (https://rhodecode.com) is the only alternative since it supports Git, Mercurial and Subversion.

Disclaimer: I am RhodeCode's co-founder.


There is also Kallithea (https://kallithea-scm.org/). Kallithea is a free and libre fork of RhodeCode after they dropped their GPLV3 license for parts of the codebase and added a paid user limit.

Kallithea is being actively developed (a 0.2 release is coming soon) by a free software community under the auspices of the software freedom conservancy. See this blog post from Bradley Kuhn for more details: http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html


Apache Allura (http://allura.apache.org/) supports Subversion, Mercurial and Git. And it is the platform which powers SourceForge so you can run your own or use it at SF.


Kallithea is partly a fork of our old, legacy version of RhodeCode without all the hard work our engineers spent over the last 12 months in turning an open source project into a real, sophisticated enterprise product.

In more than 30,000 engineering hours our team added exclusive Subversion support, 4x better performance and tons of security fixes (all based on enterprise customer feedback), server-side-mergeable pull requests and maybe the world's most flexible and advanced code review system.

Anyway, I recommend to try out both and choose the one you trust your source code and team's productivity more.

P.S.: RhodeCode Enterprise 3 is free for startups and small teams.


> Kallithea is partly a fork of our old, legacy version of RhodeCode without all the hard work our engineers spent over the last 12 months in turning an open source project into a real, sophisticated enterprise product.

The marketing-speak, it burns.

You turned your back on us. You lied. You and Marcin repeatedly told us that you were comitted to free software. I don't know if you lied to Marcin as well or if both of you knew that the GPL-ness of Rhodecode was going to disappear.

For a while you had an ambiguous licensing situation where you made it seem like Rhodecode was still somehow GPL'ed, but after a while you apparently tried to revoke permissions on everything. You even threatened with legal action someone who used the code under the GPL license you said you were allowing.

Oh, apparently you even went through with your legal threat:

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


Reply to comment by jordigh:

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.


> It is sad to see how often forks go downhill

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.


Thanks Chris!


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!


Both open and private repos on GitLab are free :D


Okay thanks I found that info here https://about.gitlab.com/gitlab-com/

Figured I'd find it on the home page or under pricing or something.


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.


Ah for whatever reason I didn't see that at all.


No problem, it is not that obvious, any suggestions how to make it more findable without messing up the other options are welcome.


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.


Thanks for the great feedback!

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?


This is a HUGE improvement :D


Thanks!


Btw my suggestions were just a template. I'm flattered that you used them as is :)

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.


Thanks for the great comments! We fixed the blurbs with https://gitlab.com/gitlab-com/www-gitlab-com/commit/8e24fc11... and the homepage is greatly improved because of it.

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.


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.

But beyond that I dunno.


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?


Ah I saw that but didn't know what it meant. Personally I like boundlessdreamz's idea :)


Me too! I've incorporated some of his idea's in https://gitlab.com/gitlab-com/www-gitlab-com/commit/3a09175f...


I second this motion. GitLab is amazing. It's open source and easy to deploy on your own hardware so you don't need to trust another provider.

Github is really great for the social experience, but I've been debating switching over to GitLab for all of my development projects.


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.


> including many from Gitorious

That's a bit disingenuous. GitLab purchased Gitorious--of course people are switching.


Sorry, it would have been better to say we acquired them, thanks for noting this.


BTW, One of your testimonials on your landing page bashes Gitorious (which no longer exists and is part of your company):

> “Gitlab is an excellent option….. not only more user friendly than Gitorious but also easier to install.”



more of a comparison than a bash, lets be fair.


We indeed try to focus on extra features and options GitLab has.


https://about.gitlab.com/

"Better than GitHub"

That's quite a motto.


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 Morbius!


It makes them sound petty and actually-probably-worse.

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!


That motto links to an excellent explanation https://about.gitlab.com/better-than-github/

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! :)


Thanks mlinksva!


i just spotted "GitLab is build to handle very large repositories." there. someone should proof-read it all i guess. :)


Thanks, fixed with https://gitlab.com/gitlab-com/www-gitlab-com/commit/5ef9196b... Hopefully many eyes will make all spelling errors shallow :)


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.


Spotted the GitHub fanboy.

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.


Wow, way to miss my point. Gitlab might be better. But when the best location on the frontpage is a direct swipe at the leading competitor, to me that reads as very weak. You know who doesn't bother to take jabs at their competitors? Winners.


I've explained the reasoning in https://news.ycombinator.com/item?id=9192595

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...


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.

Gitlab is not.


I think it is fair to for GitLab to pitch their service, considering that the google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times, while GitLab offers similar functionality. It would have been fairer for the blog to not-specifically endorse anything or post a link to https://en.wikipedia.org/wiki/Comparison_of_source_code_soft...


> I think it is fair to for GitLab to pitch their service, considering that the google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times, while GitLab offers similar functionality.

The only thing similar between gitlab and github is that they do something with version control. Gitlab is not a place for open source projects.

The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github.

There are many other hosting services like gitlab, what would make gitlab different so that it would deserve a pitch there?


"There are many other hosting services like gitlab, what would make gitlab different so that it would deserve a pitch there?"

Which is why I said the blogpost would be fairer to just post the wikipedia comparison link. I never said that gitlab should "deserve" a pitch on the blog. I did say it was fair for GitLab to pitch their services, as the CEO has done here, but that is different from "deserving" a pitch.

It is hard to objectively determine what is the better hosting, but based on people's individual preferences, they can subjectively decide for themselves, which the wikipedia article helps out by clearly explaining the differences. Everyone who uses google code knows about github anyway, but might not be aware that there are other services.

We saw gitorious, an entirely-opensource service, fail due to lack of revenue. And we've seen Google Code, an entirely-proprietary solution, fail. For those concerned about the longevity of their hosting setup, they may want a hosting provider that both has a steady source of income to help guarantee longevity and that is based significantly on opensource software (maybe for reasons of philosophical principle in that opensource development should use opensource infrastructure, or for pragmatic reasons such that they can always fork the hosting service code). GitLab fills this niche nicely, in that the community edition is based on fully open-source code, while the enterprise edition (that the their commercial service gitlab.com is based on) uses proprietary extensions.

"The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github."

The lack of stars on gitlab projects may simply be due to the first-mover advantage of github, but does not necessarily represent any fundamental deficiencies is the hosting service.


> It is hard to objectively determine what is the better hosting, but based on people's individual preferences, they can subjectively decide for themselves, which the wikipedia article helps out by clearly explaining the differences.

It's quite easy to tell actually. Responsiveness of the UI, featureset, availability, size of the community.

* Gitlab is measurably slower (it takes about 5 seconds to load the commit page of a project, compared to <1 for github) * Gitlab's lacking many features that github has (many filetypes cannot be previewed, lack of integrations, general inferior issue tracker, no search and much more) * Availability: github rarely goes down. Right now it tracks at 100% availability over the last month. * Size of community: there is really no discussion here.

Note: I'm not talking about commercial hosting, but about a place for Open Source projects. There is currently absolutely no objective reason to put a project on gitlab.


Well if we're using "Responsiveness of the UI" as the metric, then I would argue that http://fossil-scm.org/ beats both GitLab and GitHub. Fossil is easily self hosted (just run one small executible file). And it is really fast, because it is written in C with sqlite and is simple and minimalistic. It is not git based, but is a simpler DVCS. Dynamically generated pages on my home computer take less than .001 ms to display. It has all the features most small developers need, with a builtin lightweight wiki, issue tracker, and code tree. Your self-hosted website is available even if you don't have an internet connection, or you can use free hosting service like http://chiselapp.com/. Of course it looses in terms of size of community. But popularity does not determine quality.

You will likely loose arguments on public forums if you make statements like "absolutely no objective reason to ..." because someone just needs one reason to disprove. Here goes: GitLab has a functioning interface for managing git projects and lets anyone selfhost the community edition. Therefore there is an objective reason to put a project on GitLab. QED.


> Well if we're using "Responsiveness of the UI" as the metric, then I would argue that http://fossil-scm.org/ beats both GitLab and GitHub.

Which is why I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project. Github and Bitbucket deserve the mention because those projects are well established.


> "Github and Bitbucket deserve the mention because those projects are well established."

According to Wikipedia article, GitHub and Bitbucket were established in 2008, and GitLab in sept 2011, making it ~3.5 years old and about half the age. Although the precise meaning of "well established" is vague, and while you could say that GitHub and Bitbucket are "more established" than GitLab, I would say GitLab is at least "sufficiently established" (i.e. at least sufficient enough to host projects with %99+ uptime). Quick searches reveal that GitHub is known to go down, with major ddos in Nov 2011 and 2 hours in March 2014, Bitbucket was down sometime 27th April 2014, GitLab.com went offline for a full 8 hours in July 2014. (Someone who cares further can do a more precise comparison of uptime). But they were all fixed quickly, still up, functioning, learning, and improving. While maybe your threshold for consideration an internet service to be "well established" is different from another person's threshold, your threshold is not necessarily more valid and cannot be determined without more specific criterion.

Based alone on the argument that "well established" services deserve mention, then that should mean services established before Github and Bitbucket that are still running reliably should be mentioned as well. But you have specifically said it's ok for github and bitbucket to deserve mention but not others.

> "I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project."

It should not. And as I pointed out clearly in my original comment which I will repeat for emphasis as it has been the core of my whole argument:

"google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times"

While it was appropriate (and arguably a duty as benefactor) for google to post a link to https://code.google.com/p/support-tools/ containing their export tools to github and bitbucket and the sourceforge import, that reference only takes one sentence and doesn't even require the google blog post itself to specifically mention any services. Considering that a shutdown announcement is a serious matter, it should be kept brief and limited to only information relevant to shutdown. All those specific references could have been omitted and the shutdown announcement would still make sense. By specifically mentioning certain services multiple times, the writer of the blog post has opened the door to queries about mentioning alternative services specifically. Had he written in a neutral manner (either by only posting the Wikipedia link or not mentioning any services), then it would have been inappropriate for GitLab to query for a request to be mentioned.


Thanks for the concrete examples.

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.


> 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.


Out of curiosity, why Frankfurt?

Speaking as a European, it would be nice if you could keep it performant over here too ;)


Because Frankfurt was close to Delft and we wanted to reduce latency to move the data, see https://news.ycombinator.com/item?id=9171533

We think the east coast of the US is the best compromise considering our user base. Can't solve speed of light :/


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.


> Gitlab is not a place for open source projects.

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.

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.


> Currently there is absolutely no reason to use Gitlab.

http://techcrunch.com/2014/12/05/to-get-off-russias-blacklis...

Since you used the words, "absolutely no reason", here's a counterpoint: as part of an anti-censorship hydra effort.

    All X is Y.
    At least one X is not Y.
    ^-- contradiction
:)


> 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?


You said "absolutely no reason" and I gave you an edge case that invalidates your statement.

Maybe "generally no reason" would be better?


Nothing in the world is absolute. However so far I have not hear any non nebulous reasons why an Open Source project should be on gitlab.


Because GitLab is open source, and the alternatives (GitHub, BitBucket) are not.


> Because GitLab is open source, and the alternatives (GitHub, BitBucket) are not.

That's not a reason to use the hosted gitlab version, that might be a reason to self host gitlab.


Not really - if you are into open source because of the ideology and not just for the price then GitLab makes a lot more sense.

If I find a bug in GitLab I can feasibly submit a patch for it.


Also, if you need to, you can migrate to a self-hosted setup without switching to another platform. There's a built-in tool that makes this easy.


> Nothing in the world is absolute.

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.


Obviously GitHub is much larger, but some projects are moving to GitLab, such as GnuTLS https://twitter.com/GnuTLS/status/573155639683248128

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


GnuTLS did not move, they were moved because Gitorious got acquired by gitlab.


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.


Gitorious has a header that informs people to migrate to Gitlab.


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.


Bitbucket also has free private repos


Sure, but you are limited to 5 users for private repositories https://confluence.atlassian.com/display/BITBUCKET/Plans+and...


Only for up to five people.


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.


We use GitLab internally, and it's an amazing piece of software. It's open source, easy to setup and is pretty robust.

I would love to see the option to move from Google code to GitLab.


We do too, it would be nice if someone can contribute an importer.


I certainly hope GitLab uses GitLab internally. ;)


We do use GitLab for GitLab development :)


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.


We agree, and the good thing is, we do! You can have public projects on GitLab, and projects like GnuTLS and F-droid are already there.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: