4 ms·

So, I'm not a huge GitHub fan for open source projects. Why? Because while it's a great site and tool (don't get me wrong, I can understand the attraction), G

by jaaron 16y ago

So, I'm not a huge GitHub fan for open source projects. Why? Because while it's a great site and tool (don't get me wrong, I can understand the attraction), GitHub can be a pain in the ass for end users. How so? I don't know how many times I've found some code I wanted to use only to find a dozen or more forks, none of which have been merged back together and a handful of which have patches I'm interested in. It's way, way too easy in GitHub for the community to get lost in the forks. There's no clear mechanism for communication (mailing list, forums, etc.) and not enough pressure to merge code back into a common repository. Sure it democratizes contributions, but it also makes a mess. There's a real need and advantage to having a canonical, master repository - something users can trust that's been properly vetted, tested and debugged. There's a lot of value in a single place for discussion with public, searchable archives so that users can learn the project history, why decisions were made and, if necessary, ask new questions. There's nothing worse than having to use Google to search blogs for outdated documentation and discussions split across little more than tweets. GitHub encourages forking but it doesn't necessarily encourage merging. Successful open source projects which a large, invested user base require a bit more structure, stability and developer support than GitHub encourages. It may be a great place to start a project, but at some point, I can see projects graduating to their own infrastructure and a real, organized community.

alecthomas 16y ago
You core complaint seems to be that maintainers don't maintain their software. This is sadly true in many cases, but I would argue that GitHub has actually improved the situation. First, by making it trivial to get patches to the maintainer. Prior to GitHub, if you wrote a patch for a project, you would have to track down the appropriate channel to submit the patch, then jump through any hoops required. Whether it be mail directly to the maintainer, a patch on a bugtracker (probably also requiring signup), mail to a mailing list (again probably requiring signup), patch having to be in a particular format, etc. The second problem is what to do if the maintainer doesn't respond? Sometimes you might end up forking the project and hosting it in yet another random web page. Sometimes you might just end up dumping the patch onto the net, in the vain hope that someone else would find it if they had the same problem. I have done both, a number of times. With GitHub, the patches are clearly there as forks. At least with GitHub, the barrier to writing a patch and getting it in the face of the maintainer is almost zero. This is an improvement. If they don't respond, at least it's obvious to users from the proliferation of forks, and if they're lucky they can find the particular fork that fixes their issue. Solving the human problem of maintenance is a big challenge. If GitHub solves that as well, I'll be amazed.

by jaaron 16y ago

alecthomas 16y ago

You core complaint seems to be that maintainers don't maintain their software. This is sadly true in many cases, but I would argue that GitHub has actually improved the situation. First, by making it trivial to get patches to the maintainer. Prior to GitHub, if you wrote a patch for a project, you would have to track down the appropriate channel to submit the patch, then jump through any hoops required. Whether it be mail directly to the maintainer, a patch on a bugtracker (probably also requiring signup), mail to a mailing list (again probably requiring signup), patch having to be in a particular format, etc. The second problem is what to do if the maintainer doesn't respond? Sometimes you might end up forking the project and hosting it in yet another random web page. Sometimes you might just end up dumping the patch onto the net, in the vain hope that someone else would find it if they had the same problem. I have done both, a number of times. With GitHub, the patches are clearly there as forks. At least with GitHub, the barrier to writing a patch and getting it in the face of the maintainer is almost zero. This is an improvement. If they don't respond, at least it's obvious to users from the proliferation of forks, and if they're lucky they can find the particular fork that fixes their issue. Solving the human problem of maintenance is a big challenge. If GitHub solves that as well, I'll be amazed.