It’s All About Barriers to Entry

One of the more common refrains our clients – as well as all of you folks too, I suppose – are hearing from me these days is “lower your barriers to entry.” The basic premise behind the thought is simple: if one accepts (as I do) Jonathan Schwartz’s contention that we’ve entered the Participation Age, barriers to entry that throttle that participation become a critical concern. A few examples:

• Poor Documentation: This may be the most common barrier to entry that I see, but it’s also the most easily remedied. It occurs when potential participants to a given project are scared off not by technical complexity, but an inability to find an accessible entry point in the form of documentation written with an eye towards the newcomer. My experience with Solaris 10 is a perfect example here; I’m an interested party that struggled through parts of the installation because I couldn’t find the type of documentation that I’ve become used to from Gentoo. Documentation is not now and probably never will be a sexy, fun task – but it can also be the difference in taking a niche project towards the mainstream. If you devote time and attention to documentation, you’ll open yourself up to new participants.
• Closed Documentation: As mentioned above, documentation is an onerous and hugely time consuming task. So one way to attack that problem is by removing the barrier of entry not to consuming documentation, but to producing it. This is most commonly achieved through the means of a wiki, but there are a variety of collaborative mechanisms that can be employed. For example, IBM/Lenovo provide little in the way of documentation for the installation of Linux on Thinkpads, but a community has arisen to meet that challenge in the ThinkWiki. Not only is it produced at no cost to IBM, it allows individual users such as myself to make corrections or add helpful tips to future readers. This real-time collaborative documentation process is a stark contrast with the traditional, high latency official documentation workflow.
• Available Code: This isn’t necessarily about source code per se, although that’s related, but rather removing the barrier to entry for potential users of your application. I’m often asked what I believe to be the most critical success factor in projects such as JBoss or MySQL, and while the technical merits are important I believe that neither one of those projects would be where they are today without being freely downloadable. In competing with their commercial counterparts, JBoss and MySQL can differentiate simply by being easily obtained. When beginning a project, the choice is often download and get coding or head to procurement, and unsurprisingly the former is generally the preferred option. While this is certainly not a prerequisite for success, it’s a very effective means of encouraging participation in your particular community, because there’s no barrier to entry.
• Poorly Implemented APIs: As we’ve seen with Web 2.0 case studies such as Google Maps, the application can become a mere footnote to the implementations layered on top of that application. The participation that produces applications such as ChicagoCrime or HousingMaps is enabled by the quality and terms of the provided APIs. That participation can be throttled, however, with a poorly designed and/or documented API. Developers continually tell us, for example, that the Bloglines API is impossible to work with effectively, and thus we’ve seen little built on top of that platform – despite its popularity.

I’m sure every one of you can think of barriers to entry to your own businesses or projects, for example. Some are necessary components of your business model or strategy, but many may not be. And it may even be worthwhile to reexamine just how “necessary” some of the barriers are, because encouraging participation is rarely a bad thing.