I've finally decided to write a bit about a topic that has bothered me for many years as a participant in the Free Software community (it applies equally well to Open Source if you prefer): User Entitlement.

Some of you out there know what I mean. You maintain an application in your spare time as a volunteer. You field trouble reports and RFEs and do your best to implement, at minimum, the suggestions that matter to you, all while holding down a job and meeting your personal and family obligations. But for a minority of users, that's not enough; they expect you to implement features that don't interest you and fix bugs you can't reproduce. In short, they expect you to provide support. While one tries never to be rude, at some point the urge to point out the obvious becomes overwhelming: you have the source, you obviously care a lot about this, and nobody else has the time or inclination to do anything about it! Instead of repeatedly asking when I'm going to implement your change, why not implement it yourself and send me a patch?

Of course, the inevitable response to this suggestion is that the user in question is not a programmer. This is a subtle but important fact that has changed the way the community functions over the years; in the beginning, we were all programmers. Now programmers are a minority of Free Software users, just as we are a minority of software users in general. The commons model breaks down under these conditions; many users have little to offer the community as a whole. Bug reports and testing are valuable services, true, but some users are just that - users. Not testers. Not contributors. Not developers. Just users; they use the software, expect (rightly) that it will work as advertised, and become unhappy and demanding if it does not. This looks a lot more like a customer than the fellow co-op shareholder the model would suggest.

I don't mean to suggest that this behaviour is representative, but it certainly has increased as the pool of users has expanded. How will Free Software projects in the future deal with the influx of Users? Much work has been done, mostly in economics, on the subject of managing cooperatives and commons; I believe this work is directly relevant to the Free Software community. I'll get more into some of that work in my next post.

Last week a contingent from Sun showed up at OSCON to talk about Solaris 10, meet with some community leaders to discuss building a community around open source Solaris, and of course learn from the other conference attendees.

Simon Phipps gave a talk on open source development and the meaning of freedom which was quite interesting. One of his points was that freedom for deployers is as important as freedom for developers, and that while licenses can help to build a community around a piece of software by giving the developers freedom, this is not sufficient as an end in itself. This is one of the things we're looking at as we get ready to release Solaris under an OSI-approved license of some as yet undetermined kind. Governance and community structure are at least as important as the license we eventually choose, and we have much more direct and immediate participation in these aspects. One point I've tried to emphasize is that successful communities form spontaneously and organically; they cannot be constructed from scratch, purchased, or willed into existence. Our challenge is to get people excited about Solaris and interested in being a part of that community, then to provide them with infrastructure and a reasonable way to make their voices heard as we proceed. Many people at the conference had some helpful suggestions for doing this.

Perhaps the most important thing to remember is that developers are fundamentally attracted by two things: exciting technology and a meaningful opportunity to work on it. The success of the BOF that Adam, Andy, Bart, and Eric put on showed many people just how exciting some of these technologies are. The feedback we received was overwhelmingly positive. Rarely does such a demo-friendly piece of technology as DTrace come along, and many of the attendees were clearly impressed. Still, it's only one of many major enhancements in S10; it's fairly obvious that there will be plenty of developers attracted to our technology provided we can generate enough awareness.

But as we've seen, compelling technology and an open license are not enough to make for a successful project. GCC and XFree86 had both, but neither project was successful in building and sustaining a community (GCC of course has been reborn since the quagmire of the 2.8 era). Many things make up a project's public perception as one which is easy and fun, or frustrating and counterproductive, in which to participate. Infrastructure, governance, and developer resources each play a role. My focus at the moment is on our efforts to help developers get started; this means providing good documentation and keeping the barriers to entry as low as possible. As one of the people who will be creating the developer documentation, tutorials, and examples, I'd be very interested in your feedback. When you're attracted to a project, what type of resource increases your desire to participate? What dissipates your interest and turns it into frustration?

Everyone is doing it and you don't want to be left out, do you? Besides, the first one's free! I'll mostly be writing about my experiences becoming a part of the Solaris kernel group at Sun. One area I'll be working in is opening Solaris to the world, which is one of the most exciting things to happen in a long time. It's especially interesting because I joined Sun only a few weeks ago after being a sysadmin and maintaining SPARC Linux in my little remaining spare time. Thanks to Sun I'm now in recovery and hopefully on my way to making some kind of contribution in the real world.