|
Open Source Commentary from
Navica's CEO, Bernard Golden
In This Issue
-
Checking Out the Community: A Guide to
Assessing Your Open Source Community
-
Navica News
Checking Out the Community: A Guide to Assessing Your Open
Source Community
Whenever you consider moving into a new neighborhood, you
always “check out the community.” Ordinarily your
real estate agent helps with this. He or she will show you
data on school location and performance; describe the character
of different neighborhoods; and even discuss recreation and
entertainment options. Astute people seek out objective data
to confirm this information, drawing on state school test
scores, census data, Google satellite photos, and so on.
This research efforts reflects the fact that much of the
satisfaction in our lives is based upon where we live –
so it's vitally important we choose the right community. It's
not exaggerating to say that our community powerfully shapes
the outcome of our – and our family's – lives.
There's a problem with this research, however. The data reflects
official statistics, but does not tell very much about the
actual members of the community – and the actual people
are what will make the largest mark upon whether our experience
of the community is positive or negative.
To take one example: schools. Official statistics can tell
you how the school performs, but won't inform you about how
your children will experience learning there. Will they be
imbued with a sense of curiosity about a world that may be
explored with others in a cooperative and
competitive fashion, or will they conclude education is purely
a cut-throat endeavor where every other participant is an
enemy in a zero-sum game? In tours through the schools in
my area, I've seen both types.
The lesson is obvious: you need both types of data –
formal and informal – to get a clear picture of the
nature of a community.
Which brings us to open source.
Community is a term much used – and misused –
in the open source world. All too often you can hear facile
generalities like “the community feels ...” or
“the community won't support ...” without any
objective basis for the statements.
Notwithstanding the too-general nature of these types of
comments, the reflect the fact that community is the fundamental
reality of open source software. Without community, open source
is freeware; with community, open source is a mighty tool
for organizations.
I addressed the general topic of open source community and
its critical importance in a previous newsletter, which you
can read here.
In this newsletter, I'd like to address the question of assessing
individual open source communities.
And, make no mistake about it, you will be assessing one
community among a plenitude. Statements like “the community
feels...,” ignore a critical reality: in choosing a
particular product, you are committing to a particular community;
given how important a role community plays in the success
of an open source product, understanding the nature of a specific
community is absolutely vital.
This reason community is so important is based on these aspects
of open source:
Community – made up of both developers and users –
provides the unique development style of open source. With
a direct bond between developers and users, user feedback
about product features and quality flows without the mediation
typical in proprietary companies. No tech support, product
management, or sales organizations stand between users and
developers to interpret user needs.
Community – unique to open source – provides
a mutually supportive environment for users to learn from
one another and help one another make better use of the open
source product. While there is no theoretical barrier to this
kind of community self-assistance for proprietary products,
it never seems to jell. And, of course, proprietary vendors
may have a financial stake in keeping users divided from one
another; put another way, vendors may have an interest in
keeping a user base from developing into a community.
Community – and its proxies like total downloads –
inform other parties that the open source product is worth
investing their efforts in. So, for example, a commercial
publisher may look to the size of a product community in determining
whether or not to publish a product tutorial – the existence
of which, of course, will make it even easier for the community
to grow and thereby become more valuable.
Community – the connected user base of a product --
provides the ultimate protection for a product's users. The
proprietary world is littered with products abandoned by their
vendors due to acquisition, management neglect, “strategic
redirection,” or even bankruptcy. Users dependent upon
proprietary products no longer supported are left to their
own devices – forced to plan a migration caused by someone
else's agenda, on someone else's timeline, but, unfortunately,
on their own nickel. With source code availability, and a
large enough community, end users can pick up the code base
and support and enhance a product. The need for this action
is rare, but open source users always have a fallback option.
Community – last but certainly not
least – provides the single most important factor for
successful use of a product – technical support. In
my book, I describe the two types of technical support: usage
and failure. Usage helps you solve problems with the product;
failure helps you when the product goes down and you need
someone to get it up and running asap. The vast preponderance
of technical support issues fall into the usage category:
how do I do this with the product? Failure scenarios are (thankfully)
rare, but exceedingly important when they do occur. The community
is -- by far -- the single most important source of both types
of technical support for open source products.
I know it's the fashion for open source commercial vendors
to downplay the importance of community and point to themselves
as the right place for users to look for the functions provided
by the community, but you are misguided if you accept this
assertion and ignore the product's community.
Ignoring the community is wrong, first and foremost, because
it provides individual user protection as noted above. An
open source vendor without a strong community offers nothing
more, really, than source code escrow, and we all know how
successful that's been in the past.
More practically, however, the community is the best available
alternative for open source technical support. While many
open source vendors now offer excellent technical support,
I believe its quality will inevitably deteriorate due to company
growth, the migration of firstline support to third parties
(e.g., HP, etc.) where it will be routinized to script-based
call centers, and, finally, the drive to lower support costs
for the vendors.
Even if you feel the quality levels of commercial open source
support will maintain their current high levels, focusing
on commercial technical support ignores one central reality:
hardly anyone uses it. Open source vendors estimate that one
percent or less (MySQL estimates 1/10 of one percent) of active
installations purchase technical support. This means you have
a 99% chance of relying solely on
community support if you are an open source user!
With that, it's clear that part of selecting an open source
product must be assessing its community. But how can that
be done? Here are five easy steps to assessing the vibrancy
and quality of an open source community:
First, how large is it? Size matters. All things considered,
a larger user base provides greater resources for you to draw
upon (and, of course, contribute back to in your own special
way). A quick proxy for this is total number of downloads
of the product. A bit more sophisticated is to look at the
number of forums or mailing lists – new lists are created
when the total number of postings grows unwieldy in a single
list. You can even look at the total number of individuals
registered for the forums/mailing lists to get a sense of
how many people participate in them.
Second, how active is it? To my mind, this is a critical
factor that must be examined when evaluating an open source
product. You're interested in how many postings get made,
naturally. More important is the quality of give and take;
more bluntly, what percentage of postings receive responses?
A forum that has a balance of 20% of postings receiving five
or more responses, 30% receiving one response, and a full
50% getting no responses at all is not a good sign. This means
that the community focuses on a small set of issues while
ignoring the rest. Unless you're fortunate enough that all
of your issues fall into the high-interest area, you'll be
spending a lot of lonely afternoons leafing through whatever
product documentation exists. Especially telling are forums
in which newbie questions get ignored. This makes for a product
with a tough learning curve.
Third, how diverse is it? Is there a broad range of users
and organizations represented in the developer and user community?
The cliché of the open source movement is that many
eyes make all bugs shallow. A more accurate reframing of that
cliché would be diverse eyes examine all aspects of
a product and improve it in all dimensions. With a wide range
of users and developers, the product will have a higher probability
of being robust in all of those dimensions, which is the key
to successful use of a product.
Fourth, how helpful is it? A community with forums filled
with sarcastic responses to postings is not a good long-term
bet. It's easy to get tired of newbie postings in which the
poster clearly doesn't want to be bothered to do any work
(e.g., “Can someone write up instructions about how
I can get this product to integrate with my general ledger?”),
but responding with hostility does not make for a productive
community. You do not want to be dependent upon a conflict-ridden
community. Examine a wide range of postings and responses.
Look for responses from developers and also individuals who
make a significant number of posts. If either of these categories
of respondents are unhelpful or unpleasant, move on. Your
key support mechanism is broken.
Finally, how interactive is it in terms of developer/user
interaction? A community in which developers deliver product
from on high while never deigning to interact with real users
is broken. If you are a member of that community you will
end up with a situation no better than the proprietary world,
where individual members have no real voice and the user base
is a fragmented, powerless collection of dependents. I must
stress that almost all open source developers are very open
to interaction and feedback, but this issue is so important
that it must be assessed before committing to a product.
The bottom line is that happy communities make for happy
individuals. In the context of open source, this means that
a healthy, vibrant product community is vital for an organization's
successful use of the product. Using the steps outlined above
will enable you to take an objective look at this critical
success factor prior to selecting a product. Don't wait until
after you've committed to the product; otherwise, you might
end up with buyer's remorse.
Navica News
I'm pleased to share the news that my book, Succeeding
with Open Source, has been translated and published in
Japanese. You can see the cover here.
You can hear me speak at these upcoming events:
April 27, 7:00 p.m.: Peninsula Linux Users' Group. Presentation
topic: "GPL3 -- Where Free Software is Going." See
www.penlug.org for more
information.
May 30, 3:00 p.m.: IKT Norge -- ICT Norwegian delegation
touring Silicon Valley. Presentation topic: "Open Source
Trends: Local and Global"
June 16, 9:00 a.m.: Burton Group Catalyst Conference. Presentation
topic: "Open Source ROI: The Real Story"
|
