On Citizenship in open-source software development

https://medium.com/products-i-wish-existed/ddd1f7be1415

by christophe971 • 13 years ago

205 81 13 years ago

oelmekki2• 13 years ago

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.

Being able to accept in a fork a PR made in upstream would be great, too.

ewheeler• 13 years ago

Agreed. And this wouldn't have to wait for github to implement. Perhaps its possible to create a webservice that could examine the forks in a network graph to identify the most active fork -- and provide a url for the repository that resolves to this most active fork. Something like bestfork.com/reponame --> github.com/newmaintainer/reponame

EDIT to be more precise, my example github link should read github.com/defactomaintainer/reponame

brendanobrien• 13 years ago

+1 I think many of us would pitch in on a hacked-together version of this just hosted on github. The repo that builds this out could itself be a testing ground for the project.

julien_c• 13 years ago

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

kmfrk3• 13 years ago

I'm not really sold on this idea, and if it ends up getting implemented, it should definitely be on a per-repo basis.

I might very well turn something like this off, so the "karma" should only exist within the sphere of a repo or (forked) project.

This would just lead to a StackExchange-like gamification of the whole system.

garretruh• 13 years ago

Agreed. A dev with 100s of "karma points" on a certain PHP project should start at 0 on other projects (both of the same and different languages).

jjm• 13 years ago

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<->mouse game continues on until the community suffers, the project dead.

Just some food for thought.

I think all these experiments are worthy. Who knows what will happen but lets try.

oelmekki2• 13 years ago

> The problem with that is you will get very aggressive individuals who will commit, and then others who will revert and this cat<->mouse game continues on until the community suffers, the project dead.

Which is exactly how wikipedia works (with the concept of admins who can protect pages, though). I wonder if this could apply to FOSS development.

Tobu3• 13 years ago

doesn't work. Edit wars and arbitrative administrativia are a major social problem on Wikipedia, and it has a problem retaining contributors.

j_s• 13 years ago

The Pull Request Hack

https://news.ycombinator.com/item?id=5357417

saraid2162• 13 years ago

http://www.cc.gatech.edu/classes/AY2001/cs6470_fall/LTAND.ht...

smsm423• 13 years ago

If the community is not functional - i.e. people can't find consensus on patches - I don't think automatic solution can fix it. It can enable functioning community to handle things better - i.e., enable to hold votes more efficiently if the community is into voting, or enable to process patches more quickly if it's ok for the community to merge them. But if some people want the patch in and some want it out, automatic merge is not going to solve it - only to piss off those who want it out and alienate them from the project. And give others feeling that it's ok to force decisions through without hearing out the others.

kmfrk3• 13 years ago

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. EDIT: Ditto for the Issues system, which scales really poorly.

GitHub's a lot like Twitter in that, and I think it's a real shame. It discourages suggestions like these, in my opinion.

Serow225• 13 years ago

I've had good luck by just emailing support@github.com; they told me that this is their preferred way to submit suggestions/feature requests.

neilxdsouza• 13 years ago

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.

This could be on lines similar to nginx/varnish etc.

Sourceforge tried sometthing like this, but maybe there were flaws in how they tried to implement it.

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.

All fee collections/payments etc happen through a github/bitbucket gateway.

trumbitta2• 13 years ago

Actually I think this is the project for another service.

GitHub would put too much at risk in following such a huge change in its core.

Really, this is a good idea, for a competitor.

kmfrk3• 13 years ago

There are two sides to this: a problem and a suggested solution.

People abandoning projects are a real problem. One way to go about it is to give all the people watching it a notice when the repo owner hasn't interacted with the repo in, let's just say, three months.

They could just leave it at that, or they could add a post mortem note with the most popular forks, or call for a vote for the unofficial official replacement repo.

The problem is real, but like you, I don't like the suggested solution all that much.

pnathan• 13 years ago

> People abandoning projects are a real problem

This is a real problem, and I hope Github tries to address it before it becomes a desolate wasteland in 5-10 years. :-)

sanj• 13 years ago

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.

And they gain that responsibility based on prior work.

ninkendo• 13 years ago

Well, Linus still ultimately pulls from his lieutenants' repos though. Nobody has direct push access to Linus's repository but Linus (if I recall, at least.) That's functionally equivalent to github's pull request system.

What's better about Linux is the fact that Linus cares enough to keep things up to date and have a functioning release process with freezes, etc. All of that can be done in github, it just requires maintainers to put in the effort.

magic_man• 13 years ago

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

mindcrime4• 13 years ago

Because now you're on the hook to maintain that fork forever. And because your fork, by definition, has diverged from "the mainline" because there really isn't any "mainline" anymore. You might have 2 or 3 or 10 or 100 other people who also forked just to fix one random bug or whatever, but there's no real cohesion or interaction between all these isolated forks.

Best case, one of the forks clearly emerges as "the" new primary repo and everybody shifts their focus there. But that doesn't always happen. It's a real problem with the fork-centric model that Github promotes. Of course, one could argue that this state of affairs is still better than the "old way" where forking a project was a very heavyweight process and rarely happened at all. But that doesn't mean the current model couldn't be improved further.

Is this Citizenship idea the right way? I don't know, but - at worst - it's a good discussion to have.

christophe971• 13 years ago

Perfect answer.

Sander_Marechal• 13 years ago

> but there's no real cohesion or interaction between all these isolated forks.

Isn't this the real issue that should be fixed then? Some way when you form a repo, you get notice of all the forks and PR's of the original repo, giving you the possibility to merge everyone's work and become the defacto upstream.

shurcooL• 13 years ago

Extremely well put.

> Is this Citizenship idea the right way? I don't know, but - at worst - it's a good discussion to have.

Completely agree.

smsm423• 13 years ago

>>> Because now you're on the hook to maintain that fork forever.

Yes, with power comes responsibility. If you don't want the responsibility, don't ask for the power.

>>> but there's no real cohesion or interaction between all these isolated forks.

If there is enough people interested in the project, that can find one who wants to take maintainership. If they can't, the project doesn't have that much value for them.

>>>> It's a real problem with the fork-centric model that Github promotes.

I don't see a problem here. If there's a strong community, fork changes naturally gravitate back there due to the advantages of community size. If there isn't, making random people be able to mess with the code base is not going to fix it.

astrodust4• 13 years ago

The idea here is not unlike "squatter's rights". If you abandon a project, other people should be able to take it over and bring it back to life.

Forks and forks of forks and forks of forks of forks have the effect of diffusing effort, where the main project has the effect of focusing effort.

mindcrime4• 13 years ago

I think part of the problem is that GitHub doesn't do a lot to support the "community" around a project. GitHub started off as just a code repository, and while it's grown, there's still - to me - something missing. Then again, I haven't spent much time messing with GitHub pages. So maybe my thinking on this is somewhat outdated.

Still, something like Google Code "feels" like it is more "project centric" than "source code centric" if you get what I mean. There's specific places to do things like linking in Google Groups or mailing lists, project blog, Twitter account, etc. And the way it's organized just makes it feel like more of a "project home".

Compare:

https://github.com/fogbeam/Quoddy

with

http://code.google.com/p/quoddy/

Anyway, what I'm getting at is, if GitHub did more to foster a cohesive community around projects, I think it would help with the "abandoned project" thing, since there would be more of a sense of "go here and discuss whose repo is going to become the new mainline" etc.

amalag• 13 years ago

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

bryanlarsen• 13 years ago

What should 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.

The problem is that this doesn't happen often enough. It's a very difficult thing to do, putting your baby up for adoption.

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.

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.

oskarth• 13 years ago

What about an email saying something like

Looks like you haven't been very active on project <foo> lately, <bar>. Would you like to hand your baby over to <baz> or <quux> perhaps?

where baz and quux are people who have been ranked as being most active in the given repo.

EDIT: With a click here to hand over your repo to someone else (and lift that heavy burden off your shoulder), obviously.

ckdarby2• 13 years ago

There's no call to action. Someone (including myself) will open the email, realize there's no immediate call to action and be like, "Ya I'll get to that" and nothing will ever happen.

underscoremark• 13 years ago

How about a system that ranks the "popularity" and activity on all the forks, and simply lists/suggests these forks when a repository is considered inactive? The community will figure it out ("this fork is the suggested source"), and no action is required on behalf of the owner of the original repository.

ollysb• 13 years ago

The problem seems to be that projects just lapse, the owner's stop paying attention and the number of forks starts to pile up. Perhaps when the number of forks hits a certain point everyone that has a fork should receive an email asking if they'd be happy to maintain the project. People could then put themselves forwards and the original maintainer could then review the candidates and decide who should take over (or confirm that they want to maintain the project).

tracker13• 13 years ago

But what about popular projects... I could see that if there are > than X forks over Y time period with commits and pull requests to the main project without any accepted changes.

Look at twitter/bootstrap for example. Huge number of forks for that project.

ckdarby2• 13 years ago

The biggest problem I've come across on Github is actually getting in touch with the prior maintainer. If the user disables issues on the repo, doesn't list their email nor their github username doesn't match up with something like twitter it becomes impossible to get in touch with them.

There's been 3 repos I've attempted to take over that had no one working on them for +6 months and this was exactly what happened.

masukomi3• 13 years ago

I've had the same problem and have an oddly related problem. I have a really good contributor to one of my projects. The only way I can get in touch with him is via github issues. There's nothing in his profile that'll let me get contact him, or even google him.

astrodust4• 13 years ago

If GitHub had an "adoption center" for unwanted projects, that would be a step forward. At least give it to a maintainer who's interested.

trurl42• 13 years ago

In git every commit contains the authors email.

Vivtek2• 13 years ago

On CPAN, you can be added as a co-maintainer if there is a long-standing bug with inactive maintenance, you've fixed it in a way that's eminently usable by the maintainer, and you can demonstrate long-term fruitless attempts to contact the maintainer.

In the Github context, since pull requests are obvious demonstrations of the first two criteria, it seems to me the most logical solution would be simply to move existing forks over to a new maintenance fork owned by a popular fork maintainer with an explicit governance mechanism. Then the original owner isn't interfered with, but the new forked community king can go ahead with centralized management of the overall project if the community agrees with that.

alexchamberlain• 13 years ago

There's very little coordination between forks and URLs point directly at repos, so I'm not sure how this would work.

bcantrill• 13 years ago

Agreed -- what is needed is a peaceful transition of power from one BDFL to the next (which we've seen with many projects) or (better) to a benevolent oligarchy. A democracy, on the other hand, is emphatically the wrong way to build software (or, frankly, anything) -- and for open source in particular it leads one down the ruinous path of open source governance.[1]

[1] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...

alttab• 13 years ago

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.

Imagine building something you are incredibly proud of to grow legs and walk away before you wanted it to.

wmf• 13 years ago

People who equate open source (really peer production, but they don't understand the difference) with democracy always forget that in democracy the citizens have to pay taxes.

stormbrew• 13 years ago

You pay taxes for government, regardless of how democratic it is or isn't, not for democracy.

vidarh• 13 years ago

"Absolute control" is gone the moment you make something open source. Even if Github doesn't make it easy, nothing stops anyone from forking your projects and convincing people to work on his fork instead other than social conventions.

But social conventions are strong.

masukomi3• 13 years ago

that's not a problem with this proposal. All pull requests approved by the community end up in a non-master branch. The officially sanctioned version (master ) would remain untouched until the maintainer merged in the community changes.

saraid2162• 13 years ago

I don't think I'll ever stop being awestruck by the amount of fear the average hacker expresses when confronted by even the slightest democratic concept.

yarrel• 13 years ago

You work at a co-op?

apalmer• 13 years ago

Ummmm, this seems like mental master-BEEP(watch your mouth shaft)

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.

ericb• 13 years ago

This could be a totally optional mode, but a default.

Tobu3• 13 years ago

GitHub might provide mechanism, but there is way too much policy in these proposals. Much of it could be implemented outside, though. If it's successful GitHub might take steps to remain the centre of gravity.

mrilhan• 13 years ago

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:

Personally, I use Issues a lot, and if it would be great to be able to upload any file related to that issue.

I understand how that could be costly, and you might not want to push such a potentially complicated feature onto your 3.4m.

So:

- Let the majority use your free (meaning no-extra-costs) storage with current limitations.

- Add a tab under the repo settings labeled 'File Storage'

- Under Repo X > Settings > File Storage, let me use my own S3 key/bucket pair for that repository's Issues files.

(Example: PSD, .zip/.rar/.tar/.bz2, etc related to the project.)

Thanks for listening.

MetaCosm• 13 years ago

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.

davidw• 13 years ago

> actual examples of these problems

I think anyone who uses github enough has run into more than a few.

Look at github's very own fork of one project:

https://github.com/github/aws-s3/tree/url_for-with-parameter...

https://twitter.com/davidnwelton/status/304972225411440641

gcb02• 13 years ago

   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.

BCM43• 13 years ago

Why can't you do this now?

gvc• 13 years ago

Yeah, I'm not really sure what his point was with that. It's not that the article proposes a god github account that call push to any repo without being watched.

gcb02• 13 years ago

because you either have to:

- convince everyone that your fork is better

- pass the obfuscated code by the project owner who is very knowledgeable of the code base he started.

roryokane• 13 years ago

You can avoid this problem by making karma repo-local.

postfuturist• 13 years ago

"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.

saidajigumi• 13 years ago

As the maintainer of an an alternately alive/not-really-alive github-based project, a problem with changes being voted in is that many submitted PRs are of fairly low quality.

Just because an idea is needed by the consumers of a project doesn't mean that any given implementation will be satisfactory. Many voters will tend to be uncritical and/or have different standards. E.g. did the submitted change include tests? Did it pass existing tests? Did it implement a feature that was actually needed (e.g. did it solve a "docs" bug via a "code" patch)? Bikeshedding over existing functionality? The list goes on.

I'll also note that GitHub's great CI integration support (used by Travis CI, the Jenkins GitHub plugin, etc.) can significantly aid the proposals in TFA. E.g. a PR that doesn't pass CI would automatically be ineligible for merging.

tmorton• 13 years ago

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

tracker13• 13 years ago

I agree for the most part... as long as that package system has a way of rolling to a new maintainer because of action/inaction of the old maintainer.

jmmcd• 13 years ago

Yes this is a crucial point. For most end users, the version on PyPI, CPAN, RubyGems, whatever, is the canonical version. Only the original author has the right to push a new release there. So whatever solution Github and/or its community comes up with for the overall issue, it needs to take account of this.

qdot76367• 13 years ago

I run a lot of projects on github (http://github.com/qdot). 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.

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.

Here's two things I've come up with to help the situation in what little ways I can.

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 (http://github.com/openyou). 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.

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.

shahjigar• 13 years ago

I think github is moving there...

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.

One can compare fork and see age of the same. So say original contributor is no longer maintaining it, one can check fork. Visually.

- A good value addition could be showing it somehow on front page.

Issue voting - Yes, number of people watching could be good.

My addition would be - Explicit mention of license mention on landing page. like google-code - tags like google-code

incompatible• 13 years ago

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.

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.

On Citizenship in open-source software development

Related Stories