Howdy all, I've never been much of a user of Git, but I appreciate that the most popular DVCS is free software. The worrying part is that most people who *say* they're using Git are using Github. I have heard rumblings that Github is problematic: it's non-free compared to Git being free, it's centralised where Git is federated, it requires users to use protocols that are incompatible with Git. In short, it undermines and defeats most of the benefits of a federated free-software tool. Here is an article by someone who has decided after a long usage to switch from Github, for these reasons and more. The problem is that github is most emphatically not git. If a person using git (and therefore send-email) wants to collaborate with someone using github, one of the two of them has to give in and use an interface they deliberately decided not to use. There’s no way around it: github does not supplement git, github replaces git. Deciding whether to use github versus just git is an either/or proposition. Two products with nearly identical functionality: one is open-source, and the other is closed-source and depends on the other. Not a hard choice. <URL:http://bytbox.net/blog/2012/08/leaving-github.html> -- \ “… Nature … is seen to do all things Herself and through | `\ herself of own accord, rid of all gods.” —Titus Lucretius | _o__) Carus, c. 40 BCE | Ben Finney
On 17 September 2012 23:10, Ben Finney <ben+freesoftware@benfinney.id.au> wrote:
The worrying part is that most people who *say* they're using Git are using Github. I have heard rumblings that Github is problematic: it's non-free compared to Git being free,
Unfortunately, where github is concerned, I think there is some FUD also, which may not always be true. They give you full access to your all your data, using open protocols. So it is not as bad as some other closed source cloud solutions that don't give you access to any of your data. Unless you pay to host private projects, most information is public information, so privacy issues don't apply (unless say cloud based mail solutions). Unlike other cloud solutions, they appear to be actively developing the code and constantly improving it. I get the impression that their support will be good too (not that I have ever needed it). It is true that github is closed source, and you cannot make changes yourself (probably the biggest limitation), host it on your own servers (not without paying lots of money for the enterprise version anyway, and even that doesn't allow you to make your own changes), or host private code (without paying). There is also the issue that we have to trust their closed source code to be secure and prevent unauthorised changes (using gpg signed git tags can help here for git repositories but not the issue tracker).
it's centralised where Git is federated,
Nothing stopping you pushing your git repositories to other servers. You could even synchronous the issue list and wiki if you wanted to. There is always going to be the issue that us, as software consumers, expect to see an "official" upstream version of the code, and git doesn't do anything to change this. Not a github issue. For synchronising the issue list, in Debian there is the following package, never used it myself: Package: sd Priority: optional Section: universe/perl Installed-Size: 856 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: Christine Spang <christine@debian.org> Architecture: all Version: 0.75-0ubuntu1 Depends: perl, libdatetime-perl, libdatetime-format-natural-perl, liburi-perl, libprophet-perl (>= 0.72), libhtml-tree-perl, libtime-progress-perl Suggests: librt-client-rest-perl, libhiveminder-perl, libnet-jifty-perl, libemail-address-perl, libwww-perl, libnet-trac-perl, libnet-google-code-perl, libnet-github-perl, libnet-redmine-perl Filename: pool/universe/s/sd/sd_0.75-0ubuntu1_all.deb Size: 134676 MD5sum: 46413f1cc2578f63adcc3c8fa2dcc505 SHA1: c8cc7db0f2a7710e772b52c48e3667012f44fc35 SHA256: fcbf7d0170375bdfb6802ec330c6ad9ffffb47a6dcd479d67603f52cc3264103 Description-en: peer-to-peer bug tracker SD is a peer-to-peer bug tracker that's built for sharing and use both online and offline. With SD, you can sync your bugs back and forth between other instances of SD, and even between SD and other bug trackers that SD supports. Since SD does not require a network connection for use and stores bug information locally, you can always access your bugs, no matter where you are. . Currently, SD supports syncing between SD and RT, Hiveminder, Trac, GitHub, Google Code, and Redmine (read-only). . SD is built on top of Prophet, a distributed database system. Homepage: http://search.cpan.org/dist/App-SD/ Description-md5: 3eb9ca839e78f1c2c50fbdf4da09e4e2 Bugs: https://bugs.launchpad.net/ubuntu/+filebug Origin: Ubuntu I think there might be others, possibly based on git, this is the only one I can find right now.
it requires users to use protocols that are incompatible with Git.
What protocols are incompatible with git? The issue tracking isn't done using git, most issue trackers don't support git however, even open source ones. Everything else (including wiki) uses standard git protocols.
In short, it undermines and defeats most of the benefits of a federated free-software tool.
Really?
The problem is that github is most emphatically not git. If a person using git (and therefore send-email) wants to collaborate with someone using github, one of the two of them has to give in and use an interface they deliberately decided not to use. There’s no way around it: github does not supplement git, github replaces git. Deciding whether to use github versus just git is an either/or proposition.
There is nothing that says you can't use github alongside some other hosting website. Just push your git changes to both. github happens to be the best available right now. gitorious is perhaps the best I know of that is open source, but is rather complicated to install and maintain, and doesn't have a number of features github does, e.g. integrated issue tracking. There is also an open source github clone, which is, ironically, hosted on github. Not used it, so I don't know how good it is: http://gitlabhq.com/ https://github.com/gitlabhq Anybody who is seriously concerned with github being closed source, perhaps should look at this. -- Brian May <brian@microcomaustralia.com.au>
On Mon, Sep 17, 2012 at 11:10 PM, Ben Finney <ben+freesoftware@benfinney.id.au> wrote:
Howdy all,
I've never been much of a user of Git, but I appreciate that the most popular DVCS is free software.
The worrying part is that most people who *say* they're using Git are using Github. I have heard rumblings that Github is problematic: it's non-free compared to Git being free, it's centralised where Git is federated, it requires users to use protocols that are incompatible with Git.
In short, it undermines and defeats most of the benefits of a federated free-software tool.
Here is an article by someone who has decided after a long usage to switch from Github, for these reasons and more.
The problem is that github is most emphatically not git. If a person using git (and therefore send-email) wants to collaborate with someone using github, one of the two of them has to give in and use an interface they deliberately decided not to use. There’s no way around it: github does not supplement git, github replaces git. Deciding whether to use github versus just git is an either/or proposition.
I'm a big user of git and github, and I don't particularly like the places where github tries to improve upon stuff that git already does - mainly pull requests (I can't actually think of any others). Having said that, it's obvious why they had to create them - pushing patches into someone's mailbox and saying "there you go - figure it out" is hardly in line with their intent to make git easy for the masses. But the above quote is simply not true. I don't like pull requests, so I can (and do) just use `git remote`, `git pull`, `git merge` from my local box, and push the results up to github as a dumb repository. It works just fine, and it's just plain git. Granted, github *discourages* people sending emails-with-patches-attached - you can still do it if you want, although many folks users will look at you funny. I would discourage using send-email as well, for the record. Now, some people will tell you the only way to push changes *to them* is to send them a github pull request, which I always find baffling. But that's no different from me telling my contributors that they must send me a smoke signal with their diffs - it's the fault of the maintainer for requiring that, not the service for providing it.
On Tue, Sep 18, 2012 at 10:53:03AM +1000, Tim Cuthbertson wrote:
On Mon, Sep 17, 2012 at 11:10 PM, Ben Finney <ben+freesoftware@benfinney.id.au> wrote:
Howdy all,
I've never been much of a user of Git, but I appreciate that the most popular DVCS is free software.
The worrying part is that most people who *say* they're using Git are using Github. I have heard rumblings that Github is problematic: it's non-free compared to Git being free, it's centralised where Git is federated, it requires users to use protocols that are incompatible with Git.
In short, it undermines and defeats most of the benefits of a federated free-software tool.
Here is an article by someone who has decided after a long usage to switch from Github, for these reasons and more.
The problem is that github is most emphatically not git. If a person using git (and therefore send-email) wants to collaborate with someone using github, one of the two of them has to give in and use an interface they deliberately decided not to use. There’s no way around it: github does not supplement git, github replaces git. Deciding whether to use github versus just git is an either/or proposition.
I'm a big user of git and github, and I don't particularly like the places where github tries to improve upon stuff that git already does - mainly pull requests (I can't actually think of any others). Having said that, it's obvious why they had to create them - pushing patches into someone's mailbox and saying "there you go - figure it out" is hardly in line with their intent to make git easy for the masses.
But the above quote is simply not true. I don't like pull requests, so I can (and do) just use `git remote`, `git pull`, `git merge` from my local box, and push the results up to github as a dumb repository. It works just fine, and it's just plain git. Granted, github *discourages* people sending emails-with-patches-attached - you can still do it if you want, although many folks users will look at you funny. I would discourage using send-email as well, for the record.
Now, some people will tell you the only way to push changes *to them* is to send them a github pull request, which I always find baffling. But that's no different from me telling my contributors that they must send me a smoke signal with their diffs - it's the fault of the maintainer for requiring that, not the service for providing it.
I found it something of an annoyance to have had to create a GitHub account in order to contribute to some free software projects. A federated pull request protocol used between all the code hosting/collaboration sites would be excellent, but due to the commercial interests providing/supporting these services this is unlikely to happen. As for GitHub itself, it by no means replaces Git. In fact, as a developer, you can do very little with GitHub without using Git. The mechanisms offered by GitHub may be the preferred way to contribute to many projects, and perhaps mandated by a few, but this is at most a mild annoyance for those who would prefer to use other hosting/collaboration services or none at all. I see no major software freedom issues for free software projects using GitHub; the data being worked with is the (public) source code and nothing particularly special is being done to that data (cloning, branching, merging, etc). It is therefore not a problem that GitHub itself is not free software (though GitHub have liberated many free tools and libraries, which is good). There are similar sites/services that run on free software. I think free software advocates should stick to those where possible, and in all other cases not let the details of where or how to contribute get in the way of actually contributing to free software. Regards, Fraser
_______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-m...
participants (4)
-
Ben Finney -
Brian May -
Fraser Tweedale -
Tim Cuthbertson