tecosystems

It’s All About Barriers to Entry

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.

8 comments

  1. Don't forget the barriers to exit. It's about those too, if I can't get my data out of your application, or my code out of your framework, when you go under or stop being maintained or when someone else comes along whose New Hot Thing is mandated from on high in *my* organization.

  2. It used to be about barriers – that's how the GDS' in the travel industry held their positions for so long. Then began what a former boss called death by a thousand cuts – start-ups chiseling away at the GDS advantage by developing new systems that did basically the same thing for a lot less money. Today, the GDS' are having to re-invent themselves because of the new entrants. The verdict's still out on whether or not they will be successful but the GDS' are in no position to gamble they won't be.

  3. Fraxas: absolutely agreed. i think the barriers to exit are just as critical, as Jon Udell has alluded to previously.

    Gary: great analogy. i think there are actually a great many businesses that have been built over time on top of barriers to entry; indeed, it's one of the first thing that VCs typically ask about. to be candid, it's necessary – whatever your business you typically need to do something better and/or different than your competitors. the question is how to find a happy compromise between protecting your interesting and serving customers. not always easy to do.

  4. Complexity as a barrier to entry: it fails for more than one reason

    1. If it is complex for your competitor, it is also complex for you. Time is money. Tools are money. Maintenance is money. Features are money.

    2. You drag forward not only your complex product, but the complex data it produces. That bind you to the customer just as surely as it binds them to you like a marriage with two SUVs, four kids and an expensive home with a half-paid off mortgage. He who travels fast travels light.

    3. Every time a new platform is released or your old platform is revised, you get to rebuild. If you don't 'cross the chasm' just behind your competitor, (Be The Middle Gazelle), you will be unable to bid without committing yourself to big, expensive changes to the product that you were just about to obsolete. Now you have two organizations to manage instead of one and you have to scavenge the best brains from both to get the OLD work done. Particularly true in RFP-driven business models.

    4. Don't be afraid of the little guys carving you up if they make crappy software. Some of the mashups are terrible and legally dicey to apply. The juries and lawyers have yet to get involved here. Don't chase the trend to be trendy. Chase the customer requirements and make sure you are meeting them. Happy customers are the sure path to the top. Technology for its own sake is a crabwalk down a path being paved by your tools supplier. Caveat emptor.

  5. len: excellent, excellent point. complexity in some ways is the ultimate barrier to entry – the proof point? WS-*. web services should be HUGE, and the complexity is just a massive throttle for many potential efforts.

  6. MS, Google, and Yahoo? Nah – eBay, that’s a web 2.0 player

    If Web 2.0 is about the “web site as platform” then eBay is in particularly good shape. Like Amazon, its used as a trading platform by an army of small vendors. I can still remember my surprise the first time…

  7. Kathy’s Idea meet Bill’s, Bill’s meet Kathy’s: On Idea Splicing and Attention Economics

    -warning: this blog has little if anything to do with enterprise systems  This interweb thing is pretty cool. There are, like, all these people out there talking about stuff. They don’t know each other but sometimes their ideas…

  8. What is Intel’s Problem? Towards a pledge for IT and Economic Freedom

    —warning: There may be a teeny bit of politics in this blog about economic development “People with a $100 notebook computer will get the computer they deserve,” he smiles. Compare and contrast. I can’t vouch for a laptop I h…

Leave a Reply

Your email address will not be published. Required fields are marked *