By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Whoa! I didn't know that I wasn't a member of the open source community! So I wrote back, saying that I certainly consider myself part of the community. He responded by saying that in his opinion the open source community was confined to those individuals who are open source developers.
That definition sure does limit the size, scope and inclusiveness of the open source community, and I'm wondering if it's a definition shared by many IT professionals.
This exchange got me to thinking about the term "community." It's thrown around a lot. You often hear statements beginning with, "The community believes in …" or "The community won't respect …," without any real identification of who makes up the community.
Over the past few weeks, I have been polling people on what they mean by the term "community."
What's been fascinating is the ambiguity of the responses. Some people identify the community as my correspondent did, including only open source coders. Others include people who contribute other project artifacts, like bug reports, documentation and so on.
Many people have a very inclusive definition that encompasses developers, artifact contributors and the entire user base. It is this latter definition that I find most congenial. In fact, I think a broad definition of community is crucial to the ultimate success of open source.
One of the real strengths of open source is that -- unlike commercial software -- its users have myriad resources to turn to. Open source is no monolithic, take it or leave it, world. It's hard to overstate the power of this aspect of open source. Something about open source brings out mutual effort, which makes using it much, much easier.
So what's wrong in defining the open source community as only a group of developers?
It's elitist. One of the great things about open source is that it levels the playing field of software. Users have much more control with open source products, unlike commercial software where vendors dictate and users defer. Why should users swap one master for another? Telling open source users that they are not part of the in-crowd is hurtful and, even worse, might dissuade them from using open source. Let's not have open source shape commercial practices, or fall into a situation like Orwell described in his classic book Animal Farm, "four legs good, two legs better."
It's wrong-headed. According to the developer-only community definition, the community would include some Microsoft engineers but exclude Tim O'Reilly. That seems laughable. We need a community definition that can include everyone with something to contribute, even if it's not contributed via an Integrated Drive Electronics.
It ignores open source realities. Most open source users are -- users. They don't want to develop, they want to use. For them, other users are much more important than the developers. Other users help them learn how to use the product. Other users provide example configurations. Defining users as not part of the community seems impractical.
It harms open source developers. Open source thrives on user involvement. One of the biggest criticisms of commercial software is that products tend to be feature-bloated and most responsive to other vendors, analysts and hype, while ignoring real users' needs. Defining community in a way that limits user involvement harms open source products.
It limits the future. Open source is dramatically transforming the IT industry. Its use is growing enormously and it's not too far-fetched to envision a future where open source dominates IT infrastructure. The flip side of that reality is the changes it will bring to the user base. Future users will be less idealistic, less ideological, less willing to kowtow to open source purity. Excluding them from the open source community will harm all of us, because their enthusiastic embracing of open source is vital for its ultimate success.
About the author: Bernard Golden is CEO of Navica Inc., a systems integrator based in San Carlos, Calif. He is the author of Succeeding with Open Source (Addison-Wesley) and the creator of the Open Source Maturity Model, a formalized method of locating, assessing and implementing open source software.