This is republished from http://dyepot-teapot.com/2009/02/17/open-source-citizenship/ and was first posted on 2/18/09
When we started working on Open Source Bridge, Selena and I came up with the term “open source citizenship” to describe what we hoped to explore. We’re planning a conference that will connect developers across projects, across languages, across backgrounds to learn from each other. We want people to experience something beyond “how to use tool X” or “why databases keel over when you do Y” (even though those topics are important, making up our tools and trade, and will be a central part of the conference content). We’d like to share what open source means to us, what it offers, where we struggle, and why we do this day in and day out, even when we’re not paid for it.
In order to do that, it seemed important to bridge the kinds of roles we have in open source, user/contributor/owner/institution, getting down to something more fundamental. What else are people who interact in this multi-directional way? Perhaps we’re citizens. Not residents—we do more than live here. We are, like citizens of a country, engaged in the practice of an interlocking set of rights and responsibilities.
Citizenship isn’t a concept I’ve thought about much since grade school, so I might only be scratching the surface of what it implies, but here’s a few thoughts.
There are rules for gaining citizenship. You have to be born in a place, or have parents who are citizens, or be sponsored, or apply and jump through hoops and make sense of bureaucracy. There’s no requirement you and the government like each other, but you must agree the follow the laws you and it are bound by.
Citizens are constrained, but they also have rights. They are protected from outside entities. They may be called to act in service, to contribute to the country’s well-being and defense.
Citizenship can be revoked, or renounced, if the person commits treason, or is found serving an opposing side.
—–
I’ve been working with Ruby and Rails for almost exactly three years now. I have yet to submit a patch to either project, but I help with pdx.rb events and share what I know with other developers. I also promote Ruby, Rails, and related projects by telling people what I like about the tools I use. In return, I expect the projects to not do anything stupid that would prevent me from writing software (especially since it’s how I earn a living) and continue to make useful improvements, asking for feedback as they go. Their continued stable existence protects me from having to work with something less useful or appealing. Maybe it wouldn’t be the worst transition, but I like it here.
Last year I started Calagator, an open source calendar aggregator, with a group of local tech enthusiasts. Our citizenry is broader than that of a programming language, encompassing all types of technology users and creators, as well as the whole Portland metro area (and perhaps beyond). We try to provide a useful calendar service, and ask the users to help us by providing and updating event data, letting us know what is or isn’t working, and assist us in developing new features that meet their needs.
There are many other open source products I use, but those are the ones I feel most closely aligned with. Even with casual or temporary affiliations, there’s a minimum contract: it will do what I need, or I won’t stay. Long-term residency may have stronger demands (and more benefits: now I know how it works and how to alter things).
As I said before, this is just a starting point, but I’d like to explore further what rights and responsibilities open source citizenship brings. Especially for developers, we’re not just users, but a kind of co-producer, and that relationship is often assumed and left undocumented unless we’re in charge of a project or join the government core team. I’d like to draw it out, see what the implied contract looks like, and talk about how well it’s upheld on all sides.
If you have ideas on that, or anything else open source, our call for proposals is open now through March 31. We want to hear what’s interesting and important to you.