Kind of telling that of the other comments I see here so far, nobody seems to be addressing what the article is about: because they don't trust github, a for-profit company who hides their source code, to not some day pull a Sourceforge.
We had this discussion in the GNU project. The basic conclusion I could see was that simply using github as a place to host the repo like Linus does with Linux is not a problem. In typical GNU fashion, the biggest problem people saw was with the non-free javascript that entails from using the github web interface. Some also were concerned with whole SaSS problem with github, were they tie you up with wikis, bug trackers, pull requests and a lot of other things around just git hosting that are difficult to transplant to another service.
they tie you up with wikis, bug trackers, pull
requests and a lot of other things around just
git hosting that are difficult to transplant to
another service.
Are you saying that some people say GitHub should be avoided for GNU projects because it's too useful?
"tie you up" might have been better written as "lock you in". Those tools can certainly be made available through other means via free (as in freedom) software. It takes work in doing so and that's what Github is selling - ease and convenience.
Github has obviously done a great job of making these tools useful and approachable. The point about having ultimate control over that data though is valid. Github might be able to mitigate some of these concerns with something like Google's "Data Liberation Front", providing a contractual agreement with users to make their data easily exportable if they choose to do so. Of course, even that may not be enough for some projects and for them it's a totally valid option to avoid github (and similar closed SaaS options).
GitLab CEO here, we want to give people options to prevent lock in. GitLab CE already has a one click importer for all your GitHub.com repo's and issues. We're working on automatically importing your pull requests and wiki's too.
In the private discussions I saw, there was some disagreement over whether Github is SaSS or not, but many felt like it was.
(Btw, the official stance is that there is one GNU project with many packages, and all of these packages form part of the GNU operating system. So R, GIMP, Gnome, and Octave are GNU packages and part of the GNU project and operating system.)
No one's forcing you to use GitHub's wikis, issue tracking, or pull request facilities. One would only use these features if they were useful. Hence my question.
The wiki is trivial to export (it's just https://github.com/gollum/gollum, and you can clone the git repo with your wiki data directly). Issues and PRs are less trivial, but there's nothing inherently difficult about writing an exporter. The lock-in mostly comes from the ecosystem of third-party tools that's gradually developing which either only support github or work poorly with other hosts.
For WebODF, we also use GitHub because WebODF is a JavaScript project and there are many JavaScript programmers on GitHub. I'm also a member of the KDE community as is boud with the Krita project. But KDE was traditionally more a C++ community. That is becoming more diverse now.
I agree with all the points in the blog, which is why I posted it. But moving WebODF to a separate server would remove a lot of the easy of accepting contributions, so we're not doing that at the moment.
I don't use Github because their pricing model for hobby projects sucks. Bitbucket's model of only charging for projects that have more than 5 users makes much more sense.
Github's payment plans don't work out well for a team that's doing lots of small repositories.
My team is pretty small (5 devs) and we easily have 150+ repositories for different packages that all get wrapped into our main product. Github charges per private repository and 125 repositories maxes out github's organizational plans. Hence, we are currently on bitbucket.
The team also didn't want to have to make a business justification everytime someone wanted to fork a repository or throw something together experimental. We would rather just be free to create as many repositories as we please and not have to concern ourselves with the question of whether it should be a public or private repo.
It matters because he specifically mentions that the team "didn't want to have to make a business justification everytime someone wanted to fork a repository".
Yes, but that doesn't imply they're justifying a financial cost. It could be that they need to justify creating a new repo and figuring out how/where to host it.
The maxed out organizational plan ($200/mo) is still only 125 private repositories.
GitHub is just not financially feasible for small organizations with many small, private repos. For small teams like mine (3 + an occasional contractor) that have close to 200 repositories of closed-source code, $200/mo is laughable, particularly when we can host all of that on BitBucket for free because we never go above 5 users.
I don't use Github because of their unacceptable TOS. They reserve the right to delete my account and all content for any reason, at any time, without giving prior notification.
Who can operate a real business with that hanging over your head? Seems very foolish to me.
Page is down, but my answer to the title is that I don't (always) use github because it's really, really easy to set up a private repo on the Debian VPS I'm renting anyway.
That's it. Admittedly you are now responsible for backups, but hopefully you back up your server anyway. And of course you don't get the snazzy web interface but I don't imagine most of us use that much anyway.
Sorry, is there an easy way to backup a server (e.g. Debian)? Do you use the provider's "backup your instance" feature? How can you be confident that they'll never close your account and lose ypur backups, for example based on an assumption that something you're doing isn't legit?
I use http://duplicity.nongnu.org to back up my data (not the whole server). I don't know if it's necessarily the best thing these days, but it works OK.
I think the risk of losing my VPS, my working copy and my backups at the same time is acceptably low, given that the world would not end if my git repos disappeared anyway.
Yeah, my poor blosxom instance running on an ancient ideapad I got for free at a meego conference in Dublin isn't made for loads like ycombinator causes. It's got a load average of over 150 now. The moment my screen session started getting slow, I thought -- someone posted this on ycombinator...
Reading the article, I don't think this was meant as a question to the group here. The question/title feeds into the article explaining why they don't use github. Perhaps a more forum-friendly title would have been "Why We Don't Use Github." I'd be curious to hear people's thoughts on the statements made in the article (see posts with cache link if you can't load it).
1) Private repos are too expensive from a value standpoint. Its a $200/month service [ https://github.com/pricing ] for what I can get for $50/month worth of VM time internally.
Actually, hg sucks if you're collaborating with different people on different projects, because everyone has different hooks and extensions and so they insist on different workflows. On git everyone has compatible configs and the workflows mainly differ just in the number of long-running branches.
If you don't have issues, good for you. I'm not saying hg is unusable, particularly if you're using it within an organization or community that enforces a set of tools, workflows etc. But if you look at the github community where people tend to fork dozens of projects from a diverse set of people, that clearly isn't happening with hg, and I think the "Some assembly required" is part of the reason why. Git, on the other hand, is very much "Batteries included".
hg interface makes sense. there's clear distinction in semantics between commands and flags. that is not the case with git. git demands being a wizard to be excellent; hg doesn't.
hg repos typically are clones of each other: it takes work to not have all changesets replicated everywhere. the implication of that is that there's no forgetting branches; ergo, there's no confusion about what piece of the dag is pushed and what isn't. it's all pushed.
hg branches are 'true' branches, as opposed to refs. I could go into depth into how that plays out in better ways than git, but that's more of an actual essay.
hg extensions give hg more power - if you really want to get complicated, it's not unbelievably difficult.
hg project makes certain guarantees about stability of interface; tooling is easy to develop around that. tooling makes life better, often.
as a general rule of thumb, the hg project and experience adopts a principled way of choices; this flows out into the code and experience. it's a very clean and "better is better" way of working.
(For fairness, if you want the arguments in favor of git, try this: http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ . But honestly, I prefer Mercurial. It doesn't matter, because the vast majority of the people I collaborate with are using Git, but if I could make the choice, I would use Mercurial.)
Incidentally, for anyone who like's GitHub's features and workflow but not GitHub the organization itself, GitLab (https://about.gitlab.com/) has an open-source and self-hostable CE version that's very much "well-executed GitHub clone", with a paid (but still self-hostable) EE version with stuff like extended LDAP/Active Directory and JIRA integration.
I agree with the article, and the stated reasons, but a little nitpick:
"And Github's business model is exactly what SourceForge's was."
I don't think that's actually true, is it? Githubs business model is based on enterprise customers, which to my knowledge, SourceForge wasn't. Not that that diminishes the point.
I actually prefer the cgit interface. It's fast and simple. I just don't trust myself to run a server and do backups, etc. for something as important as source code.
For convenience or in case you can't visit Google or something, here's the text of the article from Google cache as the origin server is down [mirror for the ctrl+f folks]
---
Why aren't you using github?
Is a question we, Krita developers, get asked a lot. As in, many times a week. Some people are confused enough that they think that github is somehow the "official" place to put git repositories -- more official than projects.kde.org, phabricator.kde.org, git.gnome.org or where-ever else. Github, after all, is so much more convenient: you only need a github account or login with your social media account. It's so much more social, it's so cosy, and no worries about licensing either! So refreshing and modern.
So much better than, say, SourceForge ever was! Evil SourceForge, having failed to make a business out of hosting commercial software development projects is now descending to wrapping existing free software Windows installers in malware-distributing, ad-laden installer wrappers.
The thing is, though, Github might be the cool place to hack on code these days, the favourite place to host your projects: that is exactly what SourceForge was, too, back in the days. And Github's business model is exactly what SourceForge's was. And if that isn't a warning against giving your first-born children in the hands of a big, faceless, profit-oriented, venture-capital-backed company, then I don't know what is!
And yes, I have heard the arguments. Github is so familiar, so convenient, you can always remove your project (until Github decides to resurrect it, of course), it's git, so you're not losing your code revision history! But what about other artefacts: wiki, documents, bugs, tasks? Maybe you can export them now, I haven't checked, but what will you import it into?
I've spent over ten years of my life on Krita. I care about Krita. I don't want to run that sort of risk. One thing I've learned in the course of a mis-spent professional life is that you always should keep the core of your business in your own hands. You shouldn't outsource that!
So, one big reason for not moving Krita's development to github is that I simply do not trust them.
That's a negative reason, but there are also positive reasons. And they all have to do with KDE.
I know that a lot of people like to bitch about KDE -- they like to bitch about the layout of the forum, the performance of the repo browser, the size of the libraries, the releases of new versions of the Plasma Desktop, about fifteen year old conflicts with the FSF (which somehow proves to them that KDE isn't trustworthy...) The fact is that especially in the Linux world, a bunch of people decided ages ago they didn't like KDE, it wasn't their tribe and they apparently find it enjoyable to kick like a mule everytime we do something.
Well, shucks to them.
Then there are people for whom the free software world is a strange place. You don't see something like Corel Painter being hosted together with a bunch of other software on a bigger entity's website. It's confusing! But it's still strange, to many people, to see that Krita shares a bug tracker, a forum, a mailing list platform, a git repository platform with a bunch of other projects that they aren't interested in.
Well, I see that as a learning moment
And not as a hint that we should separate out and... Start using using github? Which would also mean sharing infra with a bunch of other projects, but without any sense of community?
Because that is what make KDE valuable for Krita: the community. KDE is a big community of people who are making free software for end users. All kinds of free software, a wild variety. But KDE as a community is extremely open. Anyone can get a KDE identity, and it doesn't take a lot of effort to actually get commit access to all the source code, to all projects. Once in, you can work on everything.
All the pieces needed to develop software are here: websites, forums, wiki's, bug trackers, repo hosting, mailing lists, continuous-integration, file hosting, todo management, calendaring, collaborative editing, file hosting. The system admin team does an incredible job keeping it all up and running, and the best thing is: we own it. We, the community, own our platforms and our data. We cannot be forced by a venture capitalist to monetize our projects by adding malware installers. We own our stuff, which means we can trust our stuff.
And we can improve our platform: try to improve a closed-source, company-owned platform like github! So suggestions for improvement are welcome: we're now looking into phabricator, which is a very nice platform giving a lot of the advantages of github (but with some weird limitations: it very clearly wasn't made for hosting hundreds of git repos and hundreds of projects!), we're looking into question-and-answers websites. Recently, the continuous integration system got improved a whole bunch. All awesome deveopments!
>So, one big reason for not moving Krita's development
to github is that I simply do not trust them.
>We cannot be forced by a venture capitalist to monetize
our projects by adding malware installers. We own our
stuff, which means we can trust our stuff.
Whether you agree or disagree, they did in fact make an argument.
We had this discussion in the GNU project. The basic conclusion I could see was that simply using github as a place to host the repo like Linus does with Linux is not a problem. In typical GNU fashion, the biggest problem people saw was with the non-free javascript that entails from using the github web interface. Some also were concerned with whole SaSS problem with github, were they tie you up with wikis, bug trackers, pull requests and a lot of other things around just git hosting that are difficult to transplant to another service.