Parallel Feedback Loops: Integrating Your Community

December 18th, 2007 John Mark

The term innovation opportunity has been discussed by Matthew Aslett, who described it as “the potential to lower development costs for business users, while at the same time raising their potential to focus on innovative development.” This falls in line with the view that an open model is more efficient, but how exactly is it more efficient, and how does one maximize that efficiency? Does Open Source development lead to the creation of a perfect market? I will attempt to describe how innovation opportunities come about, and how to take advantage of those opportunities. The key would seem to be enhancing the ability to deal with parallel feedback loops that arise as a matter of course from interactions with your user and developer community. Put another way, maximize the surface area of your community and be able to capitalize on these “touches”.

Total innovation opportunity (TIO) as described by Aslett refers to the advantage inherent in building on the knowledge of others and not re-constructing every wheel, thus freeing developers to focus on new innovations. I should note that building on the knowledge of others does not necessarily mean code re-use, although it can. Solving the same problem using a different means, language, or algorithm but using a previous solution as a model will invariably take less time than implementing a “clean-room” solution. Regarding those core developers for a project, it would seem that the way to maximize innovation opportunities is to ensure regular interaction between them and outside community members. After all, one of the worst things that can happen to a developer group is to develop tunnel vision and work within an echo chamber. It’s better to let them see what outside users, customers and developers have to say about project direction. To illustrate this concept, I’ll make use of a comparison between older, proprietary models, and modern open source processes.

1. Older model - Engineering works with Product Management and small focus groups, usually a subset of customers, to fashion new product features. In this scenario, outside involvement is minimal, with the possible exception of a beta period that takes place well after a code freeze. The beta stage is usually designed to squash bugs, not introduce or kill product features
2. Newer Open Source model - Depending on how much of the engineering process is conducted out in the open, the product “touches” a much wider audience at each stage of development, from inception to implementation, to QA, and to ultimate release.

The key to (2) above is to maximize the number and diversity of outside touches, whereby outside community members can participate in the initial features discussion, outside engineers help validate the usefulness of the new code, and users from a variety of industries are able to put the proto-product and its features to the test. Sheer numbers of outside touches, ie. users, are indeed essential, but the diversity is actually more important - the user base should consist of developers, system architects, sysadmins, managers, and an assortment of end user types. From reading several articles on a given project’s community health, one thing is clear: just increasing downloads says nothing about the diversity of touches. If only end users download your software, you are not maximizing the potential value from your project’s community.

Each user type will touch the project in a different way and at a different stage: end users will be more likely to engage with a project that’s feature complete, sysadmins will have a higher tolerance for breakage, and ditto for developers. This will result in multiple types of data streaming in through the interfaces you’ve built, such as bug trackers, forums, wikis, etc., and often in parallel. If you accept the premise that community diversity is a key to your project’s success, then surely you must agree with the idea that maximizing your ability to handle the data throughput will determine how well you capitalize on your community’s value. Failing to close these parallel feedback loops will necessarily mean less than maximum value from your community. Thus, it’s important that each community layer have clearly defined methods of interacting with the project maintainers. Can developers easily find your code repository? Can a sysadmin locate your bug tracker? Will they understand how to find and edit, if necessary, your documentation?

Each community layer should be addressed depending on their strategic value to your project. If your priorities are structured such that your project’s community does not reach the ideal level of diversity, then a re-weighting of priorities might be in order.

Entry Filed under: Community, IT Industry