One of the investment themes we are pursuing here at Flybridge within our Dynamic Computing (which my partner David Aronoff covered in detail here) is the rise of developer driven business models.

Ten years ago architectural standards in large or mid sized companies were set by the CIO or Architecture review boards and the choices were fairly limited (Solaris, Linux or Windows for the OS; Oracle, DB2 or mySQL for the database; Weblogic, Websphere or jBoss for the app server, Java or .Net for languages, etc). In today's world, on the other hand, the choices have expanded by a couple of orders of magnitude with the rise of open APIS (what Ross Mason calls the ninja slicing of the application stack) open source, virtualization, cloud computing and dynamic scripting languages. This has empowered the developer to experiment, prototype and ultimately drive the adoption of new technologies in ways that were not previously practical.

As a result many companies are seeing great success in infiltrating large customers not with a top down approach marked by expensive sales people, but rather on with a bottoms up, developer led approach that demonstrates value on a project by project basis before the CIO even knows what is happening. So what are the keys to success in driving this grassroots adoption?

The most important point is the simple one: your product needs to work and have a clear value proposition. In other words the age old better, faster, cheaper still applies. But assuming that, here are ten concrete suggestions for getting the developer driven business model to work for your company:

Rapid time to value: Developers are always stretched and have more to do than time to do it. Your product needs to show value fast. Traditionally this meant less than 30 minutes to be up and running, although today this is compressing even further (one of our companies has a 5 minute register, download, install, integrate and run goal).

Free to start: Have a fully functional, high value, free product that allows experimentation. If your developer customer needs to pay to do anything useful, they wont adopt.

Superior documentation and support: Related to point one, your documentation needs to be clear, easily searched and any support issues need to be addressed quickly and thoroughly. Get everyone in your company into your support forums providing high value assistance.

Leverage existing communities of interest: As an early stage company it is hard to create a movement on your own. Tap into existing communities with momentum and where your potential customers can be found. NewRelic, which out of the gates latched on to the growing Ruby community, has always struck me as one company that did this well.

Buy your engineers plane tickets (or at least subway passes): Find where your developer customers congregate and get your team into the community to attend meet-ups, show off your product and explain what it does and why it solves real problems. Overtime, generic meet-ups can become more targeted around your specific solution as we have seen withour portfolio company 10gen, and the highly successful events they put together for the mongoDB community.

Facilitate word of mouth: Get your customers to speak on your behalf, either live or via their own blogs. Share presentations and use cases via slideshare. Contribute positively to HackerNews & Stackoverflow. Work twitter.

Have a CEO that can code: Street cred matters both externally and internally and respect in the community will build if the leader of your company has walked in the shoes of your customers. If you are a CEO and are not a hard-core developer, fix some bugs, work on the front end code, and resolve support issues.

Have a clear pricing model: Historically people think developers don't pay for anything. This is true, but their bosses will. If you are adding value, people will want to pay (and in fact a company with out clear revenue model may actually see slower uptake as Sean Ellis wrote about here), but they will need to know on what basis they will be charged so they can understand the longer-term implications of working with you.

Help your early adopters sell internally: Once you have some champions at a customer, especially in larger organizations they may need to convince their bosses that what they want to do is the right idea. Be ready to arm them with information on security, performance, integration points and other similar implementations to make this easy for them.

This is my top ten list, would love to hear other thoughts on what works, or does not work, for you.