On Citizenship in open-source software development

I run a lot of projects on github (<a href="http://github.com/qdot" rel="nofollow">http://github.com/qdot</a>). Probably way too many, especially since it's mostly weird device drivers, which means I don't have a lot of people stopping by to help because the learning curve is kinda steep. This means I tend to have things bitrot as I move on to new and different hardware.<p>The problem is, hardware never dies, it just gets discontinued, its ebay price rises, and the people using it get more and more zealoty as the ranks of users are pared down to those who REALLY require whatever hardware it is. So any time I release a driver, I expect to get email from that point until the end of time. Which sucks, 'cause I have serious project ADD and get bored quick.<p>Here's two things I've come up with to help the situation in what little ways I can.<p>I've started releasing all software I think might require further community maintenance under an organization instead of my personal account. For instance, I've got a bunch of health device drivers that I wrote, many of which I don't care about anymore. Instead of letting them rot on my personal account, I opened an org for them (<a href="http://github.com/openyou" rel="nofollow">http://github.com/openyou</a>). This means I can still have a part on the projects, as well as fork back to my personal account to keep pull request workflows going, but if community wants to come along and work on it, I just add them to the org, give them the perms, and we're good. Having the projects on the org makes things look a bit more "open" then just having it sit on my personal account.<p>I'm also trying to live in all parts of the cycle. This means if I find a project that's gone quiet that I still use (and I can't get ahold of the author, or if I can, get the authors permission, which hasn't been a problem thus far), I'll create an org, fork to the org, find people in the issues lists that have things that haven't been resolved, and reach out to see if I can get a community group started for new maintenance. This seems to work out well.

What <i>should</i> happen is that is that the BDFL (aka king) should appoint a successor if they cannot give a project the attention that it deserves. I've seen this happen successfully many times, and have never seen the "wrong" person chosen.<p>The problem is that this doesn't happen often enough. It's a very difficult thing to do, putting your baby up for adoption.<p>So what GitHub should do is a little bit of social engineering to encourage inactive maintainers to bless a fork. It's more than that, of course: you have to ask somebody if they're willing to step up. It's unlikely that one of the forks is comprehensive but there are likely people that would be willing to make their fork comprehensive rather than see the project abandoned.<p>Handing over the reigns to a committee does not work very well, in my experience. It's better than abandonment, but that's all you can say about it.

On a more meta note, I find the channel of feedback and suggestions to GitHub to be virtually non-existent. I see plenty of great suggestions, and I myself have come up with a few, but they always end up as faint echoes leading to nothing. I find this particularly sad for a company that's marketed at being all about "open", participatory, community-driven, etc. The unreadable feeds on GitHub are emblematic of this problem. <i>EDIT:</i> Ditto for the Issues system, which scales really poorly.<p>GitHub's a lot like Twitter in that, and I think it's a real shame. It discourages suggestions like these, in my opinion.

"automatic merging" upon consensus -- had to laugh at this idea, the ratio of merge requests that would merge cleanly, automatically is low. Generally they have to be rebased against the exact branch they are to be merged against with human intervention to rectify not only merge conflicts and broken tests but possible interaction issues with recent changes on master branch. In any case, arbitrary changes can (and sometimes should) be made to bring the branch in line with the main code. So branch merges that were "voted in" still need human intervention to merge. Should that then be re-voted on, given that merges and conflict-resolved rebases/merges can include arbitrary changes? Obviously, but what if more changes go into the target branch while folks are getting around to ratifying the rebased merge branch? There still needs to be trusted "merge officers" or whatever who can and will clean up, test, and merge popular branches which were voted on. You can't get around that.

I got so much flack for suggesting a year ago on a repo. The 'maintainer' came back with the point that he/she gave commit access to everyone-ish. The problem with that is you will get very aggressive individuals who will commit, and then others who will revert and this cat&#60;-&#62;mouse game continues on until the community suffers, the project dead.<p>Just some food for thought.<p>I think all these experiments are worthy. Who knows what will happen but lets try.

Great idea. Maybe a quick fix for that, before implementing such a different change, would be to automatically point to the most active fork in project description when there hasn't been activity for a while.<p>Being able to accept in a fork a PR made in upstream would be great, too.

I still think there should be one maintainer with absolute control. Otherwise, "citizens" could take away someone's open source project with "democracy" or mob rule.<p>Imagine building something you are incredibly proud of to grow legs and walk away before you wanted it to.

Article would have been MUCH better if he showed actual examples of these problems (specific github repos, dates, current state). Beyond that, I think Github fits the natural tendency of projects to be heavily driven by a small number of individuals. The idea of democratization is often silly on open source projects because the level of merit between individuals varies massively.

I think almost every active user has something they want from GitHub, so I thought I'd get this off my chest in the comments:<p>Personally, I use Issues a lot, and if it would be great to be able to upload any file related to that issue.<p>I understand how that could be costly, and you might not want to push such a potentially complicated feature onto your 3.4m.<p>So:<p>- Let the majority use your free (meaning no-extra-costs) storage with current limitations.<p>- Add a tab under the repo settings labeled 'File Storage'<p>- Under Repo X &#62; Settings &#62; File Storage, let me use my own S3 key/bucket pair for that repository's Issues files.<p>(Example: PSD, .zip/.rar/.tar/.bz2, etc related to the project.)<p>Thanks for listening.

Should this be handled by Github? Package systems like RubyGems seem like the natural point to designate an "owner" of a library.

If you add karma to Github you’ll need to actually turn it into a currency that you can buy/sell/exchange/etc.

<p><pre><code> 1. Gets lots of karma from silly/fake projects 2. Send in a PR to a high profile project with obfuscated malicious code 3. ??? 4. Profit.</code></pre>

Voting seems unattractive to me. If I trusted somebody and had enough respect for their work to give them commit access to a repo of mine, then I'd also trust them to merge whatever 3rd party patches they wanted. No point in tying things up with a slow layer of democracy. I can imagine having problems getting people to bother to vote at all on work they have no interest in.<p>Actually I don't have my own repos these days, but it's irritating to me how large the barriers to contribution really are in the free software world. We have complicated software, often more complicated that it should be, written in all kinds of different languages and frameworks, to the point that just finding the latest sources, getting the dependencies, figuring out how to build it is hard enough, then also understanding it well enough to make your changes, and then also dealing with the idiosyncrasies of whatever person or group is maintaining the thing, to actually get a patch accepted. It's not easy even for a decent programmer.

Or try and make github/bitbucket into something like an open source app store. Provide features to allow project creators/developers to build a business model around their own projects. Not all can be commercialized but I am sure some can be - having a support business model.<p>This could be on lines similar to nginx/varnish etc.<p>Sourceforge tried sometthing like this, but maybe there were flaws in how they tried to implement it.<p>You would need something like an SLA created once which can be shared by similar projects and have project leaders/communities (OSS Project leaders/communities) use variations of it which they use to provide support for their customers.<p>All fee collections/payments etc happen through a github/bitbucket gateway.

I think github is moving there...<p>Currently it has graph on individual's profile that tells what he has contributed. - Something like OpenBadges can be added to "top contributor to repo" etc.<p>One can compare fork and see age of the same. So say original contributor is no longer maintaining it, one can check fork. Visually.<p>- A good value addition could be showing it somehow on front page.<p>Issue voting - Yes, number of people watching could be good.<p>My addition would be - Explicit mention of license mention on landing page. like google-code - tags like google-code

Actually I think this is the project for another service.<p>GitHub would put too much at risk in following such a huge change in its core.<p>Really, this is a good idea, for a competitor.

Isn't this the model that Linus Torvalds (effectively) uses with Linux? He ultimately is the maintainer, but delegates responsibilities to trusted individuals for large chunks of the codebase.<p>And they gain that responsibility based on prior work.

Ummmm, this seems like mental master-BEEP(watch your mouth shaft)<p>Core redesign of GitHub's product from hosted source control repository to Open Source social construct. This seems like a completely different product from GitHubs core.

If owner has abandoned his project why not fork it and fix it yourself?

I think this could be a great opt-in feature.