Thinking Out Cloud

Thoughts on Platform-as-a-Service

The recent news about layoffs at Bungee Labs has triggered a discussion about the viability of the Platform-as-a-Service concept. In this post I attempt to map the PaaS landscape and discuss possible strategies and approaches for the platform vendors. But first, to understand PaaS, we need to look at where it fits in the larger picture. PaaS is one of what I view as the three pillars of cloud computing:

1. Software-as-a-Service: Although the term "software" denotes any piece of software, the term SaaS is usually applied to the idea of delivering a complete software application to its end users over the Web, and typically with a subscription or per-usage pricing model. Examples include Zoho and Salesforce.com.
2. Infrastructure-as-a-Service: IaaS is about providing basic IT resources, such as compute power, memory and storage, over a network (typically the Internet) and usually with a subscription or per-usage pricing model. Examples include Amazon Web Services, GoGrid and Flexiscale.
3. Platform-as-a-Service: The term PaaS is often confused as it is actually used to refer to to two distinct elements:
   
   1. Web-based development tools (aka IDE). This could more accurately be refered to as Tools-as-a-Service (TaaS).
   2. A run-time application platform that enables running applications in the cloud, typically on top of an IaaS and delivered as SaaS.

 The two types of PaaS are sometimes confused because vendors often offer them combined as a single solution. Things are further confused because they often include a third, separate, component: that of a development framework or programming model (what is commonly referred to as the API).

To understand this better, let's compare to the more familiar and established world of Java. Building and running a standard Java app requires three main elements: the API (the Java programming language itself), a run-time platform (the Java Virtual Machine, or JVM -- or more accurately, the Java Run-time Environment, or JRE) and development tools (popular IDEs such as Eclipse and IntelliJ). Note that the three are separate from each other. A developer can choose which IDE and which JVM implementation (from IBM, Oracle, Sun or others). Also taking advantage of the Java Run-Time Environment does not require the Java programming language. One can use other interfaces such as JavaScript, Groovy and JRuby.

 The same principles apply to the Java Enterprise Edition (JEE). A developer can choose from a number of application server implementations (the run-time), IDEs and APIs (e.g., Spring Framework or EJB).

 

Armed with this understanding, let's look at Bungee Labs again. They made some crucial decisions with their product, BungeeConnect, which significantly impact the adoption of the product. the first was that they provide all of the elements: the development tools (a web-based IDE), the run-time platform (they may be leveraging other platforms underneath but it is transparent to the user), the hosting (i.e., IaaS) and the API (they offer a proprietary C-like API).

 
Second, they decided that you cannot separate the four elements from one another. They are tightly-coupled. You cannot use their tools without also adopting their API, run-time platform and hosting service. If you like their tools, and want to use them with other run-time platforms, APIs or cloud providers (hosting), too bad.

Third, they didn't leverage standards. Although their programming language syntax is C-like, so it is at least familiar to many developers, it will not execute on other run-time platforms as-is.

The adoption barriers created by Bungee's self-imposed limitations are becoming evident. A developer or company contemplating the use of BungeeConnect are forced to make a strategic, long-term decision about the future of their business: to be locked-in to Bungee's product in almost all aspects of their own product.

 

I don't mean to pick on Bungee. As a fellow entrepreneur, I sympathize. I can also understand the considerations they had when making these choices. For one, the notion of creating a "total solution" seems appealing at first. And from a practical perspective, it is easier to create a more powerful solution when you restrict and control the environment it operates in. Besides, they were being ambitious, and I respect that.

 

Let's look at some alternative approaches that Bungee could have taken (and still can), as well as what other players have been doing.

Go-To-Market Strategy

Generally speaking, achieving adoption for a new platform is a difficult task. It is true that the advent of cloud computing creates an opportunity for new players, but major challenges remain. There seem to be four main approaches to doing this:

• Brute Force: the very biggest vendors have the marketing muster, credibility and resources to make it happen by "brute force." An example of such an approach would be Google App Engine. Google has taken the exact same approach as Bungee -- they provide all four elements -- but they obviously have the market visibility and budgets to achieve fast adoption.
• Open Source: It means two things: first, pricing adoption barriers are removed (i.e., offer it for free and develop premium products and services later). Second, the product source code is available, allowing end users to customize it and the comfort of having access to source if something happens to the vendor. 10gen is an example of a vendor taking this approach.
• Specialized: Focus the platform on a particular segment of the market, instead of trying to be all things to all people. The key is that you have to build a "total solution" for that particular segment. This is reminiscent of Geoffrey Moore's Crossing the Chasm model. Ning is a good example, as it's a platform focused exclusively on building social networking applications. Other forms of specialized platforms could focus on a particular industry or type of application.
• Ride the Coattails:This strategy involves building a platform that allows developers to leverage an existing install base. The Facebook Platform is a good example. Given that today many applications expose their APIs to the general public, vendors other than the 'owner' of the install base can take this strategy.

Target User

Another dimension PaaS vendors should think about is who is the target user of the platform. The typical choices are programmers versus so-called business users (non-programmers). Bungee, Google App Engine and 10gen are all clearly targeting programmers. Ning, on the other hand, allows people without any code-writing skills to quickly create their own social network. They do, however, offer developers the ability to further customize their application through programming.

Totality of the Solution
As already noted, PaaS-related vendors need to decide which elements of the 'stack' they provide. Specifically, do they provide the run-time platform, the development tools, the hosting service, all of the above? And if so, do they lock users into their components or do they allow use of certain components from other vnedors? Here's a list of vendors and the choices they made:

Product	Run-Time	Tools	IaaS	API	Primary Target Users	App Focus
BungeeConnect	Yes	Proprietary web-based IDE	Yes	Yes. Proprietary	Developers	Free form
AppJet	Yes	Proprietary web-based IDE	Yes	Semi-proprietary, JavaScript-based	Developers	Free form
Jboss Cloud	Yes	Stanadard, installed IDEs	No (suports EC2)	Standard (J2EE)	Developers	Free form
GigaSpaces Cloud	Yes	Standard, installed IDEs + Cloud Tools for deployment	No (supports multiple clouds, including EC2)	Standard (Java/Spring, .Net, C++, JavaScript, Groovy, JRuby, JMS, JDBC, Jcache)	Developers	Free form
Aptana Cloud	Yes, for PHP and AJAX1	Aptana's open source installed IDE (based on Eclipse)	Restricted to Aptana hosting2	Flexible IDE for a variety of APIs, including JavaScript/AJAX, PHP, Ruby, Java	Developers	Free form
Force.com	Yes	Yes	Restricted to Salesforce.com hosting	Proprietary		Database-centric
DabbleDB	Yes	Proprietary web-based tools	Restricted to DabbleDb hosting	JavaScript based on JSON schema	Business (developer customization options)	Database-centric
Zoho Creator	Yes	Proprietary web-based tools	Restricted to Zoho hosting	Proprietary	Business (developer customization options)	Database-centric
LongJump	Yes	Proprietary web-based tools	Restricted to LongJump hosting	Java, REST, SOAP	Business	Database-centric, Workflow-centric
Google App Engine	Yes	Standard, installed IDEs + SDK	Restricted to Google App Engine hosting	Python (with limitations) and additional task-specific APIs	Developers	Free form
Coghead	Yes	Proprietary, web-based tools	Restricted to Coghead hosting	Proprietary	Business	Database-centric, workflow-centric
WyaWorks	Yes	Proprietary web-based tools, and accessible via installed IDEs	Provide hosting and allow deployment on any infrastructure	JavaScript, JSP, Java	Business and Developers	Free form
Intuit Quickbase	Yes	Proprietary, web-based	Restricted to Quickbase hosting	Proprietary3 Http API, XML/XSL and a Formula Language	Business	Database-centric
10gen	Yes	Yes, but you can develop code with standard IDE	No, supports multiple clouds	Standard (JavaScript, Python, Ruby)	Developers	Free form
Rollbase	Yes	Proprietary, web based tools	restricted to Rollbase hosting	Proprietary	Business (developers cutomization options)	Database-centric
Morph Labs	Yes	Not provided by Morph	Restricted to Morph Labs hosting	Standard (Java, Ruby)	Developers	Database-centric

Notes to Table:

1. According to a comment posted by Kevin Hakman of Aptana, a Ruby-on-Rails run-time will be available soon.
2. Aptana Actually uses Joyent as the host today (although this fact is transparent to the user). The company plans to add the ability to choose other hosting providers and does not see hosting as part of its business model (see comment by Kevin Hakman below).
3. The QuickBase API is proprietary, but like others on the list, it it can be wrapped by other, standard APIs. The QuickBase user comunity has already done so for Perl, Ruby, PHP and others.

Community and Eco-System

Another important aspect for any platform, PaaS included, is the notion of an eco-system and a community that is built around it. How well the platform vendor encourages, enables, nurtures and promotes this community is of critical importance. There are a number of ways to do this:

• Classic community tools: forums, ability to share and blog, wiki documentation editable by users, etc.
  
• Allow Extension of the Platform: This can be achieved by exposing APIs and/or open sourcing the code and providing the process and tools for submitting extensions, plug-ins and add-ons, bug fixes, etc. 10gen, for example, has open sourced its platform. Many of the other players in the table above are exposing APIs and providing other ways to modify and customize the platform. At GigaSpaces, as another example, we open sourced our API -- OpenSpaces -- and created the openspaces.org community site, which lets developers share their creations.
  
• Create a marketplace around the platform: Often the PaaS vendor already garners interest and attention and can make that marketing prowess available to its own users. Many of the PaaS providers listed here allow their users to list their creations in some sort of a catalog or marketplace. Other users can sometimes clone the creation and extend it, leveraging work that has already be done. In many cases the platform vendor allows its users a way to monetize their efforts. Salesforce.com's App Exchange is a good example of this. By making its platform open and extensible, Amazon enabled a whole cottage industry to develop around its Amazon Web Services platform, with companies such as RightScale.
  
• Access to end-user data: One of the most effective (and tricky) ways to foster an eco-system around the platform is to allow building applications that can access end-user data in other applications. Now when I say "access", I mean that they have the technical ability to do so. The end user, of course, needs to approve such access. For example, when you build an application on Force.com, it can access the contact, account and deal information in the users Salesforce.com application.

If anyone thinks I misrepresented any of the solutions in the table above, or if you have any other thoughts, please comment.

25 Most Influential People in Web Hosting

This is pretty cool. Although it was published in May, I just found out that Jimmy Atkinson listed me in his 25 Most Influential People in the Web Hosting Industry over at the Web Hosting Database (WHDb) site. The list is made of three categories founders/CEOs, CTOs/Engineering and Marketing people. I'm in the latter category.

If you're wondering what I have to do with "web hosting", the connection of course is cloud computing, which is converging hosting with infrastructure software and other aspects of the industry (but more on that in an upcomg post about Platform-as-a-Service).

In any case, thanks for including me, Jimmy. It's a very distinguished list.

GigaSpaces Updates on Twitter

Those of you with Twitter accounts can now follow GigaSpaces-related updates on the GigaSpaces Twitter stream that was set up by Jim Liddle.

You can also follow me at: http://twitter.com/gevaperry

Are Developers Growing in Influence?

Are developers and architects becoming more influential in infrastructure software purchase decisions in large organizations?

Back in September, Matt Asay blogged an interview with Laura Merling of Krugle, which makes a search appliance for software code across the enterprise. In the interview Laura said:

The power for decision making and buying has shifted to the developers, architects and midlevel managers. We are in some very large companies and have not once talked to a CIO! Developers have paved the way with their newfound power.

This "newfound power" that Laura speaks of has to do with open source software. More accurately, it has to do with the fact that most open source software is available for *free* download with a production license. So, presumably, the developers don't need permission from anyone higher-up in the organization to use the product, as there is no purchase involved.

The story goes that this is how Linux, JBoss, MySQL -- and more recently -- Spring and Mule, to name a few, have crept into large enterprises. And one day, after some minor disaster, an executive wakes up and says: "Holy crap! this thing is running on hundreds of our servers, we better get some support". Bam! a seven-figure deal is born, and it was the developers who really made the decision two years earlier.

Obviously, developers have always been influencers and evaluators of the software they will eventually use, but what I described above is a very different dynamic. If this is in fact happening in a major way, it has huge implications to how software used by developers should be marketed and sold.

Not surprisingly, it is very difficult to find hard data on this issue (I've searched). So here's a question:

• If you work at a vendor -- open source or not -- are you seeing this trend?
• If you work at a large company -- as a developer or not -- are you seeing this happen?

Would appreciate any thoughts about this.

Update: Some interesting comments about this blog on TheServerSide, and a thorough analysis by Erik Engbrecht.

GigaSpaces on Facebook

Facebook now lets you create pages for businesses and products, so I've created a Facebook page for GigaSpaces. If you want to join it as a "fan" (facebook terminology), just go to the page (click on link above) and on the upper right corner click on "add to my products". We'll update on new events, offerings, product developments, etc. and you'll receive it via facebook.

Hopefully, over time some interesting discussions will take place.

Share on Facebook

Even Analysts Face Open Source Questions

James McGovern asks Why Gartner Analysts Don't Blog. You can read his post for the opinions he says he gathered -- and most of them are unflattering.

Although I can't entirely disagree with many of the points James is making, from my experience James is being a bit too harsh with Gartner. There are good people there, such as Massimo Pezzini, who have technical depth, do real research, and provide value to smaller vendors such as us (GigaSpaces) -- and definitely spend more than half an hour briefing with us.

I bet you there is a fierce internal debate going on at Gartner about the question of blogging. Where the competent analysts, such as Massimo, argue for it; and the rest are against it.

All this is just conjecture on my part, but I think it all boils down to the question of Open Source Vs. Closed Source. The anti-blogging  folks are probably making the claim that they are in the business of selling their research and analysis, not giving it away for free on the Internet. And frankly, it's not a simple issue. It's one that many software companies, such as us, face.

Few analyst firms have gone completely open source, such as Red Monk, and their model is yet to be proven on a mass scale (although it seems like Red Monk is doing great for a boutique shop). Maybe the mass scale model is dying altogether?

Some analyst firms have found, or are still experimenting, with some middle ground of unpaid blogging and paid research and reports.

The reason I am interested in this topic is that we have been giving the issue a lot of thought at GigaSpaces as well (from a software company perspective, of course). There are many interesting models out there, such as those used by Jive, Atlassian, MySQL and many others.

We're coming up with our own, pretty unique, model. Stay tuned...

PR Done Right

As CMO at GigaSpaces , I kind of live in two worlds: software developers/architects and marketing. I mostly write here about the former world, but this post is about the latter.

Todd Defren recently wrote about his firm, Shift Communications, and their relationship as a PR agency with their customers -- and specifically with one customer around Blogger Relations. It so happens that we are one of Todd's customers and let me say outright that we love them and they are doing an awesome job for us.

Anyway, his post brought to mind a few thoughts about PR I've been meaning to post for a while. These are some random thoughts about PR, not a cohesive thesis.

Point #1: Blogging/Social Media increases the need for a PR Agency

For those of you who are not familiar with modern world of marketing/PR, for the past two-three years there is a lot of talk on the blogosphere about the death of traditional PR because of blogging and social media in general. People just won't shut up about it. (Google search: "death of pr").

From my experience, social media increases the need for working with a PR agency, it does not diminish it. This is simply because of the fact that the analyst/reporter (in the broad sense of the words) universe is now much more fragmented and large, and it is not cost-efficient to try to tackle it all in-house.

Don't get me wrong, there is no substitution in the blogoshpere to your company executives, product folks, etc. getting personally and directly involved in the conversation. That can never be outsourced to an agency - and we certainly do a lot of that at GigaSpaces. But there is a lot of work around it, such as tracking who's writing what, making initial pitches and so on, which a PR agency can greatly help with (especially if they are as savvy about it as Shift is).

Point #2: Strive to make your PR agency as much a part of the team as possible

The reality for small and mid-sized companies such as GigaSpaces is that many of the marketing functions are outsourced. We have a PR agency, SEO consultants, tech writers, marcom writers, graphic designers, web designers, etc. This is something I don't do enough, but made it a point to myself to try and integrate all of these "external" contributors into the team. It means weekly calls, regular email updates, etc. It means sharing with them the bigger picture and the going-ons of the company in other areas.

Point #3: Select the right agency, right for you that is

Duh!

I interviewed a lot of agencies before I decided to go with Shift. I had a very specific set of criteria, and Shift were perfect for me:

• Not too big, not too small. A very small firm (up to 10-15 people) doesn't have the bandwidth to handle peaks in activity. In a very large firm (probably over 100 people, you don't get enough attention ).  Shift is about 80 people, which was perfect for us. In addition, they set it up so that there are 5-6 different people involved in the GigaSpaces account and they are all kept in the loop on everything. So they can fairly quickly and seamlessly take over from each other when necessary.
• Not afraid of deep technical subject matter. I wanted a firm that wasn't afraid of dealing with technical material and had experience in marketing to developers. Shift fit both.
• Savvy about Social Media. This was an easy one. I found Shift having been a reader of Todd's blog for a while. He is one of the leading thinkers on Social Media and a pioneer of the Social Media Press Release.
• Right attitude. From reading Todd's blog, I knew these were people I could work with. Posts like this made it clear: What Would David Do? And I knew that if Todd has the right attitude, most likely anybody who works for him does too.
• Right Location. I needed a firm that has presence on both coasts. Wall Street and Silicon Valley.

The results speak for themselves. This graph shows the number of press mentions GigaSpaces received in May-June (the two months since we've been working with Shift) versus our competitors and other companies in the space who we track (I removed names and numbers).

We received more press mentions than all of the other seven companies combined.

And that was growth from a negligible amount in April. Pretty impressive.

Now, granted this is also because we had quite a few things going on during this period (new product version release, Microsoft partnership, customer win announcements, etc.), but still pretty impressive.

Extreme Talent

We have a lot of kick-ass talent at GigaSpaces, but it's not every day you get an email like the one we got about Owen Taylor, one of our main technical evangelists. We got this from Atif Aziz, one of the organizers of the Swiss .Net Microsoft User Group (published with Atif's permission):

 

I just wanted to drop some feedback about Owen's presentation to the user group. Frankly, I am not exaggerating the slightest by saying the attendees (myself included) were completely blown away. I am really grateful that he put all his passion and enthusiasm in delivering the talk (even after such a long flight), which went to demonstrate his own conviction of the subject matter and consequently made the audience more receptive to newer ideas. Owen is a rare gem in that he possesses some very unique and exceptional presentation and story-telling skills. He took a subject that was fairly new to the audience and delivered it very effectively, building momentum as he went along. He presented the problem space in its historical context and then slowly moved over to the solution without missing any of the essences along the way.

I would end there, but I think the attendees were even more amazed when he managed address all of the technical concerns and queries that were brought up during and afterwards. Really, I know something changed in that room that day. :)

Here are the exact words of one of the attendees that I received by e-mail the following day. “I just wanted to thank you for bringing this "inspiring" and "delicious-food-for-thought" talk to the community. It was great and I enjoyed it a lot. thanks again”

Owen tirelessly travels the globe, spreading the word about Space-Based Architecture, GigaSpaces, Jini/JavaSpaces and all things distributed computing.

Besides his own excellent blog, Owen's been featured multiple times on TheServerSide.com and other sites, sharing his deep technical knowledge. But what really sets Owen apart is that he is a natural born performer. He was a performer on Broadway for many years and that combined with his tech knowledge and passion -- well, it's dynamite.

To check out Owen in an event or Java/.Net user group near you, go tour Upcoming Events. To see how Owen has been tirelessly spanning the globe, see our Previous Events...

Tower of Babel

Our industry has a problem, and it has to do with words. We use the same words to mean different things, and different words to mean the same thing. In particular, there is a problem with naming categories of technology or products. Consider the terms grid computing, utility computing, on-demand computing, high-performance computing. Some people see them all as referring to the same thing. Others believe there are nuances among them, and yet others feel they refer to completely different things. Now, also add to the mix the terms fabric, virtualization, distributed computing -- all of which are also frequently used to refer to similar -- if not the same -- things, and you've got a big mess.

I was thinking about this because it seems that GigaSpaces, and the tech category it belongs to, is now at a point where it is crossing the proverbial chasm from early adopters to mainstream customers. And an important part of maturing is having a  clear and consistent name for the product category.

This Tower of Babel phenomenon occurs partly by coincidence -- different people come up with different words to describe what they or others are doing more or less at the same time. But partly, this is happening by design.

I see three main reasons for this (in no particular order):

Reason 1: The prevailing Silicon Valley common wisdom of marketing technology is based on Geoffrey Moore's seminal Crossing the Chasm. In it, Moore writes that if you are introducing a new technology, invent a new category for it and position yourself as the leader.
So you've now got thousands of vendors -- start-ups or established -- inventing new categories and crowning themselves supreme leader of the category. For example, the terms Business Service Management (BSM) emerged to describe the suite of application development, testing and monitoring tools provided by vendors such as BMC Software. To establish itself as a leader in its category, Mercury Interactive (now part of HP) went ahead and created the competing term Business Technology Optimization (BTO). You now have two terms referring to what is essentially the same thing.

Reason 2: Competing analysts need to make their mark on the world. The Forresters and Gartners of the world want to be able to say "I called it." So they describe an emerging trend -- and name it. For professional prestige reasons, the competing analyst firm cannot use the other firm's terminology, so they describe the same phenomenon in a slightly different way and give it a different name. Luckily, the big analyst firms have consolidated and there are only a few of them now, but on the other hand, there is a growing number of boutique firms, Wall Street analysts, the press, the blogosphere -- all throwing their own phrases into the mix.
So as an example from my own experience with GigaSpaces: Gartner categorizes us under the general area of Extreme Transaction Processing (XTP). Within it, they place us in two sub-categories: Grid-Based Application Platforms (where they name GigaSpaces as the leader and include vendors such as Appistry) and Distributed Caching Platforms (Where they name GigaSpaces as the leader together with Tangosol/Oracle). Forrester categorizes us under the umbrella of the Information Fabric (and more recently Information-as-a-Service (IaaS), and within it in the sub-category "Data Grid." The various vendors in the spaces use any and all of these terms, as well as things like "Data Fabric" and "Clustered JVM."

Reason 3: "The king is dead; long live the king!" What do you do if you provide hosted application services, commonly known as an Application Service Provider (ASP), but no one wants to touch that with a ten-foot pole, because of the billions of VC investments lost in that category during the dot-com bust? You invent a new name for the category: you call it Software-as-a-Service (SaaS). Presto! Out with the old and un-sexy; in with the new and trendy.

The reason this is an industry-wide problem that we should all care about is because the confusion caused by this creates an impediment to the adoption of new technologies.

Moore states this concisely when he writes:

Potential customers cannot buy what they cannot name, nor can they seek out the product unless they know what category to look under.

Our industry is already dealing fairly competently with a similar issue: technology standards. Why not apply the same approaches to "marketing standards"? Sure, reaching technology standards is often a  lengthy process, fraught with  political maneuvering and compromise, but at the end of the day it works. And the reason it works is because vendors realize that lack of standards are a barrier to overall adoption of their products. It's an issue of increasing the size of the overall pie, and not just fighting for a slightly bigger slice of a small pie.

So borrowing from the tech standards approach, here are a few possible ideas to consider when it comes to technology category naming conventions:

• A Standards Body -- made of analyst firms, vendors and other stakeholders
• A Community Process -- similar to the Java Community Process (JCP)
• And my favorite: A Wikipedia-like model (perhaps with some modifications making it a hybrid with a standards body). So for example, under the entry Object Spaces in Wikipedia, it says: "It has been suggested that this article or section be merged into Tuple space. (Discuss)". Besides a discussion process, one can also imagine a polling function and actual voting.

Some of this will always remain a problem, because the different products in a ctegory don't usually overlap 100% and therefore it does make some sense to categorize them differently. It will also remain a problem because vendors, and perhaps rightly so, will always want to claim their turf and have the game played by their rules. This also happens with technology standards. But still, seems to me that there is a lot of room for improvement.

Marketing to Developers, Part I

Marketing to developers (software , not real estate) has unique challenges. That may seem obvious to some, but I was surprised to see how little information is out there about this topic. A Google search on "marketing to developers" yields a mere 331 results, only a handful of which are relevant to the topic and none of which systematically discuss it. Searches on "marketing to programmers" and "marketing to software engineers" provide even poorer results.

And of course there are no books specifically about the topic.

The most useful result I found were the comments on a blog post by Joel Spolsky (of Joel on Software fame) from about 2.5 years ago. Joel was asking for advice on how to market software to programmers and received some good responses.

The topic is of obvious interest to me as chief marketing officer at GigaSpaces, a company that makes an infrastructure software product intended for use by software developers.

So I plan to write some more on what I've learned from more than a decade of being involved in marketing to developers in one capacity or another, but in this post I'll just cover why I think marketing to developers has some unique challenges:

• Developers always think Build-or-Buy. The first thought that crosses a developer's mind when you try to sell them software is "I can build that myself - and better." The build-or-buy decision may be present in other industries, but nowhere is it as dominant as when trying to sell software to developers. As my old boss, Dave Parker, used to say: "At the end of the day, software is just ones and zeros." Meaning, you can code anything with a relatively small up-front investment. It's an extreme form of the Not-Invented-Here mentality, which prevails in many engineering organizations, combined with the fact that with software -- at least seemingly -- building yourself is a feasible option.
• Developers are tinkerers. They love to tinker with the product before they buy. If they can actually build a prototype, they will. If they can look at the source code, all the better (and it has nothing to do with any advantages of open source -- it is pure curiosity)
• Developers are religious. Technology religious, that is. Again, this may exist in other businesses, but software developers are down right zealots: Java Vs. .Net, Mac Vs. PC, SOAP Vs. REST -- to name but a few of the holy wars developers wage. You've got your open source fanatics, who sacrifice their economic prosperity for the cause. You have your Linux crusaders, trying to liberate the Holy Land of OS from the Microsoft infidels, or some other perceived "evil empire."
• Developers are cynical. They will be particularly resistant when they believe they are being sold to or marketed to. Now, this is becoming increasingly true of the general consumer populace, as we are told repeatedly by books such as The Cluetrain Manifesto or gurus such as Seth Godin, but it is especially true of developers. They will always try to challenge the marketer or seller, they will look for the weakness points and the corner cases.
• Like all experts, developers suffer from the Curse of Knowledge. I am referring to the Curse of Knowledge as described in the book Made to Stick. It means they cannot imagine what it is like to not know what they do. In all of my career I cannot recall a single software engineer who could really explain a software issue to non-techies in a simple way.

Obviously, some of the items above are gross generalizations, but I still think these are useful observations from a marketers point-of-view. Also, I want to apologize in advance if the overall points above may seem to some as negative towards developers. That was not at all the intent. I was trying to list the unique challenges of marketing to developers -- not the joys of marketing to developers. We are obviously talking about a profession whose members, as a rule, are highly intelligent, highly educated, open-minded and pleasant to work with.

So this is a first crack at the topic. In a future post I will address some of the strategies and tactics I've found useful when marketing to developers. As always, if anyone has any further insights, ideas, objections or comments, by all means.

UPDATE: This update refers to my first bullet above "Developers always think Build-or-Buy" [and a re naturally inclined to build]. After I published this post, I read the We See No Silver Bullet post by Bill de Hora. Basically Bill argues against Scott Rosenberg (author of Dreaming in Code) and his assertion in this Salon piece that programmers rather code themselves for wrong reasons. Bill claims they do it for right reasons. Whatever the case, it reinforces my claim that this is indeed the situation. From a marketer's point-of-view, you are facing this issue. And from personal experience I think that both are correct.

In any case, one of the comments in Bill's blog led me down a rabbit hole to this post by Jonathan "Wolf" Rentzsch, which led me to this one -- Programmers Don't Like to Code -- and the ensuing Digg post and discussion. Apparently this is a highly debated issue (not whether programmers do it, but why).

Update: more on Build Vs. Buy

Update: Owen Taylor's perspective on Targeting Developers