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...
Wow dude, not only is using someone's quote on your website without consent pretty unclassy, using their employer to add legitimacy and make it seem like they're speaking on behalf of the company is just not ok at all.
Just to be clear, I asked the person that was quoted what he thought about it as I posted it and he seemed pretty relaxed https://twitter.com/sachinag/status/576145655120277504 but I still thought it was better to remove it.
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 :-)
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:
And now you're talking about "engineers" and "enterprise" and "real" and "sophisticated".
bkuhn salvaged what he could without trying to get into the legalities of the GPL revoking you did (which the GPL itself forbids), but still I feel very betrayed by what you did with Rhodecode.
Wow, there is someone really angry and offensive here and not really telling the truth ...
It is sad to see how often forks go downhill if they were purely based on ideologies and not with the user and general good for the project in mind.
But anyway, we welcome and fully support everyone to fork our old GPL versions, the world does not need less but more source code management systems, especially since we lost now one of the key players in Google Code.
As can be seen in my blog post and various talks in the subject, the Kallithea community faced two choices: a fork of only the GPLv3'd components, or a lengthy GPL enforcement battle with Rhodecode, who violated the GPL by changing to a non-Free-Software license for code that combined GPL'd software that wasn't copyrighted by Rhodecode.
If Rhodecode would go back to a pure GPLv3 model for its software and develop the software in pubic again, I think the fork could be easily resolved and we could all work together again. Thus, only one simple act of yours would resolve the fork entirely, sebastiank123, will you take that act?
Meanwhile, I'm sure the Free Software user community can make the easy and obvious choice between a community-run, developed-in-public Free Software project that complies with GPLv3 and a for-profit-corporate run, developed-in-private, semi-Open-Source project that has a history of GPLv3 compliance problems.
But I heartily recommend people look at Gitlab...