Nov 15, 2010
Chris Grams has an excellent post reminding us to avoid the tool trap when forming a community. That advice is so obvious yet so rarely practiced. Building communities is hard work and the temptation to experiment with technology is a distraction — a distraction so strong that it can obscure the fact that the community has no reason to exist. No matter what platform, the community will inevitably fail if it doesn't have the necessary ingredients: people with passion and a common set of interests and goals.
Technology can be an enabler but it can never be a driver. A robust community will survive with bad technology. I would say to intentionally use bad tools when you start a community. This approach will cause an unviable community to fail faster and save unnecessary investment. If a community is starting to grow despite bad tools, then you know you really have something worth investing in. By the way, if anyone wants to join my Julio Lugo fan club, fax me your fax number.
Jan 04, 2010
I have finally gotten around to reading Clay Shirky's excellent book Here Comes Everybody
. I love Clay's writing style and the way his perspectives make me think. One of the points that really resonated with me was about open source. But before I get into it, I should say that when Clay talks about open source, he is really talking about community developed open source (not commercial or institutional open source). Readers of this blog know that the designation "open source" simply means that it is licensed under an OSI certified license. "Open source" says nothing about how the software was developed. Given that disclaimer, Clay nails it when he describes the advantage of community developed software:
The bulk of open source projects fail, and most of the remaining successes are quite modest. But does that mean the threat from open systems generally is overrated and the commercial software industry can breathe easy? Here the answer is no. Open source is a profound threat, not because the open source ecosystem is outsuccessing commercial efforts but because it is outfailing them. Because the open source ecosystem, and by extension open social ecosystems generally, rely on peer production, the work on those systems can be considerably more experimental at a considerable less cost, than any firm can afford. (from page 245 of the hard cover version)
This quote comes from a chapter called "Failure for Free" that discusses the importance of failure for innovation. The key point is that traditional companies can't afford to really innovate because they must limit their bets to initiatives that they feel have a high likelihood of success. Innovation winds up being constrained to small tweaks to things that are well known. Real breakthroughs are rare. Community development doesn't make better ideas but it reduces the cost (and risk) of trying ideas that at first seem unlikely to succeed. Out of all this experimentation comes unexpected successes. Even the failures provide useful data that can be turned into future successes.
When open source critics see the volume of incomplete or dead open source projects as evidence against the sustainability of open source, they are missing the point. A low success rate is critical to real innovation; but that is hard to understand by someone for whom failure is discouraged or not tolerated at all. It is widely accepted that the best design for an experiment is one with a 50% chance of failure: if you know what the outcome will be, the experiment is not worth doing. But if the cost (in time and resources) of the experiment is zero or close to it, the ideal failure rate is much higher.
While we have seen many examples of community developed software out-innovating its commercial peers, this phenomenon has very little to do with open source. An open source license can create an environment that invites contribution by reducing the risk that one will exploit and unduly profit from another's contribution. But what is more important is how the software is managed. Most successful open source projects have adopted an architecture consisting of a core that is tightly managed for stability and quality and is extensible by adding modules. The bar for module code is considerably lower than core code. This allows an open and dynamic community to experiment with new ideas. The community not only bears the cost of failure but it also brings in new perspectives that the core maintainers don't have. Some of these extensions will be absorbed into the core or will become part of a commonly used bundle. Others will wither and die.
This pattern of stable core and innovative fringe does not have to be unique to open source. It doesn't really matter how the core is licensed if entry into the fringe is open. The one area that open source licensing helps with the core is in achieving a level of ubiquity that attracts a community. High licensing fees or the bottleneck of a traditional software sales process can limit the size of the user base and discourage contribution. The community developer needs the promise of a large user base to justify the time investment of contributing his work. But open source is not the only way to achieve a large user base and there are plenty of examples of commercial software and SaaS user communities that have a successful code sharing ecosystem. One company that is particularly successful is Salesforce.com. Salesforce has created a very powerful API and module packaging framework. More importantly, they have priced the product to penetrate small-medium sized companies and non-profits. In particular, the Salesforce Foundation makes the product very inexpensive for non-profits. These strategies have infused the customer population with lots companies that are highly motivated to share. These customers are active both within the AppExchange community and also integrating 3rd party open source projects like Plone (see Plone/Salesforce Integration) and Drupal (see Salesforce module).
On the flip side, there are plenty of commercial open source software companies that not been able to leverage community development. There are two primary ways an open source software product can prevent community development from flourishing. First, there can be factors that limit adoption of the core like in the case of open core products that discourage the use of the open source version. Second, the architecture can be monolithic so the only way for an outsider to add a feature is to fork the codebase. All a software producer has to do is solve those two problems. The supplier doesn't even really need to provide tools for sharing code. If the install base is large (which usually means the software is useful) and the architecture is modular, developers will find a way to communicate and share code. They can use services like Google Code, GitHub, or SourceForge to collaborate. Too often companies put code sharing tools in place without solving those two problems and then complain when they don't see any activity. In many cases, the user audience is too small to support a contributing ecosystem. In other cases, the incentives are not lined up appropriately. Shirky calls the three ingredients of a collaborative community: promise, tools, and bargain. The promise is what the contributor can expect to get out of participating; the bargain is the terms and rules for participating. Open source licensing helps with the promise and the bargain. The open source promise is that others may help improve your code. The open source bargain is that people can't take exclusive ownership and profit from your work. Some communities, like Salesforce and Joomla! have thriving commercial extension marketplaces. In those cases the promise and bargain are different but they are very motivating.
Any widely used software application, if it is appropriately designed, can benefit from community development and the benefits are not limited to the successful contributions. Perhaps the biggest value of community development is increased innovation through reducing the cost of failure. In order to harvest this value, a company needs to actively monitor, analyze and participate in its community. There is a goldmine of information sitting in the chaff of failed contributions as well as the modules that do gain traction. Companies that ignore this value do so at their own peril.
Aug 24, 2009
Jono Bacon's new book The Art of Community: Building the New Age of Participation (Theory in Practice)
is now available. I first heard about this book in January and I have tracked the progress and discussion on and off since then. As you would expect from a book about community, the development of The Art of Community was a very open process. I must say that I was a little underwhelmed by the activity around the book given the interest in the topic. Number 1 on the list of top 10 commenters had 29 comments. Number 10 had 7. Maybe most of the discussion happened over Twitter where Jono has over 2,400 followers.
I have no doubt that the book will sell well. Doesn't everyone want to start a community? I just ordered my copy and will post a review here when I get through it. The incumbent for my favorite book in this category is The Success of Open Source
by Steven Weber. Clay Shirky's Here Comes Everybody: The Power of Organizing Without Organizations
is also quite good. Both of these books effectively describe the community phenomenon. What may set The Art of Community apart is a set of instructions for creating your own successful community (Jono draws from his experience with Ubuntu and KDE). But if the techniques work so well, why hasn't the community around the book thrived? Did Jono (who also works as community manager for Ubuntu and is a musician) not have adequate time to write the book implement his techniques?
Jun 05, 2009
It was great to catch up with so many friends at the Gilbane conference in San Francisco this week. I spent literally two hours saying goodbye on my way out the door. One question that I found myself frequently answering was the reason for my recent blogging lapse. The short answer is that I have been very busy. But being busy doesn't always keep me from lobbing posts into this blog. In fact, I often find myself more compelled to blog when I am immersed in interesting work.
The truth is that I occasionally use blogging as a procrastination tool. I blog to avoid important tasks (like writing reports and deliverables) that I can't motivate myself to tackle. Blogging helps me warm up my brain and prepare me to really think. I guess when you look at it in that way, I am not procrastinating but preparing; after I publish, I am usually ready to work. So why the lapse? I have been using a better procrastinating tool.
I have taken on some application development work and I have found programming to be a more powerful distraction from my other work. When I get an idea for a blog post, I write it, publish it, and I am done. I am ready move on to that deliverable or report. When I get an idea for how to improve a feature of my application, I get sucked in and have a very difficult time stopping. There is always something more you can do to improve or extend your code. Maybe I will get curious about how something works and start exploring. I blink and 30 minutes have passed. Video games are the same way. That is why I don't allow myself to play video games. But I will never entirely give up programming. Technologists who do rapidly lose their relevance and limit their options.
Based on my small survey (sample size: 1), I would say that, other than video games, coding is the most effective tool for keeping you from important writing work (or any other activity for that matter). Knowing this about myself, I usually take every precaution to avoid programming when I need to write. When I write my reports (in XML), I make sure to hire someone else to do the XSL:FO work for my rendering templates. I deliberately started blogging on Blogger because I knew fiddling with a blogging platform would keep me from blogging. I knew this would happen when I took on this development project but it was so interesting that I couldn't resist.
I am wondering if there is some neurological explanation for this disconnect between programming and writing: that your programming brain suppresses your writing brain. My anecdotal observations seem to suggests others struggle with this too. For example, developers often hate to write documentation. I don't think that is because of poor writing skills. Of course, it also be that documentation happens at the end of the project when developers are burned out. Does anyone else have similar experiences? What is your most dangerous procrastination device?