A tale of three communities

After having spent the past year and a half living and working in the commercial open source software world, I still marvel at how “the community” supports and makes possible the creation of high quality software. At first glance, a commercial enterprise that produces open source software may look like an absurdly small number of people supporting a large number of projects and a huge number of users. But an open source project team isn’t just comprised of the people within the walls of a building in a particular office park. It also includes all the contributors, anywhere in the world, in the project’s community.

In the past week, I had three distinct experiences with communities in various forms. Or, at least, they were three organizations that people referred to as “communities.” In thinking about them, the only one that really empowered its members and was based on the collaboration that is possible in an internetworked world was the one based around an open source software project.

The first community was based around a very popular home computer product. I’m a member of this community, since I recently bought an updated version of the product to make DVDs and digital movies. I think, however, that I bought the new version a little too soon as it seems to have a bug or two. One of the bugs caused the program to crash when it was started.

I only had one of the more minor bugs show up on my PC. I was curious, however, if other people were seeing this problem, so one evening, I logged into the user support pages. Wow. Several dozen people were logging questions about more serious bugs, such as the updated version of the program crashing when it was started. Several hundred people were reading and commenting on these bugs and some people had posted workarounds that they had devised to get around the problems. These workarounds were useful as the official website of the company that sold the software had only posted a very brief workaround that didn’t work for many people.

It dawned on me that what I was witnessing was an attempt by the users of the product to build a community where they, the commumity members, could help and support each other. This community, however, had some fundamental weaknesses.

The community consisted of people who all had to look at the program from the outside-in. We all had user experiences with the program, but none of us had access to the source code or any of the program’s internal design.

Also, the program’s developers and designers were not members of the community. We were all comparing our own black box experiences and tried to discern problem root causes from those experiences. (A sort of shared Sherlock Holmes experience where we relied on our powers of observation.)

Finally, while we could all contribute suggestions and frustrations and empathy to the forums, we could not make contributions to the program itself.

The second community did not directly involve me, but, speaking of empathy, did directly affect several of my former co-workers. My former employer, a large (make that VERY LARGE) company, announced this week that it would be closing offices in multiple cities of my state and that it would consolidate the employees from these offices into a new campus that will consist of multiple new buildings in two adjacent towns. Part of the plan is that campus will faciliate better collaboration between employees. The cynic in me says that the company’s real goal was to reduce its real estate cost, but there is probably some genuine interest in building collaboration as well as a new campus.

The goal was to build a collaborative community, but it was fundamentally based on a flawed (or at least outdated) view of the boundaries of a community. The most efficient physical organization of a project team is probably for all the team members to be in the same room. But this is not a realistic plan for a project today. Skilled, talented and dedicated people are everywhere in the world and with the internet, they can work together. What’s more, in most open source projects, they are working together today.

The future will only bring easier global comunications, so it’s very unlikely that projects will ever be staffed by people in the same geographic location. The communities that support projects are built on the talents and contributions of the contributors, not their time zones.

Besides, as a perpetually disgruntled former co-worker of mine commented on this plan to build a collaborative campus, what’s the difference between being in two adjacent towns or thousands of kilometers away? With email, online chats, video conferencing, and cell phones, there’s not really much of a difference. Or, as my co-worker observed, “That’s great. I still work with people in California and India on my project. And, they aren’t being co-located. (Not to mention the other 100,000 people in the company.) And, my commute just got longer, too.”

In contrast to these two communities, I’ve recently become a (small scale) contributor to an open source project.

The project team is widely dispersed geographically. I’m currently working with people in the UK, Czech Republic, Australia, some other US cites several hours away by air travel, and one person who works out of his basement about 20 miles away. The team works together and is in fairly constant communication. The only hardship involved in the communication has been having to learn to convert local timezones to UTC. Speaking of timezones, the dispersed nature of the team has rendered the concept of a “workday” obsolete. What’s a workday? Well, while any one person may work only eight hours a day (more or less), the project team itself never really shuts down. As I’m writing this, it’s near midnight on the east coast of the US. In a couple of hours, the project team members in Europe will just be starting their work day.

I think it’s useful to look at this type of collaboration with a historical perspective. The city as a human construct developed as a mechanism to enable human interaction by gathering people together in the same place. The internet removes time and location limitations in building a community and enabling collaboration.

But beyond the mechanics of collaboration made possible by global communications, it’s the nature of that collaboration in the context of an open source project that makes the real difference. It’s common these days for closed source projects to employ people all around the world. What’s different in an open source project is the democratization of the content. I’m able to view the source code of the project and talk directly about its operation and design with the same people who designed, reviewed, and contributed the code. And while people as individual contributors may have an emotional attachment to the specific code that they wrote and contributed, all the code (and documents too) are subject to the same rigorous review by the community. There’s no hiding a bad design or buggy code behind locked doors.

I remember a very different experience from a couple of years ago. I had been assigned to a troubled (closed source) project after having spent months trying to avoid it. (A few years before that, as a customer of the company for which I came to work, I had actually refused to buy the product!) The project was, well, a mess. The design had been modified so many times over several years that no one really understood how it worked. Customers were always logging bugs based on the external (and buggy) behavior of the product. The event that really summed up the product for me was when I heard that a co-worker, when asked about the state of the code while he was interviewing a prospective new employee said, “Well, the people here are great to work with!” (The code was, of course, less great to deal with.)

My own area of expertise is software quality engineering (QE). From a QE perspective, working with and on an open source project has one great advantage over a closed source project. It’s like Eric S. Raymond said in The Cathedral and the Bazaar, “Given enough eyeballs, all bugs are shallow.” To a great degree, all the project’s community members are involved in the testing and quality of the project. Part of this is due to test-driven development and the use of continuous integration (CI), but it’s also due to the openness of the design and the quality of the code.

The project’s community controls its own destiny. It’s not a case of “outsiders,” submitting entreaties to the project’s “owners.” The community IS the owner, and the code is not hidden. I can ask questions and see the answers in the source code or design or user documents. I can even make contributions and see other community members make improvements to them.

To sum it all up, the first two communities (whether or not their creators intended them to truly be communities and not just user forums and office parks) suffered from limitations imposed on their members. The limitations may have included access to information or a limiting point of view about physical locations. The third community is vibrant and thriving. It’s not based on a utopian ideal, and its members still have to deal with the same interpersonal problems that exist in any human organization. The code and documents, however, are open to everyone, and the collaboration is constant and even downright infectious. I’m even learning some Czech in the process. So, dobrou noc (good night) everyone!

This entry was posted by Len DiMaggio on Tuesday, September 11th, 2007 at 8:46 am and is filed under culture. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.