Live data from Hacker News

Bidding farewell to Google Code

google-opensource.blogspot.com

251–260 of 428 posts

Re: Bidding farewell to Google Code

#251
post #2

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…

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.

Re: Bidding farewell to Google Code

#252

Is there any alternative that supports issue attachments? That's the one feature that I really need to live for iTerm2 but github and gitlab don't support it except for images.

GitLab developer here, and happy to let you know that support for arbitrary attachments to issues and comments was contributed by a member of community earlier this month, and will be included in GitLab 7.9, due to be released on the 22nd :)

Re: Bidding farewell to Google Code

#253
post #183
post #24

GitHub's success is due, in no small part, to their excellent interface. Google Code was, by contrast, always ugly, hard to navigate, and hard to understand. (This, of course, ignores the many features that GitHub offers, which Google Code doesn't.) I know of many companies that learned about GitHub via open-source projects, which GitHub hosts for free, and decided that it was so good that they should pay money. Host…

"It was a kind of souped-up SourceForge, rather than a serious GitHub competitor." You have no idea how much better the user experience of Google Code was compared to SourceForge. Especially from the project maintainer side. I have no idea if SF still does this, but not too many years ago to upload your files you had to upload them using SSH into a folder shared between all projects, then select your download file ou…

SourceForge has come far since way back then. All the tools have been rewritten on an open source platform in the past few years. https://sourceforge.net/create/ And the weird upload system... that was replaced 7 years ago: http://sourceforge.net/blog/download-system-improvements/

Re: Bidding farewell to Google Code

#254
post #243

Earlier quoted context omitted.

> 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 pa…

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 GitH…

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

Re: Bidding farewell to Google Code

#255
post #208
post #196

Earlier quoted context omitted.

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 r…

> 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 wi…

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.

Re: Bidding farewell to Google Code

#256

Earlier quoted context omitted.

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.

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 pul…

> 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

Re: Bidding farewell to Google Code

#257

Earlier quoted context omitted.

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.

Re: Bidding farewell to Google Code

#258

Earlier quoted context omitted.

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.

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.

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.

Re: Bidding farewell to Google Code

#260

There goes my PageRank. Thanks Google. Does anyone know of a way to make the landing page at GitHub look less confusing than the default? That is the #1 reason I went with GC. I want first time users to see descriptive text not an activity log.

A redirect should send the right signals to search engines to move ranking with work. We actually do a lot of work at google to help people find things even after a move. (independent of our own projects/products, esp..)
Post reply on HN