How Github has changed the open source world(honza.ca)
honza.ca
How Github has changed the open source world
http://honza.ca/2011/03/7-ways-github-has-changed-the-open-source-world/
49 comments
With github, it generally feels like the focus is on a developer, whereas with something like sourceforge the focus is on the project/code. I'm not saying that like it's a bad thing either - I think it's generally been a positive shift.
It may be true that github focuses on the author (after all, projects are github.com/AUTHOR/project), but I'd say that focus is secondary to the code. Compare a project page on sourceforge (e.g. http://sourceforge.net/projects/azureus/) with one on github (like https://github.com/jquery/jquery). A sourceforge project page is just a vague arrangement of links, while github shows you the source and README right away. The author is given about the same amount of space on the page in both cases.
The same is true of BitBucket, and kinda Google Code as well, you know.
I'd agree about BitBucket, but Google Code doesn't nearly focus on the developer like the other two. It's not really made for/with the general sense of community and conversation.
I hesitated before including Google Code. I believe that it technically meets the qualifications of the features mentioned in the 7 ways list, but it really falls short of both BitBucket and GitHub in terms of its feeling of being a social code site. I guess Google Code is more optimized for searching, rather than sharing -- which makes a certain amount of sense, given its creation by the king of search, but results in a site that simply doesn't draw my interest as much as BitBucket.
8. Get people using Git (and more generally, get more people using version control for their projects)
9. Made it popular to post more than just projects (off hand I'm thinking about dot/config files)
10. Make it easier to actually provide patches to open source projects
9. Made it popular to post more than just projects (off hand I'm thinking about dot/config files)
10. Make it easier to actually provide patches to open source projects
As a Ruby developer its sometimes hard to know if a particular Gem is still being actively maintained or if there is a better, more recent alternative. I find that Github does an outstanding job solving both problems. If there haven't been commits in the last year (6 months?) I'll generally look elsewhere. That elsewhere is generally the "Network" page. :)
Y'know, there are some projects that haven't had commits for a while because they do exactly what they're supposed to do, and don't need a bunch of commits. I consider it a good thing when a project gets to the point where nobody can find any bugs and they stop adding features because it has enough of them already. I sure as hell don't want my quick, clean, elegant, productivity enhancing window manager to turn into a featuritis infected monstrosity like OpenOffice.org, after all.
---
edit: Actually, my window manager of choice has basically been abandoned by its developer several years ago, and it's still bug-free, stable, and lacking basically nothing. I finally came up with a feature enhancement I'd like it to have today, after using it for five years with no complaints or wants -- and that enhancement is really just an improvement of an existing feature.
More to the point, it's an enhancement that no window manager has, so I'm likely to need to write the code for this feature enhancement myself if I want it badly enough. I may pick up maintainership for the project to do just that.
Think about that a moment: one feature enhancement requested in have a decade, merely an extension of an already existing feature, and it's something entirely new to window managers as far as I'm aware. This thing has had no need for additional code in all that time, and it has been better as a result of all that.
---
edit: Actually, my window manager of choice has basically been abandoned by its developer several years ago, and it's still bug-free, stable, and lacking basically nothing. I finally came up with a feature enhancement I'd like it to have today, after using it for five years with no complaints or wants -- and that enhancement is really just an improvement of an existing feature.
More to the point, it's an enhancement that no window manager has, so I'm likely to need to write the code for this feature enhancement myself if I want it badly enough. I may pick up maintainership for the project to do just that.
Think about that a moment: one feature enhancement requested in have a decade, merely an extension of an already existing feature, and it's something entirely new to window managers as far as I'm aware. This thing has had no need for additional code in all that time, and it has been better as a result of all that.
As a ruby dev, this happens to work (for better or worse) because if you're not updating, it may not work with the latest version of ruby/rails/whatever. If I see a rails-related gem that had its last commit in 2009, I know some work probably needs to be done to make it work with rails 3.
Perhaps a better metric is the most recent commit combined with the number of open issues. Or maybe just the number of open issues, judged by their severity.
Perhaps a better metric is the most recent commit combined with the number of open issues. Or maybe just the number of open issues, judged by their severity.
> If you're not updating, it may not work with the latest version of ruby/rails/whatever.
Do Ruby/Rails/whoever often have releases that break backwards compatibility?
Do Ruby/Rails/whoever often have releases that break backwards compatibility?
Some gems don't function correctly with Ruby 1.9.1, and a lot have minor issues with Rails 3.
Although sometimes it's more an issue with the documentation as opposed to code issues.
Although sometimes it's more an issue with the documentation as opposed to code issues.
It varies, re: Ruby, moving from 1.8 to 1.9 (the latter of which is basically the difference between major versions, though for some reason they aren't calling it 2.0). I think things are worse in this regard for Rails than for Ruby.
Not really. Your example -- keeping up with underlying technology upgrades -- may not even require as many commits as the number of upgrades to the underlying technology version. Especially if the software is well-written without unnecessary "cleverness", software can often survive upgrades to the underlying technology without issues.
Sometimes, such changes do need to be made, though; sometimes, you have at least part of a point. On the other hand, those changes might consist of a flurry of commits every time the underlying technology's version bumps, and the project may appear dormant the rest of the time. Some might think it's a "sick" project because it only gets updates in groups every now and then, with three, six, twelve, or even eighteen months between such flurries of updates (depending on the underlying technology), but they very well might be wrong.
[Basing your impression of a given project's quality and health on project activity is dangerous.](http://blogstrapping.com/?page=2011.065.16.43.41)
Sometimes, such changes do need to be made, though; sometimes, you have at least part of a point. On the other hand, those changes might consist of a flurry of commits every time the underlying technology's version bumps, and the project may appear dormant the rest of the time. Some might think it's a "sick" project because it only gets updates in groups every now and then, with three, six, twelve, or even eighteen months between such flurries of updates (depending on the underlying technology), but they very well might be wrong.
[Basing your impression of a given project's quality and health on project activity is dangerous.](http://blogstrapping.com/?page=2011.065.16.43.41)
What window manager, by the way? I'm in UI-rage mode at the moment, and stability sounds beautiful.
AHWM
It's unlikely you'll find it in the software management system of your Linux distribution of choice, and (being not very experienced with C) I haven't managed to get it to compile on Debian -- but it's in FreeBSD ports, and has no problems at all on that platform. Given that FreeBSD is my platform of choice, that means it works for me.
Your mileage may vary, I suppose.
It's unlikely you'll find it in the software management system of your Linux distribution of choice, and (being not very experienced with C) I haven't managed to get it to compile on Debian -- but it's in FreeBSD ports, and has no problems at all on that platform. Given that FreeBSD is my platform of choice, that means it works for me.
Your mileage may vary, I suppose.
This feature bloat is exactly my issue with a lot of commercial software - especially Photoshop. With each release, it includes a load of junk most people don't want, but new ways to make files incompatible with old ones so that people have to upgrade, as well as bug fixes that should in reality have got patches.
While that may indicate the excellence of the project, it may also indicate a lack of imagination, on your part.
While your comment may indicate thinking outside the box, it may also indicate you are a condescending asshole. Only time will tell, I suppose.
Window managers (including tiling ones) are so far from a dead end in research and potential large improvements, that I think that if you can't think of anything useful that any of them does not yet do, you must be unimaginative.
That problem is alleviated by the fact that, for libraries, updates to documentation are commits as well, so even a very stable piece of software still needs the occasional commit to update a FAQ or somesuch. All in all, I've been surprised how well activity meters work when vetting software.
Even that doesn't always apply. The amount of documentation available for my favorite window manager on the (ancient) site for it is mind-boggling. The creator labels the documentation as "comprehensive" and, to quote Bill: "Baby, you ain't kidding."
For most software, though, it's true that documentation can always use improvement.
For most software, though, it's true that documentation can always use improvement.
argh, typo
Half a decade -- not have a decade.
Half a decade -- not have a decade.
i do the same. generally if the project is even on GitHub, that's a great sign it's got life.
From what I've seen, a Github profile now influences the hiring process too.
This is definitely true. I'll often check to see if a candidate has a github account when making a hiring decision. Having some interesting/good code up there can definitely move the needle a bit on a hire/no hire decision.
Absolutely. A record of solid past work can help overshadow a poor interview (nervousness, etc.) in my eyes.
If I can see the sorts of things a candidate has worked on in the past, I can more tailor the interview and ask more engaging questions. I want to know what they're passionate enough about that they will give up free time to pursue it.
None of this is specific to Github.
If I can see the sorts of things a candidate has worked on in the past, I can more tailor the interview and ask more engaging questions. I want to know what they're passionate enough about that they will give up free time to pursue it.
None of this is specific to Github.
> Force projects to include a good README
As much as we would like to believe code can be self-documenting, in most cases it is not. Having no README file can make your project more opaque. I probably shouldn't mention this in these parts, but one example of an active project without any README at all is PG's Arc. https://github.com/nex3/arc
I will concede that the Arc project does have a website that covers install instructions, but for new languages where nearly all users are newbies, having no README on GitHub can be an inconvenience.
As much as we would like to believe code can be self-documenting, in most cases it is not. Having no README file can make your project more opaque. I probably shouldn't mention this in these parts, but one example of an active project without any README at all is PG's Arc. https://github.com/nex3/arc
I will concede that the Arc project does have a website that covers install instructions, but for new languages where nearly all users are newbies, having no README on GitHub can be an inconvenience.
The complete lack of licensing information on many projects is something that Google Code tends to "fix" much better than GitHub, though -- even if Google Code is a little inferior in some other ways. It would be nice if sites like BitBucket and GitHub would do something to encourage people more strongly to actually tell us about the licenses used in their projects.
I have only recently become a major convert into the DCVS world coming from Subversion and CVS before it. When I first started going I found that git was rather hard to for me to wrap my brain around, especially since it so radically changed the way certain commands worked. So I looked at Mercurial and felt much more at home as it felt like Subversion.
Since then I've wrapped my brain around Git and absolutely love it. I now have accounts on both Bitbucket and Github and both work equally well for what I want. The only feature that I feel is missing from Github is the ability to create unlimited private repositories for free, if not at least, on their lowest paid tier.
I tend to create random projects haphazardly, and while I like to have it versioned and "backed up" somewhere where I can invite friends to collaborate with me, I don't want some of these projects out in the open. Some of them are research projects for new products I am developing, others are projects I am working on with friends that could potentially be monetized.
Don't get me wrong, I understand where Github is coming from, and being familiar with both Git and Hg is not going to hurt, it is annoying on a context switching level to have to remember how to do something in hg and then in git when switching between projects.
At the point where I am in my career I don't yet make enough money (after paying student loans, car insurance, etc...) to spend money on monthly billing paid services.
Since then I've wrapped my brain around Git and absolutely love it. I now have accounts on both Bitbucket and Github and both work equally well for what I want. The only feature that I feel is missing from Github is the ability to create unlimited private repositories for free, if not at least, on their lowest paid tier.
I tend to create random projects haphazardly, and while I like to have it versioned and "backed up" somewhere where I can invite friends to collaborate with me, I don't want some of these projects out in the open. Some of them are research projects for new products I am developing, others are projects I am working on with friends that could potentially be monetized.
Don't get me wrong, I understand where Github is coming from, and being familiar with both Git and Hg is not going to hurt, it is annoying on a context switching level to have to remember how to do something in hg and then in git when switching between projects.
At the point where I am in my career I don't yet make enough money (after paying student loans, car insurance, etc...) to spend money on monthly billing paid services.
* When I first started going I found that git was rather hard to for me to wrap my brain around, especially since it so radically changed the way certain commands worked.*
I've found Git really easy to use coming from SVN. My main problem has just been the Windows tools haven't been as intuitive as Tortoise. What issues did you first have with Git?
I've found Git really easy to use coming from SVN. My main problem has just been the Windows tools haven't been as intuitive as Tortoise. What issues did you first have with Git?
git revert did not do the same thing as svn revert, that was the first major issue I had and I put git on the shelf because of it. Only in the past year or so have I started using a DCVS. For the most part I was definitely a subversion fan boy ;-)
Check out the hg-git plugin. I use it all the time to clone projects from github using hg.
True, but isn't Git the initial game changer?
I would agree with the author, but I am still wondering why other platforms do not win. I mean, for example, SourceForge or code.google.com. Except for the first point, most hosting sites provide exactly same functionalities.
Then, I guess, the point is 'easiness' or fancy/cool user interface.
In this respect, I think github's killer feature over sourceforge is its focus on people instead of projects. Perhaps we could call it an increased democratization of open source.
Sourceforge is centered around projects. You have to register and get approval for each project separately (at least you did a few years ago, it has been a long time since I last went through the exercise). This left a significant percentage of projects with descriptions of the author's intent, but no actual code. It also meant that any third party contributions had to go back through the author (who might have lost interest).
I have never seen a project on github with no code. There is no approval process. You simply push and you are up and running. Forking allows others to start contributing right away without any action from the original author (and github really encourages you to fork projects). Then the tools that github provides makes collaboration way easier than it was in the past (pull requests vs emailing patches).
I agree with all of the things the author notes, but I really think this is github's killer feature. (Hope I didn't come off as too much of a github fanboy).
Sourceforge is centered around projects. You have to register and get approval for each project separately (at least you did a few years ago, it has been a long time since I last went through the exercise). This left a significant percentage of projects with descriptions of the author's intent, but no actual code. It also meant that any third party contributions had to go back through the author (who might have lost interest).
I have never seen a project on github with no code. There is no approval process. You simply push and you are up and running. Forking allows others to start contributing right away without any action from the original author (and github really encourages you to fork projects). Then the tools that github provides makes collaboration way easier than it was in the past (pull requests vs emailing patches).
I agree with all of the things the author notes, but I really think this is github's killer feature. (Hope I didn't come off as too much of a github fanboy).
GitHub has managed to take advantage of the Git hype and make code social in a way that SF or Google Code never could. Today's SF, although powering lots of high profile floss projects, feels increasingly dated with its traditional developer-user model. Google Code is arguably even less social and definitely lacking in features. GitHub, finally, looks great, is easy to use and has a lot of small yet very neat features that making coding easier.
BitBucket actually does everything GitHub does on that list of ways that GitHub supposedly changed the world. In fact, I find the BitBucket interface generally easier to use and easier on the eyes -- and, my God, the colors on the GitHub issue tracker pages are fucking awful.
. . . but somehow GitHub gets so much attention that many people think it's the only code hosting site in the world, just like so many idiots think that Ubuntu is the only open source operating system in the world.
. . . but somehow GitHub gets so much attention that many people think it's the only code hosting site in the world, just like so many idiots think that Ubuntu is the only open source operating system in the world.
Perhaps because Github came out first, and pioneered most of those features?
Not to say that BitBucket isn't a nice UI, but what major features did they invent? (not a rhetorical question)
Not to say that BitBucket isn't a nice UI, but what major features did they invent? (not a rhetorical question)
Well, I could be snarky and say "usability" -- which, relative to GitHub, it kinda seems like BitBucket pioneered. Frankly, though, I'm not sure whether there's something BitBucket really "invented". There doesn't seem to be much that either can do and the other cannot, aside from BitBucket's ability to make unlimited private projects (of limited size, of course) where GitHub cannot.
Usability seems to be a major difference between not just BitBucket and GitHub, though -- it's also a major difference between Mercurial and Git themselves. Between the two, I find I like Mercurial/BitBucket much more usable than GitHub/Git. The big advantage GitHub/Git has is popularity, basically, and I've never really been one to let a lack of market-dominating popularity hold me back.
Anyway . . . to answer your question more directly:
I don't pay much attention to the fiddly corner cases where they differ in total functionality, so I don't really know who came up with what features first. They've both been evolving pretty quickly, from what I've seen, so I'm not sure anyone else can really say what features one has copied from the other, unless they were working on one of the two and involved in the imitation process.
I don't even see why it matters. It's like open source software: imitation is a good thing, because good features get more widely used, and everybody wins. It doesn't have to be a competition. I just don't think holding up GitHub alone as some kind of messiah really helps anything.
Usability seems to be a major difference between not just BitBucket and GitHub, though -- it's also a major difference between Mercurial and Git themselves. Between the two, I find I like Mercurial/BitBucket much more usable than GitHub/Git. The big advantage GitHub/Git has is popularity, basically, and I've never really been one to let a lack of market-dominating popularity hold me back.
Anyway . . . to answer your question more directly:
I don't pay much attention to the fiddly corner cases where they differ in total functionality, so I don't really know who came up with what features first. They've both been evolving pretty quickly, from what I've seen, so I'm not sure anyone else can really say what features one has copied from the other, unless they were working on one of the two and involved in the imitation process.
I don't even see why it matters. It's like open source software: imitation is a good thing, because good features get more widely used, and everybody wins. It doesn't have to be a competition. I just don't think holding up GitHub alone as some kind of messiah really helps anything.
Everything? Does BitBucket support git? I thought it was using Mercurial.
Mercurial is great, but it's not git. It's a hassle to have to learn two ways of doing everything. (Being intimately familiar with git's required these days, especially for Linux and Android programmers. Mercurial's not.)
Mercurial is great, but it's not git. It's a hassle to have to learn two ways of doing everything. (Being intimately familiar with git's required these days, especially for Linux and Android programmers. Mercurial's not.)
I don't remember "Supports Git" being one of the seven signs that Git Christ the Savior has Risen.
> Mercurial is great, but it's not git.
Yeah -- it's easier to use. I've even seen Git users suggest that newbies to the world of DVCSes coming from Subversion or CVS might want to try out Mercurial first because it's easier to pick up, then migrate to Git because that's what the people suggesting this path use.
> It's a hassle to have to learn two ways of doing everything.
That's as strong an argument against Git as it is against Mercurial. Despite this, I've learned to use both -- because "it's about the code". I just choose BitBucket/Mercurial for my own projects; otherwise, I use whatever DVCS is appropriate to the project based on what the project's core team uses.
> Being intimately familiar with git's required these days, especially for Linux and Android programmers. Mercurial's not.
Hah. There are lots of Linux- and Android-related projects on BitBucket and otherwise developed within a Mercurial framework, too -- and not everybody is developing primarily for Linux and Android, anyway. Did you notice, for instance, that the majority favorite language of GitHub hipsters (Python) is using Mercurial now? Your narrow world is not everyone else's narrow world.
> Mercurial is great, but it's not git.
Yeah -- it's easier to use. I've even seen Git users suggest that newbies to the world of DVCSes coming from Subversion or CVS might want to try out Mercurial first because it's easier to pick up, then migrate to Git because that's what the people suggesting this path use.
> It's a hassle to have to learn two ways of doing everything.
That's as strong an argument against Git as it is against Mercurial. Despite this, I've learned to use both -- because "it's about the code". I just choose BitBucket/Mercurial for my own projects; otherwise, I use whatever DVCS is appropriate to the project based on what the project's core team uses.
> Being intimately familiar with git's required these days, especially for Linux and Android programmers. Mercurial's not.
Hah. There are lots of Linux- and Android-related projects on BitBucket and otherwise developed within a Mercurial framework, too -- and not everybody is developing primarily for Linux and Android, anyway. Did you notice, for instance, that the majority favorite language of GitHub hipsters (Python) is using Mercurial now? Your narrow world is not everyone else's narrow world.
I love github as much as anyone. However, why is it that Git still drives non-technical people crazy? Why do those people prefer dropbox over Git?
I'm intrigued that no-one mentions launchpad yet, it has roughly the same feature set, but doesn't put the code on the front page.
I've spoken to a couple different Open Source app maintainers who have basically said: GitHub made our community of contributors better by making it so easy to fork smaller portions of the codebase.
Where before they would basically just take abuse about issue/features (Why don't you support Markdown instead of direct HTML entry in your CMS, or whatever). Now they can just say "fork off" and have whoever complains maintain a separate codebase with their custom additions.