6 ms·

Why aren't you using GitHub?

44 points by oever 11y ago

coppolaemilio 11y ago
Basically, they don't want to. I don't see any relevant argument made on this text.
- nicarus1984 11y ago
  Not how I read that. >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.
pbreit 11y ago
Free private repos.
bonsai80 11y ago
Server seems to be having issues. Google cache: http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1Z5e8J:www.valdyas.org/fading/index.cgi/2015/05/29&hl=en&gl=us&strip=1 http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1...
- boudewijnrempt 11y ago
  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...
  - oever 11y ago
    Hey boud, sorry for getting your server hammered. Your blog is now getting points on the strength of the title alone.
    - boudewijnrempt 11y ago
      Well, it's down now. I guess I'll bring it up again tomorrow or so.
ryandvm 11y ago
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. Also, I don't like monocultures.
- agumonkey 11y ago
  Talking about monocultures : https://twitter.com/mjackson/status/604325015333412864 https://twitter.com/mjackson/status/604325015333412864 That tweet explain that there are numerous cool projects on codepen that you can explore.
michaelhoffman 11y ago
1) Because I prefer Mercurial. 2) Because Bitbucket gives me a free academic plan.
- ossreality 11y ago
  2) Because Bitbucket gives me a free academic plan. So does Github
fweespeech 11y ago
Google Cache: http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1Z5e8J:www.valdyas.org/fading/index.cgi/2015/05/29+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1... 1) Private repos are too expensive from a value standpoint. Its a $200/month service [ https://github.com/pricing 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.
- bonsai80 11y ago
  Regarding #2. Do you choose to pay some amount to the OSS project(s) you use for this? (seriously asking, not meaning to sound like a jerk here)
  - fweespeech 11y ago
    https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/ Yeah, for work. Not for my side projects.
bowlich 11y ago
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.
- marcc 11y ago
  You don't have to pay for private forks.
  - deleted 11y ago
    [deleted]
  - pc86 11y ago
    What does that matter? They still have over 150 repositories.
    - avalaunch 11y ago
      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".
      - nicarus1984 11y ago
        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.
      - yebyen 11y ago
        They wouldn't have to, if they were on Github's maxed-out plan already. There is no higher tier. They're already paying the most. (hypothetically)
vezzy-fnord 11y ago
GitHub's issue tracker is pretty bare bones. I always thought that was sort of reflective of its culture. 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.
pnathan 11y ago
I strongly prefer Mercurial. Github, Inc. seems like a decent company, and I like the UI. But hg roxx. :-)
- atmosx 11y ago
  Why? Are there any technical reasons or is it just the nerd-within wich pushes into the "less popular" choice?
  - mcherm 11y ago
    Yes. http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-merc... (For fairness, if you want the arguments in favor of git, try this: http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ 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.)
  - pnathan 11y ago
    sure, a number of reasons. 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.
- semi-extrinsic 11y ago
  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.
bonsai80 11y ago
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).
jordigh 11y ago
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.
- aaronbrethorst 11y ago
  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?
  - worklogin 11y ago
    No, if you read the exact sentence you quoted, it should be avoided because those value-adds are lock-ins that are hard to move to a new service.
    - aaronbrethorst 11y ago
      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.
      - cha0s 11y ago
        Embrace the usefulness! http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
newsreader 11y ago
Because I been using Bitbucket for the past five years and I have no compelling reason to switch.
Touche 11y ago
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.
joeblau 11y ago
Free private repositories; Although I'm using GitHub to host two OSS projects.
PuffinBlue 11y ago
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! But moving development to github? Bad idea.
cgtyoder 11y ago
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.
Joeboy 11y ago
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. 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.
- tajen 11y ago
  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?
  - Joeboy 11y ago
    I use http://duplicity.nongnu.org 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.
asddubs 11y ago
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.
caherrerapa 11y ago
Pricing plans for small teams with many repos and because the pull request review sucks compared to Bitbucket.
caherrerapa 11y ago
Pricing plans for small teams with many repos and because the pull request review sucks compared to Bitbucket.
zyxley 11y ago
Incidentally, for anyone who like's GitHub's features and workflow but not GitHub the organization itself, GitLab (https://about.gitlab.com/ 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.
deleted 11y ago
[deleted]
404error 11y ago
I don't use it because I am a one man show. I don't have a need for it.
Ave 11y ago
They have a tendency to remove repos that they don't agree with ideologically.

44 points by oever 11y ago

coppolaemilio 11y ago

Basically, they don't want to. I don't see any relevant argument made on this text.

nicarus1984 11y ago
Not how I read that. >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.

pbreit 11y ago

Free private repos.

bonsai80 11y ago

Server seems to be having issues. Google cache: http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1Z5e8J:www.valdyas.org/fading/index.cgi/2015/05/29&hl=en&gl=us&strip=1 http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1...

boudewijnrempt 11y ago
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...
- oever 11y ago
  Hey boud, sorry for getting your server hammered. Your blog is now getting points on the strength of the title alone.
  - boudewijnrempt 11y ago
    Well, it's down now. I guess I'll bring it up again tomorrow or so.

ryandvm 11y ago

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. Also, I don't like monocultures.

agumonkey 11y ago
Talking about monocultures : https://twitter.com/mjackson/status/604325015333412864 https://twitter.com/mjackson/status/604325015333412864 That tweet explain that there are numerous cool projects on codepen that you can explore.

michaelhoffman 11y ago

1) Because I prefer Mercurial. 2) Because Bitbucket gives me a free academic plan.

ossreality 11y ago
2) Because Bitbucket gives me a free academic plan. So does Github

fweespeech 11y ago

Google Cache: http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1Z5e8J:www.valdyas.org/fading/index.cgi/2015/05/29+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:Y9Z0KT1... 1) Private repos are too expensive from a value standpoint. Its a $200/month service [ https://github.com/pricing 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.

bonsai80 11y ago
Regarding #2. Do you choose to pay some amount to the OSS project(s) you use for this? (seriously asking, not meaning to sound like a jerk here)
- fweespeech 11y ago
  https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/ Yeah, for work. Not for my side projects.

bowlich 11y ago

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.

marcc 11y ago
You don't have to pay for private forks.
- deleted 11y ago
  [deleted]
- pc86 11y ago
  What does that matter? They still have over 150 repositories.
  - avalaunch 11y ago
    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".
    - nicarus1984 11y ago
      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.
    - yebyen 11y ago
      They wouldn't have to, if they were on Github's maxed-out plan already. There is no higher tier. They're already paying the most. (hypothetically)

vezzy-fnord 11y ago

GitHub's issue tracker is pretty bare bones. I always thought that was sort of reflective of its culture. 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.

pnathan 11y ago

I strongly prefer Mercurial. Github, Inc. seems like a decent company, and I like the UI. But hg roxx. :-)

atmosx 11y ago
Why? Are there any technical reasons or is it just the nerd-within wich pushes into the "less popular" choice?
- mcherm 11y ago
  Yes. http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-merc... (For fairness, if you want the arguments in favor of git, try this: http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ 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.)
- pnathan 11y ago
  sure, a number of reasons. 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.
semi-extrinsic 11y ago
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.

bonsai80 11y ago

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

jordigh 11y ago

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.

aaronbrethorst 11y ago
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?
- worklogin 11y ago
  No, if you read the exact sentence you quoted, it should be avoided because those value-adds are lock-ins that are hard to move to a new service.
  - aaronbrethorst 11y ago
    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.
    - cha0s 11y ago
      Embrace the usefulness! http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

newsreader 11y ago

Because I been using Bitbucket for the past five years and I have no compelling reason to switch.

Touche 11y ago

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.

joeblau 11y ago

Free private repositories; Although I'm using GitHub to host two OSS projects.

PuffinBlue 11y ago

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! But moving development to github? Bad idea.

cgtyoder 11y ago

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.

Joeboy 11y ago

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

tajen 11y ago
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?
- Joeboy 11y ago
  I use http://duplicity.nongnu.org 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.

asddubs 11y ago

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.

caherrerapa 11y ago

Pricing plans for small teams with many repos and because the pull request review sucks compared to Bitbucket.

caherrerapa 11y ago

Pricing plans for small teams with many repos and because the pull request review sucks compared to Bitbucket.

zyxley 11y ago

Incidentally, for anyone who like's GitHub's features and workflow but not GitHub the organization itself, GitLab (https://about.gitlab.com/ 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.

deleted 11y ago

[deleted]

404error 11y ago

I don't use it because I am a one man show. I don't have a need for it.

Ave 11y ago

They have a tendency to remove repos that they don't agree with ideologically.