Why aren't you using GitHub?
valdyas.org
valdyas.org
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.
The overall issue with SaSS is this. Bit tl;dr, but worth reading it when you have the time:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
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.)
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).
Possibly because the page is unreachable (for me, at least).
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.
Also, I don't like monocultures.
That tweet explain that there are numerous cool projects on codepen that you can explore.
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.
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.
Who can operate a real business with that hanging over your head? Seems very foolish to me.
Edit: For those who don't know:
On the server:
mkdir ~/whatever.git
cd ~/whatever.git
git init --bare
On your local machine:
git clone me@myserver.com:~/whatever.git
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.
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.
http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1...
2) Because Bitbucket gives me a free academic plan.
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.
2) I prefer to support open source projects.
Yeah, for work. Not for my side projects.
But hg roxx. :-)
(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.)
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.
That's just like, your opinion, man. I don't have significant issues...
(and it's not terribly hard to do per project configuration)
I'm also not too keen on the entire gamification aspect that GH places on you. I find it gratuitous.
When it comes to layout and design, I think cgit is the leader, though GH is a close second perhaps.
"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.
---
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!
But moving development to github? Bad idea.
>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.