The Difference Between Friend and Faux Open Source

Community: The Difference between Friend and Faux Open Source

There are lots of different perspectives on the topic of open source community. Some point to the unique development model, drawing together disparate contributors from around the world, most of whom never meet face-to-face. Others are intrigued by the governance model of open source development, which seems to function without any explicit hierarchy. Most commentators on open source fail to address what I consider the single most important aspect of community, the user community.

It’s easy to understand how product users get overlooked in all the histrionics about open source community. In part, it’s because it’s hard to know just who they are – this is due to the challenge of open source anonymity, which I addressed in the June 2005 newsletter.

Another reason that the user base gets overlooked is due to the current state of open source discussion. Many of the established pundits of open source are most interested in the developer community; indeed, they are, in some sense, the alpha males of the user community. The press has contributed to this as well; after all, it’s much easier to talk to the usual suspects than to unearth real users.

In my view, however, this ignores a central reality: for actual users of open source (the vast majority of the people who actually interact with open source products), the user community is the single most important factor dictating potential success for an open source product, as well as a critical predictor about the future of a given product.

Why is this?

Most users of software, whether commercial or open source, focus on software implementation, not creation. For them, information about configuration, integration, and tuning is all-important. Not only are they unlikely to contribute code to a project, they are unlikely to want to even compile the project source, far preferring to download executable binaries.

Consequently, the information they’re most interested in is practical help in getting the software running. For this, fellow users are a vital resource. Other users have probably already confronted (and solved!) the problem a new user is facing. One of the most fascinating things about open source is the phenomenon of users helping users. While it’s fairly easy to understand the motives for open source developers (scratching an itch, status, skill-building, etc.), it’s not as easy to understand the altruism of what is, in effect, free technical support. In my book I described one Perl mailing list contributor, Charles K. Clarkson, a real estate developer. His motive is that the pure logic of Perl programming problems offers relief from the irrational human interactions that make up most of his day – for him, tech support is stress reduction! In any case, no matter what the motives of the contributors are, the user community is where most users of an open source product will realize the majority of the value they get from the community.

However, some organizations choose to purchase technical support from a commercial organization. Primarily, this support comes from companies directly associated with a given open source product. For example, JBoss (the company) offers paid support and services for JBoss (the application server product). Many purchasers of paid open source support dismiss the product community’s importance, believing they have a higher-quality mechanism in place. This is a huge mistake on their part.

Here’s why:

First, the viability of commercial open source vendors depends upon the existence of a vibrant community. Commercial vendors survive selling to no more than one or two percent of the total user population of a product. Without a large community of users, there aren’t enough potential customers to support the vendor.

Second, a strong community is critical for long-term vendor existence. A number of open source companies have been funded recently, many of which are just developing their products. By definition, early-stage open source products have nascent communities. While these companies are currently operating on their venture funding, unless they develop large communities, their future is dim. If you’ve bet your infrastructure on a commercial open source provider like this, your risk exposure is quite high. In effect, you’re buying an option on the adoption of the product by a large community. This situation is likely to become more common, as more vendors decide to take advantage of the “magic” of open source distribution.

Many of these will be what I call “faux” open source companies that adopt open source distribution, but pursue policies more common to proprietary software companies. These policies, which include: (1) shielding developers from the community; (2) focusing most of the company’s energy on selling commercial versions of the open source product; and (3) holding features back from the open source product to make the commercial version more attractive, will all have the effect of hindering community growth. In other words, faux open source companies will never develop a strong community, and their products are poor choices for use, since the company probably will not survive long-term.

Third, and perhaps most important, a large community insulates you from vendor decisions. We’ve all seen software vendors change strategic direction and strand their users. Commercial entities operate according to their own motives, and just because a vendor is open source-oriented does not preclude this sort of shift from occurring. In fact, it’s likely we’ll see this happen more than once in the future. With a significant community, however, underpinned by a product with an open source license, the bond between product and vendor is broken. The community can take up an “orphan” product and ensure its viability.

For all these reasons, community is, perhaps, the key factor for organizations using open source. Most of them aren’t going to take advantage of source code availability, but all of them will rely on the community – even if they deal with a commercial entity. Community is the open source insurance policy.

So, if you’re considering an open source product, be sure to assess its community – present and future. Community is what separates friend from faux.
LinuxWorld Wrapup

LinuxWorld San Francisco has come and gone. I had the opportunity to participate in the product awards committee. This is a real treat, since it offers a peek at new technologies that are coming to the fore.

It was surprising to me that there was so much hardware at the show. File servers, SANs, clusters – all there. I guess it illustrates the fact that, with the operating system a commodity factor, innovation can move to other places – like interesting hardware experiments. It’s clear to me that we’re going to see more and more hardware goodies in the future; it’s a great time to be a user.

Also interesting to me was the crowd. LinuxWorld San Francisco has had the reputation of being more vendor-oriented than the Boston version, due to its proximity to Silicon Valley. While there were lots of vendors and venture capitalists floating around the show floor, what struck me was the number of what appeared to be typical IT types in attendance. It shows that mainstream IT has discovered that open source is something they should be paying attention to – and where better to find out about it than LinuxWorld?

Shameful, however, was the banishing of the .org pavilion to a second floor area away from the main exhibition hall, much like you put a socially inept relative near the kitchen at your wedding reception. It’s really exciting that there is so much vendor interest in open source, but … the thing that underpins open source is the community. Source code availability enforces open source, but community enables it. I hope the LinuxWorld management makes a wiser decision next time.
Takeaways

Community is a term much bandied about in open source, usually with little clarity but typically with much certainty (as in "the community believes" or "the community wants ..."). It often is defined quite restrictively as being made up only of open source developers. As both of the items in this month's newsletter illustrate, community is a broad and critical component of open source; from the user perspective, the community (in both the restrictive developer-only and broader user-inclusive definitions) is key to implementing the power shift from vendor to user that open source represents.

However, community is also key for vendors -- in some sense, the user community is where open source vendors hunt for revenues. In an upcoming newsletter, we'll address how vendors can help or hinder community creation for their products.