I have a confession to make. I’m bad at open-source. Not writing the code. I’m pretty good at that. I can even write pretty good documentation. I’m bad at all the rest: patches, mailing lists, chat rooms, bug reports, and anything else that might fall under the heading of “community.” I’m more than bad at it: I don’t like doing it and generally try to avoid it.
I write software to scratch an itch. I release it as open-source in the vague hope that someone else might find it useful. But once I’ve scratched the itch, I’m no longer interested. I don’t want to found a “community” or try to herd a bunch of belligerent, independent-minded cats. I’m not in it for the money. I’m not even in it for the fame and recognition. (OK, maybe a little bit for the fame.)
But this age of “social” insists that everything be a community. Deoderant brands beg us to “like” their Facebook pages and advertising campaigns come accesorized with Twitter hash tags. In software, you can’t just release a bit of code as open-source. You have to create a Google Group and a blog and an IRC channel and a novelty Twitter account too.
The infrastructure of “social coding” has codified this trend into an expectation that every piece of open-source software participate in a world-wide collaboration / popularity contest. The only feature of GitHub that can’t be turned off is the pull request.
Don’t get me wrong, I love GitHub and use it every day. On work projects, I find pull requests to be an efficient tool for doing code reviews. GitHub’s collaboration tools are great when you’re only trying to collaborate with a handful of people, all of whom are working towards a common, mutually-understood goal.
But when it comes to open-source work, I use GitHub primarily as a hosting platform.[1] I put code on GitHub because I want people to be able to find it, and use it if it helps them. I want them to fork it, fix it, and improve it. But I don’t want to be bothered with it. If you added something new to my code, great! It’s open-source – have at it!
I’m puzzled by people who write to me saying, “If I were to write a patch for your library X to make it do Y, would you accept it?” First of all, you don’t need my or anybody else’s permission to modify my code. That’s the whole point of open-source! Secondly, how can I decide whether or not I’ll accept a patch I haven’t seen yet? Finally, if you do decide to send me a pull request, please don’t be offended if I don’t accept it, or if I ignore it for six months and then take the idea and rewrite it myself.
Why didn’t I accept your pull request? Not because I want to hog all the glory for myself. Not because I want to keep you out of my exclusive open-source masters’ club. Not even because I can find any technical fault with your implementation. I’ve just got other things to do, other itches to scratch.
If everyone thought that way, would open-source still work? Probably. Maybe not as well.
To be sure, there’s a big difference between one-off utilities written in a weekend and major projects sustained for years by well-funded organizations. Managing a world-wide collaborative open-source project is a full-time job. The benevolent-dictator-for-life needs an equally-benevolent corporate-sponsor-for-life.[2] You can’t expect the same kind of support from individuals working in their spare time, for free.
I sometimes dream of an open-source collaboration model that is truly pull-based instead of GitHub’s they-should-have-called-it-push request. I don’t want to be forced to look at anything on any particular schedule. Don’t give me “notifications” or send me email. Instead, and only when I ask for it, allow me to browse the network of forks spawned by my code. Let me see who copied it, how they used it, and how they modified it. Be explicit about who owns the modifications and under what terms I can copy them back into my own project. And not just direct forks — show me all the places where my code was copied-and-pasted too.
Imagine if you could free open-source developers from all the time spent on mailing lists, IRC, bug trackers, wikis, pull requests, comment threads, and patches and channel all that energy into solving problems. Who knows? We might even solve the hard problems, like dependency management.
Update Jan 17, 8:52am EST: I should mention that I have nothing but admiration and respect for people who are good at the organizational/community aspects of open-source software. I’m just not one of them.
Footnotes:
[1] I’m not the only one. Linus Torvalds famously pointed out flaws in the GitHub pull-request model, in particular its poor support for more rigorous submission/signoff processes.
[2] Even with a cushy corporate sponsor, accepting patches is a far more work than the authors of those patches typically realize. See The story with #guava and your patches.
11 Replies to “The Reluctant Dictator”
Comments are closed.
Perhaps you could xpair up with someone who likes to help…
It’s wonderful that you like working on open source projects and that you release a lot of work for free for others to use. That’s truly a beautiful thing. However, I believe that the real value and benefit of ones work is limited by the extent to which the work is understandable and usable by the community at large. Users give meaning to software.
“Imagine if you could free open-source developers from all the time spent on mailing lists, IRC, bug trackers, wikis, pull requests, comment threads, and patches and channel all that energy into solving problems. Who knows? We might even solve the hard problems, like dependency management”
I’m not sure if I could disagree more. The real hard problems in the world are all to do with people – especially working together, collaborating and sharing in harmony. The energy I channel into the Overtone community is in-turn fuelling and shaping the culture and enthusiasm of the users who in-turn help and fuel others, and so on.
Writing software is the easy part. Watching software fragment into a million tiny pieces is even easier. Finding common ground, and working with others though, that’s tough.
The benefits of working together are also immense. Just check out all the amazing work that Phil Hagelberg is doing with the Leiningen community. It really is a fantastic piece of community work that really is having a massive impact on the majority of Clojure developers. Something like this would never be possible with the write-once-throw-into-the-ether-for-the-hounds-to-fork approach you’re advocating.
Hi Sam,
I’m not advocating this approach for everyone, nor for every project. I’m really impressed with (and a daily user of) the amazing work Phil has done with Leiningen. But Leiningen and Overtone are both end-user applications (even if they are targeted at developers). Some software projects definitely need a community — tooling being a perfect example.
My open-source code tends to be in the form of libraries and small snippets. I think that kind of software is served just as well by free-form evolution. Good ideas tend to stick around and grow on their own. For example, I wrote and abandoned Lazytest, but the code-reloading techniques it employed got copied around in various other libraries until I returned to it in tools.namespace 0.2, which Brian Marick made use of in Midje. All of this required no coordination at all.
I want to spend my time where I feel have the most to offer, which is in writing code, documentation, articles, and books.
-S
“I want to spend my time where I feel have the most to offer, which is in writing code, documentation, articles, and books.”
Please don’t stop – I respect the work you do and hold you in high regard. Absolutely none of what I said above was aimed specifically at you, it was more broadly targeted towards the wider discourse of code and community and the tensions therein.
“Please don’t stop” — Don’t worry. I couldn’t stop myself if I tried. :)
I think it’s possible to agree with both of you (Sam and Stuart). The basic point is that integration is hard. There is potentially great value in it, too, and this is Sam’s point. But if some developer finds, after weighing up the various benefits, pains, satisfactions and frustrations of participating in integrative development activity, that it’s not for them, there’s nothing wrong with that. Arguably, the open-source model thrives on human diversity. If something is really worth integrating, there is a decent chance that someone else who has a different set of coefficients will come along and do it.
The latter supposing is arguably optimistic. I can think of lots of software in which plenty of potential progress is passed over because nobody can be bothered to make the integration effort. In fact, this debate points to a research question. Perhaps integration is more difficult than it needs to be, and can be made easier given different tools and systems (cf. the never-ending struggle for consensus, which manual patch-based approaches entail). I really believe this (it’s what my PhD was about, although I wouldn’t say I made very much progress). So Stuart’s last paragraph is raising a classic tension that recurs in just about any discipline: how much effort should we spend working within the existing system, perhaps inefficiently, versus working to improve on it, which might yield longer-term benefits at some shorter-term cost?
Interesting view. Maybe it’s worth including the attitude in README. Something like “don’t bother me”. That could help both you and people that bother (and don’t know about it)
However, I don’t thing the lack of dep management tool is a result of too much communication, but maybe too little.
Just my $0.02
I think tools.namespace is a bit of an unfortunate example, given that the readme of https://github.com/Raynes/bultitude specifically mentions problems with the community relations for tools.namespace.
I’m not saying the code isn’t good, nor that there aren’t many of us that are lousy at the community thing (I’m one of them). But I think your dividing line between languages/code and end-user systems is false. They all need community.
By the way, the reason people ask you if you’d accept a pull request is because it’s received etiquette and no-one much likes forking code.
Hi Julian,
As I see it, Bultitude is a perfect example of open-source working well. Anthony forked tools.namespace 1.x (as Bultitude) to get a specific feature he needed for Leiningen. I didn’t need or want that feature at the time, but about 4 months later I realized it was useful and merged it into tools.namespace. Nobody had to ask permission or wait for anyone else to apply a patch to get their work done. It was a trivial amount of code anyway, hardly worth getting worked up about.
-S
Stuart, you’re right.
The whole point of git is that people can work in their own copy of the repo without affecting others. Github even makes this kind of thing really easy. I think it’s one click to fork a project, see which projects come from which, etc. Actually, popular projects tend to have a fog of forks surrounding them.
What’s hard is managing these different versions. If I want a feature in a library, of course I can fork it and add it myself. Then I have to bump the version number in the project.clj, build a jar, and push it to clojars to be able to use it. I could imagine a system where we could have our branches and use them seamlessly, too.
Conclusion? Github is made for the kind of “lazy” management you mention in this article. Tell those jerks with the pull requests to lay off!
Thanks for the article!
Eric
TL;DR: