Will the real exception_notification please stand up?
A while ago, I wrote about some concerns of mine regarding git and github. Today, I was looking around, because I wanted to add the exception_notification code to a site of mine, and ran into this:
http://github.com/rails/exception_notification/network
Scroll all the way to the right, and you'll see that there are a bunch of relatively current forks, and none of them seem to share recent changes. So which one is the 'real' one? My guess would be the one belonging to 'rails', but who knows... maybe that one has been abandoned?
Once again, this is nothing 'new': it has always been possible to fork open source code. What I wonder about is the mentality of just going off to work on your own stuff without contributing anything back. The results are a bunch of different forks, each of which may potentially contribute something interesting, but none of which appears to have collected all the new work.
Trackbacks
Use the following link to trackback from your own site:
http://journal.dedasys.com/trackbacks?article_id=2149
about {{count}} hours later:
"The results are a bunch of different forks, each of which may potentially contribute something interesting, but none of which appears to have collected all the new work."
This is what gene pools look like. Given a sufficiently large population, a sufficient degree of recombination, and selection based on fitness, we might expect intersting evolution of the software. I am very curious to see how large the population and how informed the selection needs to be for this sort of system to be distinguishable from a randomly diverging forked code.
about {{count}} hours later:
You've stumbled on Github. This is social networking and development combined. DVCS 2.0, with tags and AJAX. Weeeeh!
Did you actually expect to find something sensible?
about {{count}} hours later:
I think in this case its quite easy to chose the right one: Take the one from Rails, the biggest user. That one should be quite stable and at some point in the future they might pull in the changes if they make sense. Or try to find out from where Rails originally pulled exception_notification.
If you stumble upon some weirdness before that, you can still check out the forks to see if its fixed there. The other versions might even be hacked-up variations which got thinned down for a special purpose and aren't generally useful, but its still nice to have access to them, isn't it?
I share some of your concerns but not really in this case :)
I must admit the fork-madness on Github is actually an improvement to the last time I worked with Rails: Back then also everybody forked other people's code but you had to hunt down the most recent version from some blog somewhere on the internets.
BTW, I like the Gitorious approach a lot better (you register a main project like it has always been and people fork from that central one), but unfortunately Gitorious is chronically broken.
about {{count}} hours later:
I think in this case its quite easy to chose the right one: Take the one from Rails, the biggest user. That one should be quite stable and at some point in the future they might pull in the changes if they make sense. Or try to find out from where Rails originally pulled exception_notification.
If you stumble upon some weirdness before that, you can still check out the forks to see if its fixed there. The other versions might even be hacked-up variations which got thinned down for a special purpose and aren't generally useful, but its still nice to have access to them, isn't it?
I share some of your concerns but not really in this case :)
I must admit the fork-madness on Github is actually an improvement to the last time I worked with Rails: Back then also everybody forked other people's code but you had to hunt down the most recent version from some blog somewhere on the internets.
BTW, I like the Gitorious approach a lot better (you register a main project like it has always been and people fork from that central one), but unfortunately Gitorious is chronically broken.
about {{count}} hours later:
If Gitorious is chronically broken, use repo.or.cz. That allows for the same type of forking and it works, albeit slow sometimes.
1 day later:
This is new, but not in the way you think. GitHub doesn't cause people to fork their code. It just helps them do it in the open, where you can see it (and maybe even use it).
Every company I've ever worked at has had made at least a few custom changes to the open source projects we used. Some of them were submitted upstream but never merged. Some weren't submitted, either for business reasons or because they weren't of interest outside the company. In the past, all of those non-merged changes were hidden inside the corporate firewall or on individual users' hard drives and you'd never know they existed. Now at least you can see what other people are up to.
As an example, here's my company's fork of the ActiveJS project on GitHub (and yes, we are working with the upstream maintainer to get these changes merged in): http://github.com/mbrubeck/activejs