I have started objecting to the description of a contributor as a “volunteer”.

Volunteers are people who give their time/effort to an institution or group at some cost to them for little benefit in return. They usually do this as a labor of love, and therefor the argument can be made they receive some kind of emotional satisfaction from the exchange but it’s fundamentally categorized as a one way exchange where the volunteer is **giving** and the institution or group is **taking**.

Open source contributions are not market transactions. In a market there is a producer and a consumer, the transactions between them are to the benefit of either the producer or the consumer or both. Producer makes something, consumer evaluates the product and decides to give capital to the producer. Volunteer is a term used to describe an actor that is working for the benefit of the producer without reciprocal benefit to themselves to the extent that they benefit the producer.

Capital is the driving force in a market, it’s what enables the transactions. Workers are paid for contributions to product so that institutions can enable transactions where consumers are given a product in return for more capital. Capital is certainly a factor in open source, but it’s auxiliary. Capital may drive one side of the transaction, an actor paid to contribute to a product or consumption of a product used by the consumer to generate capital, but it does not drive each side of the transaction.

Contributors are not driven by a need to benefit a particular producer and are rarely driven by capital. In fact I can’t think of a way to describe open source contributions in terms of a market. In open source there is the **product**. The product exists almost as it’s own entity outside of the producers that created it or the consumers that use it. Because if it’s transparency and it’s ease of access and manipulation it cannot be viewed as a unit in a transaction within a market. Instead, all interactions need to be described in **relation to the product**. Contributors, institutions and individuals, that take part in production and those that take part in consumption take part in transactions with the **product**. This is an open source community, a group of actors taking part in transactions with a product.

The communities that thrive are the ones that remove barriers to these transactions and create tools that enable new transactions for more diverse contributions to the product. The transactions are not one-way, each transaction is two-way, benefiting both the product and the actor.

Rather than capital, mutual benefit seems to drive open source transactions. The product and the actor benefit from every transaction, with only a small portion of those transactions seeing capital as the benefit. The notion of a volunteer simply doesn’t exist in this model because there are rarely, if ever, transactions that only benefit a product at a cost to the actor. Actors **must** to be motivated and products are not “owned” in the traditional sense of ownership since their production is taken on by a community motivated by mutual benefit which tears down the relationship traditional market producers have with products.

Tools that are built to enable one sided transactions to a product usually fail because actors aren’t motivated by transactions that aren’t mutually beneficial.

A quick look at Firefox shows a very broad and diverse number of tools that enable mutually beneficial transactions. Although we often think about the new kinds of contributions that additions to Firefox itself will enable like [Personas](http://www.getpersonas.com/) or [Jetpack](https://jetpack.mozillalabs.com/) we also have a variety of tools that enable non-code contributions. Everything from that little button that reports a crash (benefits the product’s stability and improves your browser experience) to [SUMO](http://support.mozilla.com/en-US/kb/) (users seek resolution to support issues while providing the product with immeasurable usage feedback and bugs) are examples of tools that enable new transactions with the product that are mutually beneficial to the product and the actor.

One of my favorite things about working at Mozilla is being able to think about new kinds of contributions and how to enable them. There are few products with such a large and diverse ecosystem of users so the opportunities for new contribution is uniquely large so long as we create tools that are mutually beneficial.

I’m not lucky enough to get to choose one source control manager and use it exclusively. On a daily basis I use git, svn, and hg. Every week or so I also use bzr. Luckily, I no longer have to touch darcs.

I haven’t dug in to the internals of these tools enough to say which one has the superior technical merits although I will say that I’ve never seen a git conflict resolution interface even across unbelievably hairy merges.

I write a lot of small libraries and a couple big ones. I care far more about the social effects and contribution workflows a tool provides than any other features. There are different public web applications that try and provide infrastructure for the social effects of DCVS and after months of working with different approaches I have to say that GitHub is the winner by a mile.

At the end of the day there are two factors that make GitHub such a clear winner. The first is zero friction publishing. The second is the democratizing effect of scraping any notion of a “central” repository.

Nearly a year ago i hit the Google Code project limit and had to call in some favors to get the limit pushed up for my account. I have to push lots of small libraries so having a simple and seamless publishing of repositories has made my life much easier. The fact that I can just push my repository and worry about turning that repo on GitHub into a “project” later, instead of the other way around, means that I have no reason **not** to publish every little thing I do.

The second and more controversial feature of GitHub, and possibly of git itself, is that there is never a clear central repository. There is my repository, and your repository, and every other **person’s** repository. This throws off FLOSS projects that have always relied on a “committer” hierarchy to manage the influx of work in to a project. Nearly every book on community driven open source focuses on the creation of a class of contributors with special write permissions to the repository. There has been a huge discussion on how to translate that process to DCVS and some tools, in particular hg, make it fairly easy to simulate older workflows with a central repository.

After living with GitHub for a while and seeing the potential for new collaboration I think the answer to translating the “committer” model to DCVS is to **not translate it at all**. GitHub makes **everyone** a committer and that enables a new class of contribution that the old model totally excluded.

Since code can travel seamlessly through different developer’s repositories each change takes on a life of it’s own. People who made what they thought were small changes for their own personal use easily share them with other developers and those changes can move around repositories hopefully making it in to an official release. New contributors don’t have to worry about this giant wall of process behind getting a patch in, they simply write the patch and push it, send pull requests to other relevant contributors and module owners eventually getting those changes pushed up in to the repository that gets packaged and distributed.

Someone is always going to be responsible for releasing a product, someone owns the keys to the distribution mechanisms, so I find the notion that some amount of authority over the project’s direction is lost by not centralizing the repository to be exaggerated. Although there is some authority that is lost to the previously defined class of committers the democratization of write permissions encourages a bigger class of lost contribution that is excluded by the laborious process of patches in bugs and the required upstream process to get the work committed. This also means that a number of contributors can live with changesets for an extended period of time before they get packaged in a release which increases confidence in large changesets that many projects reject outright for fear of instability.

GitHub solves the social problems of open source collaboration by taking a much more anarchist approach to the contribution process and while this is certainly shaking the foundation of traditional contribution models I’m loving it

I’m in London for the next few days and would love to grab a drink with any community members be you Mozilla, CouchDB, Python, Windmill, JavaScript or just plain old coffee, whisky or beer geeks

I’ll be leaving tomorrow morning for [Open Source Bridge](http://opensourcebridge.org/) in Portland, Oregon.

I’m putting together a new [Windmill talk](http://opensourcebridge.org/sessions/36) that tries to incorporate all the feedback we’ve received over the last year of speaking which I’ll be presenting on Thursday.

Mozilla is also a [sponsoring](http://opensourcebridge.org/sponsors/) the conference and there is going to be some great [Firefox related sprints in the hacker lounge](http://opensourcebridge.org/wiki/Hacker_Lounge). Dietrich is also giving what sounds like an awesome talk on extending Firefox called [Firefox Switchblade](http://opensourcebridge.org/sessions/251).

Hope to see you all there!

PS. I’ll also be at EuroPython and the Community Leadership Summit, more on those later

The Rails community seems to be on the verge of imploding, not necessarily because of a [particular event](http://www.ultrasaurus.com/sarahblog/2009/04/gender-and-sex-at-gogaruco/) but because of the [response by Rails leadership](http://afreshcup.com/2009/04/28/a-painful-decision/) to the event and their lack of meaningful reflection on why this happened.

This event has been well commented on, so I won’t go in to all the details, but unsurprisingly the best comments I’ve read so far have come from women, in particular [Audrey Eschright](http://dyepot-teapot.com/2009/04/25/dear-fellow-rubyists/). It’s good to see meaningful discussion in that community but I think the proposed solution of increased “professionalism” is counterproductive and generating an even more hostile response from [Rails leadership](http://loudthinking.com/posts/39-im-an-r-rated-individual).

Professionalism doesn’t have a good history of promoting equality. After segregation “professional” was one of many code words for “white male” and even after many years when non-white males began entering the work force the idea of professionalism served to strip people of their culture and identity to better fit in to a white male dominated environment. For those of us in open source, and especially those who have left traditional corporations, we identify “professionalism” as the way corporations turn people in to plastic dolls in suites that can talk to other plastic dolls from other corporations at trade shows without getting “off message”. Luckily, we aren’t talking about a corporation here, we’re talking about a community and community isn’t about professionals it’s about people.

I think people see professionalism as a solution to this problem because it provides a way for us to change people’s conduct that we disagree with without actually changing people or how they think they should conduct themselves in a community. The real problem here is that some **people** think it’s just fine to engage in public conduct that knowingly excludes people and doesn’t help include or encourage any new participation.

When news of this little outburst broke I have to say I wasn’t surprised that it happened in the Rails community. All tech communities have a low number of female participants, this is something nobody is great at yet, but for some time now Rails has been the worst offender. In the early days Rails was promoted by DHH in what, at the time, sounded like a great strategy: Attack dominant technologies (Java) and piss people off that use them long enough to check out your stuff. This strategy generated huge buzz and lead to one of the fastest adoptions of a new technology I’ve ever seen and it’s worth noting that the technology was actually so good that people could go from being a pissed off Java developer to a Rails developer in a relatively short amount of time.

But the biggest problem with DHH’s strategy was that it was hostile and it intentionally excluded a large number of people who were invested in the old technology and couldn’t get over being pissed off at DHH. The first thing DHH will say is “well, we don’t want or care about those people”, and he’s right, Rails doesn’t need those people. But when you, as the leader of a project, are hostile and partake in action that **intentionally excludes people**, regardless of who those people are, it creates an environment where others see no need to alter their behavior not to exclude people.

I’m really disheartened by [DHH's "I'm an R rated individual" post](http://www.loudthinking.com/posts/39-im-an-r-rated-individual), because it’s not that he’s wrong, he’s actually right, he should be able to be an individual in the community he’s built, but if he doesn’t intentionally curb some of his behavior he’s going to encourage exaggerations of the worst parts of his personality by the example he sets. It’s great that DHH loves Louis C.K and his dick jokes, but that doesn’t mean he would intentionally start a keynote with them, he knows better, and that’s what makes the difference and that’s what is so wrong with Matt’s talk, he knew before he went up there that this would make a lot of people uncomfortable and discourage participation from women and he did it anyway.

In order to lead an inclusive community you have to encourage participation and allow everyone to be individuals. If you treat everyone with respect, no matter who they are and no matter what they do, others will conduct themselves the same way. It’s always easier to respond to hostility with hostility but all you’re doing is creating an environment where hostility is the norm and it’s alright to exclude people.

The kind of communities we want are not impossible, in fact we get closer and closer every day. I’m lucky enough to be at [#moz09](http://search.twitter.com/search?q=%23moz09) this week, and I’m looking around at over 200 people from different cultures from around the world none of which seem to be trying to hide who they are or where they came from for some notion of “professionalism” and everyone treats each other with respect and every day we gather more participation from a broader set of individuals. We aren’t perfect, we’re never where we want to be, but we should be confident we’re going in the right direction.