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.
Google Code did one thing very well - each project could have one wiki and issue tracker, but any number of source code repos. This is fantastic for projects where there are multiple parts - eg an Android client, an iOS client, multiple server parts etc. Github for example only lets you have one source repository per project, and as a result the wikis and issues are useless since they are almost always filed against the wrong sub-project.
Every startup I have been involved in over the last many years used Google for business (users, groups, office stuff etc), but then for code hosting we were forced to go elsewhere, needing yet another set of user accounts, groups, admin, billing etc. There was a ticket begging to let folks pay for google code, but it never came to pass. All the startups would have gladly paid, especially to avoid dealing with multiple accounts, sites and admin. Some features like the issue tracker were quite good. Heck you could even prioritise issues - something github still didn't have the last time I looked.
For an example of what this looks like: http://code.google.com/p/iosched
I work on Google Code, and we will be putting a service in place to redirect
deep links to project homepages, issues, etc. to their new locations.
Projects on Google Code will need to set the "project moved" flag, under the
advanced tab of the project. But once set, things should work like you
You can disable the wiki and issues pages on a repository-by-repository basis. If you're looking to solve the issue of issues being filed in the wrong place, you could try to pick the component that is the most central or most front-facing and only leave that wiki or issue tracker enabled. Then you'd just add a simple note in the README of the other repos about where to go to report issues or read documentation. It's definitely not the same, but it is a somewhat elegant workaround.
What will happen, if those projects are not migrated because their developers have simply forgotten about them?
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.
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.
Comply with those terms (i.e. include that piece of text when you redistribute) and you satisfy MIT.
GPL, &c, they all have similar clauses. In fact, MIT goes much further. I could take all those projects, mirror them, and charge people insane amounts of money for it.
If you can't even rehost on Github, what good would copyleft be?
(now, third party code they may have included is a different issue, you can't get rights to that through someone else's claims, but ...)
But there is a plan to provide archival-style info throughout 2016 (tarballs per project). Is Google in touch with someone like the Intenet Archive to make sure that these data are still available after Google stops hosting them? I'm sure there's some group that's willing to take on the work of hosting the project metadata and associated files.
I personally, occasionally use a handful of "orphaned" libraries that haven't been touched in years and only live on Google Code. Gonna be a bummer when those links break.
For instance if you want to file bugs for AppEngine the official way is through Google Code
What are the plans on moving this and other issue lists for different Google products out of Google Code?
We have plans for this, we're just not ready to talk about them yet.
"What will happen to things that are hosted on google code, like jquery and the google font set? Thousand, if not millions of pages link to these directly - will they all be invalidated? "
They should be linking into Google's Hosted Libraries, which are separate and will continue AFAIK:
> rather geeky and sometimes unreliable internet site called SourceForge
Wtf. SourceForge was for a long time very decent. It wasn't geeky nor unreliable, it offered CVS and later Subversion, web hosting, mailing list hosting, forums and downloads.
GoogleCode itself was geeky with its very basic "Wiki", but it had a leaner "GMail style" UI, with only basic features so newer projects used it over SourceForge.
"Bidding farewell to Google Code", that's a rather nice wording for closing down a web service. Please archive orphan open source projects to a read-only SVN/GIT repo or donate the data to archive.org.
It reminds us that more open source projects should host the code on their servers, e.g. using Gitlab. In some years SourceForge and GitHub may get closed down too. Some orphan project of great value may get lost of the digital dark age.
Would it be possible to get a list of all the projects inside Google Code? I would very much like to grab the lot and preserve them inside searchcode.com
Codeplex provides this sort of data and GitHub and Bitbucket have an API. I could write a crawler/scraper to do so but I would probably miss something.
Please don't let this become similar to Geocities and have it all lost forever.
Honestly, I'll probably just download the archive and take it offline. I don't want to think about this shit.
“GitHub is just really smooth,” says Rob “CmdrTaco” Malda, who lived through the open source revolution as the editor-in-chief of the tech site Slashdot. “It’s a sexy, modern interface.”
These are some captions in need of a meme generator.
In all seriousness, though, I started my own open source project hosting website back in the day. It was the first to offer public Mercurial and Git hosting.
Google Code existed then and the interface and functionality has not really changed since I released the first version of the site.
For them to change, they'd have to either: 1) Support everything into eternity, which given their propensity to release new things frequently would grow to be impossibly expensive, or 2) Be more disciplined in what they release, so that it can be supported in perpetuity. I don't see either happening, so we end up where we are now. They have to keep innovating or they'll stagnate and die.
Someone has to invest the time and money to keep services running, even if only limping along. Google likes to experiment and test the waters. It's part of why they've been so successful. I hope they keep killing off their underperforming/underused services so they can keep on pushing other things forward.
However, closing down stagnant projects is very different from locking down access to previously open APIs (Google Maps). Since we're discussing the closure of Google Code, I won't get distracted with that controversial topic.
In the end, they are a for-profit business. Not a charity.
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.
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.
'Eternity' overstates it. Plenty of vendors support projects long after they are obsolete. IBM supported OS/2, released 1992 and a marketplace flop, until the end of 2006.
That means that if I need something to be around for awhile, I'll count on IBM and not Google. Google has the perogative to make that choice, of course, and long-term support generally is associated more with the business market than with consumers. Party that's because it costs more for businesses to change, partly IMO because consumers are poorly educated customers.
EDIT: It's a little odd to see this very normal comment modded down to -1 (now -3!). Another perfectly fine comment was modded down to 0. I don't care about the points at all, but it supports my instinct that some on HN are trying to protect Google. Employees? Fans?
That's because users paid for it.
Google gave the world high-quality, free open source code hosting for eight years. I don't see how that's anything but a net positive.
I'll give you three guesses as to how much those companies still running OS/2 were paying for support in 2006.
When IBM buys a company/product, they will merrily throw everything out and declare that v.next is the next version of whatever product you are using. Then the legacy product goes in life support.
OS/2 lived on because it was widely deployed in banking for ATMs and POS, and it generated a lot of complimentary revenue. So when a company like Target had 100,000 cash registers, IBM got to sell services around deployment and maintenance, and management software like Tivoli to manage the devices.
code.google.com was around for 7 years. What more do you want?
It was launched at OSCON in 2006.
The large companies are made of small clueless people just like every other company on the face of the Earth.
(a) For things (eg. Reader, Google Wallet for Digital Goods) that could be viable businesses in their own right with some modifications, spin them off as small companies.
(b) Open source the project they no longer have interest in. (as was done for Google Wave, which arguably wasn't necessary because the level of interest in Wave at that point was quite low)
In this case (and perhaps they already have this), I would suggest that they allow anyone to discover all the projects on Google Code and export them such that they could be imported into other code hosting sites, allowing everyone else to build a Google Code alternative.
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.
See my couple of wasted Google Glass devices that will never see an Android update again. Do you think I'll ever buy a Google Android product after they wasted $3k of mine? Do you think I'll buy any more of their tech device blunders like cars or thermostats or other devices? Likely not. It's well established they'll just drop them soon after release anyway.
They are getting the same reputation for software services. There are lots of startups that would have been happy with Reader's usage numbers besides, so they aren't even making decisions everyone would agree are good kills.
With my Android apps, any time someone sends me a bug report or a complaint, I refund them immediately and thank them for the feedback. Does this make me the most money? Hell no. But I have a lot of friendly users who email me constantly with improvements and who aren't mad I'm ripping them off or screwing them over. That's worth a lot too. Google is saving money to screw over users with this Google Code decision and it's definitely not one I agree with.
Again, these are two very niche projects. Reader was a niche within a niche. Glass was an experiment that a tiny subset of the population ever even touched first-hand. It never even reached a "1.0".
As early adopters and as technologists, it's easy for us to get upset when our favorite pet project gets killed. But in the end, Reader failed to get any kind of traction beyond its niche. Glass ran into a buzzsaw of negative perception, legislation, and media twisting, in addition to technical challenges. The lessons learned from Glass will be applied to present and future efforts.
Glass is clearly very much alive.
Glass is still very much alive.
It sucks for our niche, but ultimately Google Reader was a product that didn't have any appeal beyond said tiny niche. The original goal was to make RSS more accessible beyond technologists, but it failed to reach any kind of mass appeal. Some of this was more to do with RSS/Atom feeds having some ergonomic issues that weren't solved before the social media frenzy took hold.
Failure is when results don't meet expectations, which is what happened to Reader. I don't fault them for closing it, despite it being inconvenient for me to switch. What does a for-profit company have to gain by dumping time and resources into a failure whose window of opportunity has passed? Some goodwill from a tiny, miniscule subset of their userbase?
Apologies for the rantiness of the post below, it isn't meant aggressively, just more frustration at no apparent direction seen within the Googlesphere.
The removal of features that people use with no warning and non-implementation of features immediately after release is really really annoying. It makes their stated goals ("index everything") meaningless/temporary/untrustworthy, and dissuades me from buying services from them. Freeloaders use their products a lot (I do!) but I would think twice about ever ever ever paying for software from them, or for a service because you have no idea when it'll shut shop. Even products they still produce appear to be completely disjointed (see the Play Books app on Android and the complete disparity found with their web interface...)
Here's a list of annoyances in products they've released to much fanfare, then apparently just not bothered developing anymore:
1. Google+, yes all of it. And I use it! (where is it going now that Gundotra has left?)
2. Maps: My Maps now isn't integrated into the Android app (they spun it off??), Latitude is gone, Google Local is gone but apparently still there (you can read reviews but hidden and secret GUI controls are now the order of the day for working out how to do anything in Google Maps)
3. Google Drive desktop client: will it ever tell me how far it has got in uploading a massive file? The web client does, the desktop one doesn't. Surely that's an OBVIOUS feature in a filesync utility. Don't ask about their promised Linux version. Couldn't they write it in Go or something?
4. Google Hangouts Android client: the forced update from Talk with the removal of features (is someone actually online? a presence feature seen since MSN Messenger that somehow escapes Google's notice)
5. Google Chrome OS: why is it even here? There was much talk of being stiff competition to Windows and OSX but it's like an Etch-A-Sketch toy operating system. I think TinyCore Linux does more?
I'll stop now because it's coming up to lunch time and I'll get indigestion.
I am a big fan of Android, but their incessant removal of features within their core apps and then rereleases of similar-but-ever-so-slightly-different apps ever year at I/O is getting wearisome.
You just listed a bunch of projects that failed to get traction or lost mindshare battles. I expect an innovator to move on from failures, which is what all of your examples are. Reader: Failure, Google Code: Failure, G+: Failure, Wave: Failure. The reasons for each failure differ, but said reasons are irrelevant to this discussion. The fact is that Google attempted something, maybe enjoyed a little bit of success, but the results didn't meet their expectations. Rather than continue running these things with skeleton crews (to what effect?), they've done the right thing and closed them down.
The only exception is Glass, which was an experiment that already is impacting other current and future products. It never had a guaranteed future. It never reached consumer "1.0".
That's great if you are an investor or employee, but if you are a user it kind of sucks.
Google just needs to be up front about it (and maybe they are): We make no commitment to supporting this application or maintaining it as is. We might make radical changes, we might shut it down. If we do shut it down, we'll warn you at least 9 months ahead of time.
I'm not going to invest much in those applications, but others might.
Google code is mostly irrelevant to this calculus, because it was not ever meant to make money for anyone, but i think you are a little harsh here.
Don't get me wrong, as a user, I would love to have the stuff i want to use supported forever. But it's unrealistic.
Google is suffering the reputational damage it deserves - not because it is now behaving any differently from other corporations but because it has betrayed the promise that it would.
Nobody launches a new product and guarantees "If this doesn't work out, we'll keep it around indefinitely on life support". You don't start a new effort expecting failure. If it doesn't end up working out, it'll be closed down. Google's failures are just a lot more public than whatever side business many of us may take a stab at.
This isn't unique to Google. Failures need to be learned from and culled. We as a small business/startup oriented crowd should understand that more than most. I've had to kill off more projects than I'd like to admit because I didn't want to spend the time/money on what I perceived to be failures.
Not that failure is bad. Like Google, I've learned a ton from my unsuccessful projects.
Consumer and 'free' software is the exception, and it's a recent exception with rapid release schedules. It's just shifting the costs from the vendor (maintaining old products) to the consumer (changing/upgrading).
It's important to note that in many cases, the vendor pays for what is otherwise a free service (Reader, Wave, G+). In the case of some services, they may gather some data from which they can profit from, but that doesn't always pay the bills.
So yes, the customer may have to switch services or upgrade, but unlike enterprise software, they aren't paying four to six figures to use said services.
No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate.
What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth overhead) by publishing static files over HTTP. With the addition of a static export of the Google Code pages (mostly doable by crawling; some pagination issues would need to be worked out), Google could host the site going forward on a simple HTTP server without needing to maintain its server-side codebase. And Google is lacking in neither HTTP servers or bandwidth... Belated abuse complaints would remain a problem, but it's easy enough to delete things on request.
Google is obviously not legally obligated to keep the site up, and under current mores I suppose it's not socially obligated either. But I think that when the owning company continues to be highly financially successful and maintenance is easy enough, there should be a social obligation for some kind of archival.
Or at least redirect the subdomain to whatever Archive Team comes up with...
> Lately, the administrative load has consisted almost exclusively of abuse management.
They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.
As for the deep links, one of the Google Code devs did mention:
> 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.
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".
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.
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.
In that paper she publishes a link to a Google Code repository as supplement materials. For example, in the aforementioned paper there is a link to the following repository: http://code.google.com/p/glu-genetics/
Don't get me wrong, I'm all for retaining the materials and knowledge, etc etc. I'm just having a hard time understanding why you expect Google to do the work and maintain it? What if she uploaded her materials to Megaupload, or any of the hundred other filesharing sites - would you hold them to the same standard? Why doesn't the journal that published the paper (which, has a revenue stream) host the material, given that it directly supports their work?
Megaupload is not run by Google, with the stated mission of organizing the world's information.
Megaupload is bankrupt. Google is one of the richest technology companies in history.
This is not Megaupload throwing away its hoard of 90's B movies. This is Google, knowingly and literally throwing away coding history. We don't even know what might be thrown away.
What if some currently unknown researcher wrote his first code and uploaded it to Google code and forgot about it, and turned out to be the next Zuckerberg or even Turing?
What if some valuable research that was entrusted to Google from a deceased researcher suddenly disappears?
There are likely many more unintended consequences stemming from such an act, and I don't think we should give Google a pass, especially since Google controls possibly the largest collection of computers on the planet. (besides, source code tends to compress pretty well!)
Seems like the least they could do is stick it in an 'unlimited' Google Drive and lock it as read only.
Does anyone know of an effort to maintain this, like is done with sequencing data at the NIH? Something like PubMed Central?
I have first hand experience with this on the biology side, looking for reagents or even protocols from a 10 year old paper...and coming up completely dry. It's kind of a travesty, but the world collectively shrugged.
I'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.
Researchers would kill to have the balled-up scraps of paper that (e.g) Shakespeare threw in the trash.
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".
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.
Or a library to burn down its own buildings? Or Google to delete all scans of old books?
History matters, because citations to "old" research/code may become more valuable with new requirements and research. Surely a company that "organizes the world's information" needs no explanation of these topics.
If it's their archives, yes.
And if those are the only archives of Usenet in existence, then it's not Google's fault no one else cared to back it up.
(Admittedly, if I recall correctly, Dejanews had already gone broke trying to maintain that archive before Google bought it, so arguably Google didn't kill it, they just bought the dying corpse and kept it animated in a zombie-like state for a decade or so past it's natural death...)
This is software, not ancient manuscripts written by scribes on now crumbling vellum - there is no excuse for there to be one canonical copy of anything. Every pornographic movie ever made has multiple redundant backups on decentralized peer to peer networks and darknets.
I understand the importance of maintaining references, but realistically, expecting URLS to be permanent is shortsighted at best, unless you own that domain and the server it's on and expect to have the money to keep the rights to it in perpetuity. You can't expect a third party host to be willing to keep the servers on forever.
But as far as the historical record and the data itself - Google's given warning, people can move their data or lose it. Fork and move on.
Google's an ad company, they don't have an obligation to be the arbiters of human history, whatever their slogans might be regarding 'organizing the world's information'. They care about the information that makes them money.
Actually closer to saying they are evil for destroying humanity's only copy of the recipe.
> 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.
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
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?
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.
Google's first business is access to information about links. You'd think they would be more careful about propagating link rot.
Unless they _want_ link rot, as they're much better positioned to handle changes in links than any search engine entrant?
That does make sense - the more people who stumble upon broken links an choose to use them to find information, the more traffic they get and can earn from ads with. Remember their experiments with Chrome hiding the URL(!) last year?
I guess robots will soon make decisions in Google too ;)
Perhaps they should stop offering products to humans then?
Seriously, why would _anybody_ use/recommend a Google product, when the expectation of "customer service" is "maybe some other poor schmuk on some poorly maintained and difficult to search Google group once had the same problem and they (or some other non Google person) worked out a fix and bothered posting it".
Yeah, you're not paying for it - it's worth exactly that when anything goes wrong. (Unless you're running 5 or 6 digits a month in Adwords spend, then they're _remarkably_ good at CS...)
(a) a project's issues and wiki will be preserved in some form, in addition to the repo(s) themselves;
(b) code.google.com links will be redirected to this googlesource archive (for projects which have not opted in to the custom redirect thing).
If the answer is yes on both, then I'm a happy camper.
For (b), that's not a bad idea, but I don't know if we'd talked about that. I'll poke it in our bug tracker. Thanks!
The proper response to something like this shutting down is "It's a pity it has to end, but thank you for running the service all those years."
I think Google and others should feel free to experiment, shut down closed experiments once the time is right, and not have to be obligated to spend resources on archiving things. As long as migrating is easy.
Admit failure, provide plenty of notice (like they're doing), and close up shop so resources can be spent on more impactful projects.
A party isn't a failure just because everyone eventually has to go home. It just means even successful things have ends.
Google Code had a few good years, and I am grateful that it happened. However, it did fail to win the software forge battle as the space heated up. It failed to evolve enough to keep up. It failed to keep the mindshare it built in those two initial years as Github and others blew past it over the next six.
So call it for what it is: A project that had two good years out of eight. Like many failures, there were successful moments and positive impacts on the greater community. But closing down due to losing constitutes failure.
When Google Code came out Source Forge was horrible, and Github didn't exist. Google Code helped both open source software and the market for code hosting. Now there's a dominant, but so far so great, offering with Github, and several very good competitors.
Google Code wouldn't have even launched today, it's both necessary to projects and to Google.
Another way to (very charitably) count Google Code's success is to look at the role it played in Google. One of the largest users of Google Code has always been Google itself. In 2005, Google had released like 8 project tarballs on SF, kind of tentatively. Having Google Code as a home field endorsement allowed that to grow into the thousands. Now, OSS releases seem pretty routine for Google and feel more integrated with the community than ever.
This is just the wrong metaphor entirely. It's not a battle because battles, and even wars, have ends.
But you're implying that somehow today is special and marks the end of the battle and therefore GitHub "won" because it's the most popular right now. But will it be in twenty years? If not, will you have to go back and edit your comment?
There's no winning and losing here. It's just an endless continuum of time where popularity waxes and wanes, where things end and new things begin. Google Code had a good run. So did SourceForge before it, and CVS and FTP sites before that. Something will come along to replace GitHub eventually.
The computer world is new enough that we haven't gotten used to the idea of software technology having a finite lifespan, but it absolutely does. That's OK. The goal of every product on Earth doesn't have to be to live forever.
I have been known to make use of ancient, forgotten code from geocities pages, and keeping the integrity of hyperlinks together matters to me. Think of the blog posts that currently link to Google Code pages; those will never be updated.
I don't see why they don't put stricter requirements on starting a project page or contributing instead of making this move.
FWIW. Mercurial can use Git as a backend which would ease the tension for those not enamored with it.
Google Code isn't that great of a product, it has a small userbase, and there are many alternatives.
But I heartily recommend people look at Gitlab...
That you haven't yet is mindboggling.
(if you'll get in trouble for this please say so here or via firstname.lastname@example.org and I'll remove it ASAP)
From a user action perspective, if you give a user who doesn't know what their options are too many options, they won't take action. They'll feel the need to explore all the different paths, and feel anxiety about making the right choice. I think giving users fewer things to think about is actually better a lot of the time.
Disclaimer: I am RhodeCode's co-founder.
Kallithea is being actively developed (a 0.2 release is coming soon) by a free software community under the auspices of the software freedom conservancy. See this blog post from Bradley Kuhn for more details: http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html
In more than 30,000 engineering hours our team added exclusive Subversion support, 4x better performance and tons of security fixes (all based on enterprise customer feedback), server-side-mergeable pull requests and maybe the world's most flexible and advanced code review system.
Anyway, I recommend to try out both and choose the one you trust your source code and team's productivity more.
P.S.: RhodeCode Enterprise 3 is free for startups and small teams.
The marketing-speak, it burns.
You turned your back on us. You lied. You and Marcin repeatedly told us that you were comitted to free software. I don't know if you lied to Marcin as well or if both of you knew that the GPL-ness of Rhodecode was going to disappear.
For a while you had an ambiguous licensing situation where you made it seem like Rhodecode was still somehow GPL'ed, but after a while you apparently tried to revoke permissions on everything. You even threatened with legal action someone who used the code under the GPL license you said you were allowing.
Oh, apparently you even went through with your legal threat:
And now you're talking about "engineers" and "enterprise" and "real" and "sophisticated".
bkuhn salvaged what he could without trying to get into the legalities of the GPL revoking you did (which the GPL itself forbids), but still I feel very betrayed by what you did with Rhodecode.
edit: more details of the debacle
Wow, there is someone really angry and offensive here and not really telling the truth ...
It is sad to see how often forks go downhill if they were purely based on ideologies and not with the user and general good for the project in mind.
But anyway, we welcome and fully support everyone to fork our old GPL versions, the world does not need less but more source code management systems, especially since we lost now one of the key players in Google Code.
As can be seen in my blog post and various talks in the subject, the Kallithea community faced two choices: a fork of only the GPLv3'd components, or a lengthy GPL enforcement battle with Rhodecode, who violated the GPL by changing to a non-Free-Software license for code that combined GPL'd software that wasn't copyrighted by Rhodecode.
If Rhodecode would go back to a pure GPLv3 model for its software and develop the software in pubic again, I think the fork could be easily resolved and we could all work together again. Thus, only one simple act of yours would resolve the fork entirely, sebastiank123, will you take that act?
Meanwhile, I'm sure the Free Software user community can make the easy and obvious choice between a community-run, developed-in-public Free Software project that complies with GPLv3 and a for-profit-corporate run, developed-in-private, semi-Open-Source project that has a history of GPLv3 compliance problems.
Do you have free hosting for open source? If not then I don't think it makes sense for them to mention your service.
Edit: As pointed out below GitLab.com actually has free public and private repository hosting. It took me a while to find it on the website. That's pretty cool!
Figured I'd find it on the home page or under pricing or something.
I think what Gitlab.com needs is a template like this
- Free Private Repos - Host it on Gitlab.com
- Need to host it on your servers? Get our open source edition
- Need enterprise support/features? Get our enterprise edition and host it on your servers
Btw do you offer enterprise features on gitlab.com? It was not very clear
Also your pricing page needs to be clear about the different versions. There are at least 3 different Gitlab products (free gitlab.com, gitlab ce, gitlab ee) but the information is easy to miss.
In your homepage, the three blurbs (download and install.., pricing for spport.., signup for gitlab.com..) feel like 3 product features rather than 3 different products.
I've changed the homepage according to your feedback in https://gitlab.com/gitlab-com/www-gitlab-com/commit/3a09175f...
https://about.gitlab.com/gitlab-com/ mentions that it runs the enterprise edition in the middle box
The pricing page is a hard one, we'll look into that.
Any idea how we can make the three blurbs on the homepage feel more like different products?
1. For the blurbs - remove the icons and add headers. Something like this - https://cloudup.com/cGSjRmrWGkU
2. Gitlab.com as a product name is very confusing. When I first checked out gitlab.com my thought was "I'm already on gitlab.com, what's this other gitlab.com" :)
So I have changed it to Gitlab Hosted to make it more clear
Other Potential Improvements
This section - https://cloudup.com/c4vipl-QFBU tries to do everything. Explain features, introduce 3 different products and has a lot of text that could be removed
I would suggest making the entire block about features but in a layered way. i.e first introduce common features and then differentiate the products.
Some text could be removed - Subscriptions blurb can be replaced by "See our enterprise pricing page for subscriptions" or something similar. The way it is laid out now, it seems it is separate from Github Enterprise.
The current feature text blurb is too much text and too little text at the same time :) Too much because it is just
long lines of text. Too little because none of your features are explained elegantly. There is also a "much more" syndrome :)
Just see - https://about.gitlab.com/features/ - Powerful Code review - "Merge requests with line-by-line comments, CI and issue tracker integrations and much more" with a giant image. Text doesn't say much and ends with an ambiguous "much more" and the image is intimidating unless you are familiar with Gitlab.
Compare that to Pull requests section of stash "https://www.atlassian.com/software/stash?utm_source=bitbucke...
Images are not much help but they help in avoiding a wall of text and all the sub features are explained
The actual experience of using Bitbucket is not that great but they are doing a good job of explaining features :). Github enterprise also does something similar.
I think you should also move "Better than Github" to a different section like say "Why use GitLab?" Having it right at the top seems very defensive and a bit distracting.
One last thing - Link to some interesting projects using Gitlab and make it easy to find. You can even link to Gitlab.org somewhere. Looking around a repo gives a better feel for the product.
We'll try to improve the rest too and track it in issue https://gitlab.com/gitlab-com/www-gitlab-com/issues/271
Thank you very much for your kind comments.
But beyond that I dunno.
Github is really great for the social experience, but I've been debating switching over to GitLab for all of my development projects.
That's a bit disingenuous. GitLab purchased Gitorious--of course people are switching.
> “Gitlab is an excellent option….. not only more user friendly than Gitorious but also easier to install.”
"Better than GitHub"
That's quite a motto.
Just say you're the best git host. Don't mention your competitor.
I'm going to go create an account on it now. Good luck, guys!
IMO not mentioning competitors and not providing a detailed comparison to competitors means that marketing is winning and the market is failing.
Kudos to gitlab for providing info which helps the market work. Opposite of petty! :)
GitLab is objectively better. They even list their reasons on the page.
If you disagree you could, you know, refute those points instead of dismissing the whole thing in a petty manner.
I don't think it is always bad to compare yourself, but it should always be based on facts. I think Wealthfront is a winner and they posted https://medium.com/@adamnash/broken-values-bottom-lines-3d55...
Gitlab is not.
The only thing similar between gitlab and github is that they do something with version control. Gitlab is not a place for open source projects.
The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github.
There are many other hosting services like gitlab, what would make gitlab different so that it would deserve a pitch there?
Which is why I said the blogpost would be fairer to just post the wikipedia comparison link. I never said that gitlab should "deserve" a pitch on the blog. I did say it was fair for GitLab to pitch their services, as the CEO has done here, but that is different from "deserving" a pitch.
It is hard to objectively determine what is the better hosting, but based on people's individual preferences, they can subjectively decide for themselves, which the wikipedia article helps out by clearly explaining the differences. Everyone who uses google code knows about github anyway, but might not be aware that there are other services.
We saw gitorious, an entirely-opensource service, fail due to lack of revenue. And we've seen Google Code, an entirely-proprietary solution, fail. For those concerned about the longevity of their hosting setup, they may want a hosting provider that both has a steady source of income to help guarantee longevity and that is based significantly on opensource software (maybe for reasons of philosophical principle in that opensource development should use opensource infrastructure, or for pragmatic reasons such that they can always fork the hosting service code). GitLab fills this niche nicely, in that the community edition is based on fully open-source code, while the enterprise edition (that the their commercial service gitlab.com is based on) uses proprietary extensions.
"The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github."
The lack of stars on gitlab projects may simply be due to the first-mover advantage of github, but does not necessarily represent any fundamental deficiencies is the hosting service.
It's quite easy to tell actually. Responsiveness of the UI, featureset, availability, size of the community.
* Gitlab is measurably slower (it takes about 5 seconds to load the commit page of a project, compared to <1 for github)
* Gitlab's lacking many features that github has (many filetypes cannot be previewed, lack of integrations, general inferior issue tracker, no search and much more)
* Availability: github rarely goes down. Right now it tracks at 100% availability over the last month.
* Size of community: there is really no discussion here.
Note: I'm not talking about commercial hosting, but about a place for Open Source projects. There is currently absolutely no objective reason to put a project on gitlab.
You will likely loose arguments on public forums if you make statements like "absolutely no objective reason to ..." because someone just needs one reason to disprove. Here goes: GitLab has a functioning interface for managing git projects and lets anyone selfhost the community edition. Therefore there is an objective reason to put a project on GitLab. QED.
Which is why I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project. Github and Bitbucket deserve the mention because those projects are well established.
According to Wikipedia article, GitHub and Bitbucket were established in 2008, and GitLab in sept 2011, making it ~3.5 years old and about half the age. Although the precise meaning of "well established" is vague, and while you could say that GitHub and Bitbucket are "more established" than GitLab, I would say GitLab is at least "sufficiently established" (i.e. at least sufficient enough to host projects with %99+ uptime). Quick searches reveal that GitHub is known to go down, with major ddos in Nov 2011 and 2 hours in March 2014, Bitbucket was down sometime 27th April 2014, GitLab.com went offline for a full 8 hours in July 2014. (Someone who cares further can do a more precise comparison of uptime). But they were all fixed quickly, still up, functioning, learning, and improving. While maybe your threshold for consideration an internet service to be "well established" is different from another person's threshold, your threshold is not necessarily more valid and cannot be determined without more specific criterion.
Based alone on the argument that "well established" services deserve mention, then that should mean services established before Github and Bitbucket that are still running reliably should be mentioned as well. But you have specifically said it's ok for github and bitbucket to deserve mention but not others.
> "I really don't think (and that was my original point) that a Google announcement of shutting down Google Code should act as some sort of advertisement for $code-hosting-site/project."
It should not. And as I pointed out clearly in my original comment which I will repeat for emphasis as it has been the core of my whole argument:
"google code blogspot post specifically mentioned both GitHub 8 times and Bitbucket 3 times"
While it was appropriate (and arguably a duty as benefactor) for google to post a link to https://code.google.com/p/support-tools/ containing their export tools to github and bitbucket and the sourceforge import, that reference only takes one sentence and doesn't even require the google blog post itself to specifically mention any services. Considering that a shutdown announcement is a serious matter, it should be kept brief and limited to only information relevant to shutdown. All those specific references could have been omitted and the shutdown announcement would still make sense. By specifically mentioning certain services multiple times, the writer of the blog post has opened the door to queries about mentioning alternative services specifically. Had he written in a neutral manner (either by only posting the Wikipedia link or not mentioning any services), then it would have been inappropriate for GitLab to query for a request to be mentioned.
GitLab is faster in on some pages. The commit page probably is slower, but not by so much:
master.1 [ <=> ] 66.40K 382KB/s in 0.2s
master.2 100%[=====================>] 183.50K 662KB/s in 0.3s
Again, your milage may vary (cache) and I do agree that the commits page of GitHub feels faster most of the time.
GitLab doesn't have preview support for as many features as GitHub, but it has many other features GitHub doesn't have such as protected branches and git-annex support (version large binaries with git).
There are less integrations than GitHub but I would not say there is a lack of them https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/mode...
We think the issue tracker is good, working with labels can be improved but getting a milestone overview across projects is pretty sweet.
Availability of GitLab.com is over 99.9% at the moment http://status.gitlab.com/
Over 700 people have contributed to GitLab http://contributors.gitlab.com/
We understand if people place open source projects on GitHub, they have way more registered users. But some people choose GitLab and their numbers are growing.
For the initial HTTP request maybe and if you're in the US. Gitlab is painfully slow when loaded from a European network connection and you factor in the time it takes to fetch all resources. Cached or uncached.
> GitLab doesn't have preview support for as many features as GitHub, but it has many other features GitHub doesn't have such as protected branches and git-annex support (version large binaries with git).
Neither of which are important for Open Source projects.
> We understand if people place open source projects on GitHub, they have way more registered users. But some people choose GitLab and their numbers are growing.
I think Gitlab is a reasonable website to use for commercial hosting; I just don't see it for Open Source software.
I think protected branches are really nice for open source projects too, although I agree that most contributions will come from forks. Right now no open source projects use Git Annex but that might change now that it becomes easier to use, probably it is really nice if you have an open source game with huge digital assets.
Speaking as a European, it would be nice if you could keep it performant over here too ;)
We think the east coast of the US is the best compromise considering our user base. Can't solve speed of light :/
On GitLab, if I stumble upon any repo I can't figure which language it uses. On GitHub it is very clear. It even shows percentage of programming language used.
Open Source helps in so much for learning about programming for a noob like me and GitLab no way does that as like GitHub. Thats the one reason I don't use GitLab much, though I have an account. And one more reason why GitHub shines over GitLab for open source projects.
What reasons do you have to you believe this statement? I'm curious.
> The projects with the most stars on gitlab s gitlab itself with 221 stars right now. Even the smallest nodejs project achieves that popularity on github.
Really? I'm surprised. I started coding a forum platform and I only amassed 3 stars. On my non-furry personas, I've capped out at about 13.
I don't think popularity in github projects is fairly distributed enough to use that as a refutation of the quality GitLab has to offer. It's a bigger bandwagon, sure, but that's all.
While a big bandwagon can be attractive (it is for me), I don't think it's fair to disqualify a competitor based on this metric alone.
Did you use it? Gitlab has barely any open source projects let alone developers on it. Say as much as you want, but for many open source projects community is a big deal.
Currently there is absolutely no reason to use Gitlab. Neither does it do things better than Github or Bitbucket in any way, nor does it have a larger community. It's "just" another github clone.
> Really? I'm surprised. I started coding a forum platform and I only amassed 3 stars. On my non-furry personas, I've capped out at about 13.
The second biggest project on gitlab has 36 stars: https://gitlab.com/explore/projects/starred
The 9th largest already has less than the 13 stars you mentioned on your personal project.
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.
I don't see how this is relevant at all? First of all github did not remove that content, it IP blocked it. Secondly what do you think that gitlab would do if they would be hit by this?
Do you think it's better for github to go down for Russia entirely? Imagine that would be your proposal for what gitlab should do. Then it would even stronger enforce that gitlab is not a place to go for an Open Source project.
Why should your project suffer and become unavailable because some other project violated Russian law?
Maybe "generally no reason" would be better?
That's not a reason to use the hosted gitlab version, that might be a reason to self host gitlab.
If I find a bug in GitLab I can feasibly submit a patch for it.
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.
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
I would love to see the option to move from Google code to GitLab.
And for the whole community's benefits, we need another choice other than GitHub.