

On Citizenship in open-source software development - christophe971
https://medium.com/products-i-wish-existed/ddd1f7be1415

======
qdot76367
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.

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

~~~
ckdarby
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.

~~~
astrodust
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.

~~~
kaeawc
Maybe a maintainer can mark a repo as orphaned and others can bid to adopt it
using their karma? Then the maintainer has a list of people to talk to about
the future of the project... just helping make that transition easy would be
nice.

~~~
astrodust
A simple project setting that says "Advertise as orphan" would suffice. Then a
banner would appear on the page saying "This project is looking for a
maintainer!" and have something akin to an apply button where you might add a
short comment about your interest.

With the "Login with GitHub" feature now available, this could even be a
third-party service.

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

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

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

~~~
oelmekki
> 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.

~~~
Tobu
_doesn't work_. Edit wars and arbitrative administrativia are a major social
problem on Wikipedia, and it has a problem retaining contributors.

------
oelmekki
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
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/
_defacto_ maintainer/reponame

------
alttab
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
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
You pay taxes for government, regardless of how democratic it is or isn't, not
for democracy.

------
MetaCosm
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
> 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://github.com/github/aws-s3/tree/url_for-with-parameters)

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

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

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

~~~
jmmcd
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.

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

~~~
kmfrk
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
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).

------
gcb0

       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
Why can't you do this now?

~~~
gvc
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.

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

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

------
shahjigar
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

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

~~~
kmfrk
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
> 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
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
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.

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

~~~
Tobu
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.

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

~~~
mindcrime
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.

~~~
Sander_Marechal
> 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.

~~~
mindcrime
_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._

IMO, yes. Providing some kind of mechanism to make it easier to gain cohesion
between all the disparate forks is definitely at least part of the answer. I
haven't spent a lot of time thinking about this, though, and I don't pretend
to have any real concrete suggestion in mind.

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

