Community Event Horizons
February 16th, 2007First, there was the project.
The project was created by some guy, in some spare bedroom, at some hour in the dark of night, in some town. He may have done it out of academic interest. Or maybe it solved some problem for him. Ultimately, others shared the same interest or problem, and the project found prospective users. The project only touched the prospects a few at a time, since the project is ultimately small in the scale of the world.
Some of these prospects gave consideration to the project. Some deemed it worthy. Some did not. Those who appreciated it became its community. The community amplifies the influence of the project. Through the community, more prospects are interacted with. And interaction helps to move prospects into the community. It broadens the event horizon between the project and the prospects.
For any group of users, a certain percentage will desire hand-holding, support and additional services. At first, the community is small and the percentage of potential customers in reality turns out to be less than one real human. The community must grow to make any advanced customer relationships viable to the provider.
After natural community growth, the activation energy required to make a commercial open-source offering is met. Enough potential customers exist to cover the risk of dedicating oneself to a commercial offering.
In each case, new sub-groups bubble-up from within existing groups. Community bubbles from the prospects. Customers bubble from the community. And it all ultimately bubbles from the origins of the project.
If you’re running a commercial open-source business, you need to acknowledge that the size of the community will and should always be larger than the size of your customer base. Growing a community ultimately bubbles more customers. And future customers, by way of the community, is what leads to bottom-line growth ultimately.
February 17th, 2007 at 5:09 pm
Your last diagram is singleton centric. The community circle should contain the project circle, and it should contain {1..n} business circles with customer circles around them [and a nice note that while much overlap could exist, it'd be insane to try and represent that]. I’d be tempted to draw lines between the business circles and the project.
I think it’s fair to say that both Project and Community are singletons [as saying they're not is akin to forking and that means a new diagram].
Your point that the ‘project -> company’ step needs to remember that community remains larger than the customers is very sound [and sound good to both customers and community ;)], but projects who don’t see that it should be ‘project -> a company’ become inbred and lose themselves.
New committers are increasingly tied to the singleton company as there is a finer dial for recognizing those committers and non-singleton employee contributors pick up on this and don’t have the urge to contribute. The genes go stale.
February 18th, 2007 at 11:52 am
[...] Henri Yanell made some comments on my previous post. I interpreted them to mean something like the following: [...]