4 ms·

Forking, The Future of Open Source, and Github

50 points by jlhamilton 17y ago

blasdel 17y ago
About the only useful thing the Apache Software Foundation can lend your project is their imprimatur of enterpriseyness, though that comes with a lot of bureaucracy to back it up. "Nobody ever got fired for buying IBM", and the ASF practically is IBM!
- omouse 17y ago
  Wow. Are you seriously complaining about that? One day someone's bitching that open source is for commies and can't make you any money and then another someone's complaining that the open source companies that do make money are TOO enterprisey!
  - olefoo 17y ago
    Being dissatisfied with the status quo is one of humanity's best and worst traits.
njharman 17y ago
"Fork" is a poor choice of verb for what I think he is describing/dvcs/github allows. More like experimental branch this dudes gonna do his thing on and if it's good we'll absorb it into the "main" project. Which, btw, has been going on forever, git[hub] just makes it easier. A Fork means there's irreconcilable differences and the dev base is splitting into 2-3 camps, old mainline, new forkers, people who leave in disgust over lack of coop.
- samdk 17y ago
  'Fork' isn't his choice of word. On github, a fork is just your version of someone else's repository.
- JulianMorrison 17y ago
  Sure, it used to mean that, in the days of CVS. But a github-style fork is a fully independent project in theory, it could go anywhere. It doesn't have to reintegrate. It might out-speed the main project and come to replace it. It might change emphasis and shoot off on a tangent. It's not really the same thing as having a copy of the source and making some private changes.
- schacon 17y ago
  "fork" is what we use to describe a user-branch of a project, where another user has write access to their own fork of the project. other dvcs hosts use the term 'fork' to describe this as well, such as BitBucket and MicroSofts CodePlex. Google Code has a similar concept but they call them 'clone's. I think many people now consider "fork" a good thing, not an irreconcilable branch of the codebase.
rlpb 17y ago
You can't just mix and match patches automatically. Someone has to resolve merge conflicts. There is a cost to this: developer time. Distributed version control systems are being so successful because they allow developers to more easily do what they have been doing all along anyway (take Linus' job, for example). I don't think there is a major paradigm shift here; just a revolution in tooling. There will still always be a main line. That main line will not be "distributed", even if the way that changesets get there might be. Most of us will only be using releases taken from the main line. Forks will carry on happening from time to time, but just like now most will work to avoid them because of the inefficiencies that result.
- steve19 17y ago
  For me it has been a revolution. No language, framework or concept has changed my development process more in the past decade. I have been able to contribute patches (both code and documentation) to many projects where I otherwise would have not had the time or energy to bother contributing. Sure, my previous attitude may have been selfish, but if it took an hour to fix a bug in a library that I am using for a throwaway script, I am not going to spend another hour subscribing to mailing lists, emailing developers and then persuading them that my patch is worth merging. In GitHub I just fork, push my patch, and notify the owner of the original repo. If he chooses to pull in the patch, that is his problem. If anyone else who is having the same problem wants to use my repo, they can do so.
  - durin42 17y ago
    Practically, that's just not workable long term. Ideally, you want to keep using more or less the same library as everyone else, otherwise versioning becomes even more of a nightmare than it already is.
  - rlpb 17y ago
    I agree with you - my experience has been the same. In the past you'd have had to work out a patch by hand and then perhaps publish it somewhere, which was a pain to do and so didn't happen often. Now the tools have improved making this much easier and so is happening much more everywhere. I have personal branches of the Linux kernel and a dozen or more libraries, and can keep them up to date easily. But the process remains the same. Your fork is no doubt invaluable to you, but unless the original maintainer pulls your patch, your fork is likely to be a dead end in terms of development - except perhaps for the odd person who needs to fix the same bug and finds your patch. My point is that the development model has not changed. The maintainer can still optionally pull in your patch, or not. Most users will continue using the maintainer's releases. If the maintainer drops the ball then there will be a fork - but that would have happened in the past anyway. Distributed version control has been a revolution - but a revolution in tooling, not of the centralised release model.

50 points by jlhamilton 17y ago

About the only useful thing the Apache Software Foundation can lend your project is their imprimatur of enterpriseyness, though that comes with a lot of bureaucracy to back it up. "Nobody ever got fired for buying IBM", and the ASF practically is IBM!

omouse 17y ago
Wow. Are you seriously complaining about that? One day someone's bitching that open source is for commies and can't make you any money and then another someone's complaining that the open source companies that do make money are TOO enterprisey!
- olefoo 17y ago
  Being dissatisfied with the status quo is one of humanity's best and worst traits.

njharman 17y ago

"Fork" is a poor choice of verb for what I think he is describing/dvcs/github allows. More like experimental branch this dudes gonna do his thing on and if it's good we'll absorb it into the "main" project. Which, btw, has been going on forever, git[hub] just makes it easier. A Fork means there's irreconcilable differences and the dev base is splitting into 2-3 camps, old mainline, new forkers, people who leave in disgust over lack of coop.

samdk 17y ago
'Fork' isn't his choice of word. On github, a fork is just your version of someone else's repository.
JulianMorrison 17y ago
Sure, it used to mean that, in the days of CVS. But a github-style fork is a fully independent project in theory, it could go anywhere. It doesn't have to reintegrate. It might out-speed the main project and come to replace it. It might change emphasis and shoot off on a tangent. It's not really the same thing as having a copy of the source and making some private changes.
schacon 17y ago
"fork" is what we use to describe a user-branch of a project, where another user has write access to their own fork of the project. other dvcs hosts use the term 'fork' to describe this as well, such as BitBucket and MicroSofts CodePlex. Google Code has a similar concept but they call them 'clone's. I think many people now consider "fork" a good thing, not an irreconcilable branch of the codebase.

rlpb 17y ago

You can't just mix and match patches automatically. Someone has to resolve merge conflicts. There is a cost to this: developer time. Distributed version control systems are being so successful because they allow developers to more easily do what they have been doing all along anyway (take Linus' job, for example). I don't think there is a major paradigm shift here; just a revolution in tooling. There will still always be a main line. That main line will not be "distributed", even if the way that changesets get there might be. Most of us will only be using releases taken from the main line. Forks will carry on happening from time to time, but just like now most will work to avoid them because of the inefficiencies that result.

steve19 17y ago
For me it has been a revolution. No language, framework or concept has changed my development process more in the past decade. I have been able to contribute patches (both code and documentation) to many projects where I otherwise would have not had the time or energy to bother contributing. Sure, my previous attitude may have been selfish, but if it took an hour to fix a bug in a library that I am using for a throwaway script, I am not going to spend another hour subscribing to mailing lists, emailing developers and then persuading them that my patch is worth merging. In GitHub I just fork, push my patch, and notify the owner of the original repo. If he chooses to pull in the patch, that is his problem. If anyone else who is having the same problem wants to use my repo, they can do so.
- durin42 17y ago
  Practically, that's just not workable long term. Ideally, you want to keep using more or less the same library as everyone else, otherwise versioning becomes even more of a nightmare than it already is.
- rlpb 17y ago
  I agree with you - my experience has been the same. In the past you'd have had to work out a patch by hand and then perhaps publish it somewhere, which was a pain to do and so didn't happen often. Now the tools have improved making this much easier and so is happening much more everywhere. I have personal branches of the Linux kernel and a dozen or more libraries, and can keep them up to date easily. But the process remains the same. Your fork is no doubt invaluable to you, but unless the original maintainer pulls your patch, your fork is likely to be a dead end in terms of development - except perhaps for the odd person who needs to fix the same bug and finds your patch. My point is that the development model has not changed. The maintainer can still optionally pull in your patch, or not. Most users will continue using the maintainer's releases. If the maintainer drops the ball then there will be a fork - but that would have happened in the past anyway. Distributed version control has been a revolution - but a revolution in tooling, not of the centralised release model.