Kallithea – Aself-hosted alternative to GitHub
kallithea-scm.org
kallithea-scm.org
Self Hosted (in order of anecdotal popularity) - Gitlab - Gitea (fork of Gogs) - Gogs - Phabricator - GitBucket - Rhodecode - Kalithea (fork of Rhodecode) - GitPrep - Allura - GitSSB - Pagure
If you want hosted Git, there are many competitors, but some of the notable are - Gitlab - Attlassian BitBucket - Google Cloud Repositories - Amazon CodeCommit - Canonical Launchpad - Sourceforge
All of which assume you want git, but other DVCSs are Mercurial (which is supported by a number of the above servers) and Fossil.
If you don't know what you want, you probably want hosted.
One of the annoying things, to me, is that the solutions I see all model code reviews as records in databases instead of doing something distributed and reusable.
They provide encrypted git hosting for free: https://keybase.io/blog/encrypted-git-for-everyone
No issues, pull requests, and social features though.
RhodeCode continued to be developed, and in 2016 the RhodeCode Community Edition was re-licensed under AGPLv3.
[1] https://sfconservancy.org/blog/2014/jul/15/why-kallithea/
Regarding Kallithea, I installed and used it for work. I like Kallithea, although the features and interface are not as well developed as some alternatives discussed here.
Kallithea is far more lightweight to setup and admin that Gitlab, but not as full-featured as Gitea, which I recommend to anyone who asks.
ui is something personal i guess, both aren't perfect. For usage in 50+ users enterprise rhodecode is much better.
It has more features, and it feels this project is actually moving forward contrary to kallithea https://www.mail-archive.com/kallithea-general@sfconservancy...
The only thing we liked more is GPL license over AGPl of rhodecode
It has a "pages" plugin, at the time of writing it is mentioned in the README
https://hub.docker.com/r/gitlab/gitlab-ce/ (run as docker image)
I think the question you were hoping to have answered is, "Why would you pick this over GitLab?". And potentially the discussion you wanted to invoke was, "Is there an advantage to going with a full free software solution as opposed to a product that is primarily proprietary, but has an open core?"
Personally, I think there is, but in the case of GitLab it may not matter. Now that there are some free software heavy hitters (Gnome and Debian) who rely on the open core of GitLab, there is some more assurance that this open core will not become a kind of cripple-ware try-before-you-buy situation. Those groups have enough horse power to maintain the open part of GitLab if they choose to do so.
Having said that, I think there is room for other free software entries in this space and I'm looking forward to seeing how it plays out. In some ways the acquisition of GitHub may be the catalyst necessary to get things started, and I think it's a good thing.
While moving is very painful, the fact that git is distributed means that setting up camp somewhere else is pretty smooth. Even the headaches of the other stuff, such as issues et al, will probably be handled by whoever the new host is.
Fossil: https://fossil-scm.org/
Notable user: https://sqlite.org/whynotgit.html
Their characterisation of GPL vs BSD licensing in the git vs fossil comparison is frustrating though. I wonder if there is a way to convince them to update it because it really reduces their credibility. I'm specifically referring to "the GPL license grants the right to read source code to anyone who promises to give back enhancements". This is just completely incorrect. From the GPL V3: "You may make, run and propagate covered works that you do not convey, without conditions". In other words, as long as you don't "convey" (distribute) your changes, you can do whatever the heck you want (including reading the source code).
> To a first approximation, the GPL license grants the right to read source code to anyone who promises to give back enhancements. In other words, the act of reading GPL source code (a prerequiste for making changes) implies acceptance of the license which requires updates to be contributed back under the same license. (The details are more complex, but the foregoing captures the essence of the idea.) A big advantage of the GPL is that anybody can contribute to the code without having to sign additional legal documentation because they have implied their acceptance of the GPL license by the very act of reading the source code. This means that a GPL project can legally accept anonymous and drive-by patches.
That whole section in their documentation is just weird, to be honest. There is nothing in the BSD license that requires you to sign additional legal documentation either. The fossil project requires copyright assignment to include your code in the project (many FSF projects require the same thing with their projects for similar reasons).
They should just delete that section so that they don't look like they don't know what they are talking about.
Edit: They could rewrite the section to say that by distributing the code you have implicitly agreed to the license. This is more or less true. The license actually hinges on the fact that you never have to agree, but that if you don't agree then you only that the rights assigned to you by copyright (see section 9 of the GPL v3). The bit that's weird is that there is absolutely no difference with the BSD license -- you don't have to agree, but if you don't, then you don't have a license. The only real difference is that the BSD license doesn't explicitly say so.
At first I thought they were trying to make a political point, but the more I look at it, the more I think they just want to justify requiring copyright assignment. The obvious question is "Why don't all those GPL projects require it?" So they came up with something plausible, but completely incorrect.
I've been using this for years now since you get free private repos.
Left feedback, no response. Left feedback again, still no response. Moved everything to GitLab.
It's really hard to see great apps like this (and Reddit as a more recent example) destroyed by.. seemingly.. people given too much time to do their jobs. I'm not a front end guy, but the feeling I get is that it has the same problem as backend. Can't just cobble a few well-tested Django views together any more, must have a 16-microservice mess to ensure the CV is fully padded. Makes me so sad
For a bit of entertainment, take a look at this open issue https://jira.atlassian.com/browse/SRCTREEWIN-7374 created on 01/Jun/2017. Yes, an issue that makes the product unusable for many users, that has been open for over a year now.