On Citizenship in open-source software development
medium.com
medium.com
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.
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.
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.
Also on such projects people don't know each other, and don't know how much everyone have contributed, so there's no way to have meaningful discussion and consensus.
Look at twitter/bootstrap for example. Huge number of forks for that project.
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.
With the "Login with GitHub" feature now available, this could even be a third-party service.
(github network graphs would be helpful for this if their performance was remotely acceptable)
I'd suggest that when merging a commit, checking that the email is actually valid by talking to the person concerned is probably a good idea, maybe even when they're submitting the commit through GitHub.
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.
Perhaps an explicit forward on a moribund project or something.... Hm. You're right, though. The CPAN thing works because there's a centrally managed list of unique identifiers that point to the analogue of URLs (which are stored under user's names, just like Github).
Good point.
[1] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...
GitHub's a lot like Twitter in that, and I think it's a real shame. It discourages suggestions like these, in my opinion.
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.
Just some food for thought.
I think all these experiments are worthy. Who knows what will happen but lets try.
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.
Being able to accept in a fork a PR made in upstream would be great, too.
EDIT to be more precise, my example github link should read github.com/defactomaintainer/reponame
Imagine building something you are incredibly proud of to grow legs and walk away before you wanted it to.
But social conventions are strong.
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...
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.
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.
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.- 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.
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.
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.
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
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.
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.
This is a real problem, and I hope Github tries to address it before it becomes a desolate wasteland in 5-10 years. :-)
And they gain that responsibility based on prior work.
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.
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.
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.
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.
> Is this Citizenship idea the right way? I don't know, but - at worst - it's a good discussion to have.
Completely agree.
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.
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.
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.
If I click on the source tab, I want to see the source. GitHub gets this right. Google just presents you with boilerplate garbage. No, I don't want to use Subversion. Ever again. Don't even bring it up.
The real problem is how user unfriendly Google Code is, where things are compartmentalized arbitrarily and an extraordinary amount of clicking is required to get the information you need.
The "groups" feature of that is virtually useless in my opinion. I can't stand typical web forums with their chronological ordering of posts, and even those that are threaded but don't show the thread on one page are infuriating, where many "mailing list" viewers are terrible offenders in this case. You may sift through half a dozen replies only to find the problem is still unresolved.
Stack Overflow and GitHub are examples of how to organize the user experience better. Both could improve further, but Google Code seems like a huge regression in most areas.
Great, so there's one extra click to get to it. And even that is only because we consciously chose to use Google Code to serve as the "project/community home" because GitHub is lousy at serving as that. Of course, all this was setup before GitHub Pages, IIRC. We could look into scrapping the Google Code presence now, probably, but it's a fairly low priority relative to about a bazillion other things.
GitHub gets this right. Google just presents you with boilerplate garbage.
To be fair to Google Code, they do support git, and keeping a reference to Subversion was a conscious decision that we made. You may hate Subversion with a passion, but not everybody does.
Anyway, the point is, with GitHub, by default, ALL you get is "the source tab". But there's a lot more to a project than just source code.
... GitHub are examples of how to organize the user experience better.
GitHub may be better from strictly a "how to get my hands on the source" perspective, but I think it's very weak from the "How do I get an overview of the project and the community as a whole" perspective.