September 2010


It’s been argued that developers are increasingly kingmakers in the software industry – so much so that software vendors, particularly at the middleware layer, have reconsidered pricing and source code availability in order to attract developers to their platform. Attracting developers to a company’s software platform is increasingly a concern for enterprises, not just software vendors. Enterprises seeking to attract developers can learn valuable lessons from software vendors experienced in the art of attracting developers.

Low barrier to entry is essential
Forrester’s Jeffrey Hammond and RedMonk’s Stephen O’Grady have both highlighted the importance of developer awareness, preference and adoption in the growing success of open source software. As the title of O’Grady’s post mentions, developers are the new kingmakers. O’Grady explains that source code availability is far less important than simply reducing barriers to entity for a particular technology. O’Grady writes:

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.

Particularly important is that easy access to a given technology encourages a community of users to grow around that technology. The ability for a developer with a question about PHP to find countless sources of information, either through peers using PHP or through a simple Google search played a strong role in the explosive use of PHP.

The lessons apply equally well to software of any kind, open source or not. It’s no surprise that enterprise software vendors with closed source offerings have free developer offerings and are increasingly investing in developer outreach and community building efforts.

Enterprises have platforms that need third party developers also
In fact, these lessons apply equally well as enterprises start to seek developer adoption of their own platform.

Clearly the term “platform” means something very different if one compares Microsoft’s .NET, IBM’s WebSphere or JBoss’s Enterprise Application Platform to the software platform at Sears, FedEx or Netflix. For enterprises, their “platform” comprises of the application software that codifies their core business processes. Take a retailer such as Sears for example, their platform comprises of a product catalogue, inventory management and sales promotions at a minimum. Sears web and physical presence relies on these core elements of their platform. Until recently, developers that worked for Sears were the main developer users of Sears’ software platform. But that is changing.

Today, as enterprises seek to expand indirect sales channels and overall revenue potential, enterprises are turning to free and open APIs to allow third party developers to utilize the enterprise’s software platform. I covered this trend earlier this year in a post titled “How to use open APIs for business growth“.

Attracting third-party developers with open and high performance APIs
In the previous post I covered Sonoa, a provider of API management solutions for enterprises. At the time Sonoa had two somewhat separate endeavors – Sonoa ServiceNet, a priced set of offerings for enterprises, and Apigee, a free web offering for developers.

Sonoa reached out with news that the success of Apigee with developers has prompted management to rebrand and refocus the company around Apigee. Sonoa, now Apigee, is not to subtly acknowledging the importance of developers to its business and, more importantly, to the business results of Apigee’s clients.

Apigee claims that 3 to 5 percent of Apigee Free users convert into paid customers of, at the time, ServiceNet. This is an astonishingly high conversion rate from free user to paid customer. What prompts the conversion to paying customer? Users of Apigee Free, wanted, amongst other features, to offer third party developers higher performance and the ability to differentiate quality of service based on the type of third-party developer using the enterprise’s open API.

Apigee now offers a gradual path, with increasing capability, for companies that wish to expose their APIs to third party developers.

Apigee Free: A free web-based tools platform for developers and providers to learn, test and debug APIs, get analytics on API performance and usage, and apply basic rate-limits to protect their services.

Apigee Premium: Provides advanced features on top of the Apigee Free platform, including unlimited API traffic, advanced rate limiting and analytics and developer key provisioning.

Apigee Enterprise (previously Sonoa ServiceNet): An industrial-grade API platform that provides API visibility, control, management and security.

From a third party developer, or kingmaker, point of view, using an API from a retailer that is using Apigee has benefits that lower the barrier to entry.

  • First, using an open API as a third party developer is free. With cost off the table, developers can turn to other criteria such as ease of learning, developer community and performance.
  • Second, the API is presented in a way that is simple to understand, test and learn. For instance, compare the Twitter API as presented on Apigee Free versus through the Twitter documentation on dev.twitter.com.
  • Third, enterprises that use Apigee are able to protect their internal systems from overload even while the number of third party developers using the API grows. This is critical to developers whose applications rely of the third party API being high performance.

Enterprise IT departments will be, if they aren’t already, asked by the line of business teams to expose a larger portion of the enterprise software platform to third party developers. Doing so in a fashion that lowers the barrier to entry can help drive widespread adoption of your APIs. This, in turn, can help your company increase indirect revenue channels faster than your competitors.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

While Red Hat’s leadership in the enterprise Linux market is without question, questions have been raised about Red Hat’s inability to retain its “market leader” position in the growing public cloud market. Growth prospects for Red Hat Enterprise Linux (RHEL) were delivered yet another hurdle as Amazon announced its own Linux AMI.

IT decision makers considering cloud investments should understand Amazon’s Linux AMI offering and its pricing versus Red Hat’s cloud offerings and pricing.

Amazon’s RHEL-compatible Linux
After some discussion it was uncovered that Amazon’s newly announced Linux AMI is in fact based on CentOS, which in turn is based on RHEL.

It’s interesting to note that Amazon’s entry into Red Hat’s market, using a RHEL-variant has not been met with the negative press that Oracle faced when they announced a RHEL-compatible Linux OS. Perhaps, it’s because Oracle was going after the enterprise, which has been Red Hat’s turf, while Amazon is going after the cloud OS arena, where Red Hat has yet to establish itself versus Ubuntu.

Amazon explained the impetus for this new offering:

Many of our customers have asked us for a simple starting point for launching their Linux applications inside of Amazon EC2 that is easy to use, regularly maintained, and optimized for the Amazon EC2 environment. Starting today, customers can use Amazon Linux AMI to meet these needs.

Amazon further detailed some of the benefits of using the Amazon Linux AMI, versus, for instance using another Linux AMI available on Amazon EC2 or building one’s own Linux AMI:

The Amazon Linux AMI is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2). It is designed to provide a stable, secure, and high performance execution environment for applications running on Amazon EC2. It also includes several packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. Amazon Web Services also provides ongoing security and maintenance updates to all instances running the Amazon Linux AMI. The Amazon Linux AMI is provided at no additional charge to Amazon EC2 users.

Why Red Hat should be concerned about Amazon’s Linux AMI
IT decision makers should take note of two key related points.

First, the Amazon Linux AMI is provided at no charge for Amazon EC2 users beyond the per hour infrastructure charge, which starts at $0.085 per hour.

Second, Amazon is offering support for the Amazon Linux AMI through AWS Premium Support, which starts at the greater of $100 per month or $0.10 per dollar of total monthly AWS charges.

Contrast this with Red Hat’s pricing options for Amazon EC2.

Existing Red Hat customers that qualify have the option of repurposing existing unused RHEL entitlements on Amazon EC2. According to Red Hat, in order to qualify, a customer must, amongst other requirements:

Have a minimum of 25 active subscriptions and move only not currently used Red Hat Enterprise Linux Advanced Platform Premium and/or Red Hat Enterprise Linux Server Premium subscriptions and have a direct support relationship with Red Hat.

New or existing Red Customers also have the option of using the Red Hat Enterprise Linux Hourly Beta, which is priced at $19/month plus $0.21/hr, which is in addition to Amazon’s EC2 infrastructure charge.

According to Red Hat, RHEL Hourly Beta customers receive “Support for the Hourly Beta offering includes two-day, business-hour response and email-only support”. This level of support is equivalent to a RHEL Basic Subscription – priced at $349 per year, which translates to $0.040 per hour.

It’s interesting that Red Hat has opted to charge over 5 times as much for RHEL Hourly Beta as a customer deploying RHEL would pay for an equivalent level of support in a traditional datacenter deployment. On the other hand, this leaves Red Hat plenty of room to revise their pricing as the RHEL Hourly offering moves from Beta to generally available status.

Next, let’s compare Red Hat’s RHEL Hourly Beta pricing versus using the Amazon Linux AMI with AWS Premium Support. A customer wishing to run more than 16 days, or 386 hours, a month of RHEL workload on Amazon EC2 could achieve a lower cost through the Amazon Linux AMI.

With Amazon’s entry into the Linux OS market, enterprises now have the ability to run a RHEL-compatible Linux distribution with support from a trusted vendor for as little as $100 per month.

It will be interesting to watch Red Hat respond. As shown above, Red Hat’s current RHEL price premium for cloud environments is large enough that it could potentially be decreased to address competitive price pressure.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Mozilla and Google’s open source browsers are amongst the most popular browsers on the planet. They’re even making inroads into enterprises seeking alternatives to Microsoft’s Internet Explorer. Mozilla and Google are however engaged in different paths to grow usage of their products.

Google Chrome optimized for speed
The marketing slogan headlining the Google Chrome download page reads: “Browse the web, Chrome Fast”. The rest of the sparse marketing text on the page highlight “Fast start-up”, “Fast loading” and “Fast search”. Not surprisingly, Google’s engineering driving culture are focused on the “speeds/feeds” category of features.

A recent ComputerWorld bechmark found that Google Chrome 6 to be 17 percent faster than Chrome 5. According to ComputerWorld’s benchmark tests, Chrome is now only slightly slower than Opera and Apple’s Safari, with less than 12 milliseconds between each other.

Mozilla on the other hand had limited itself to reaching “near or even to” Chrome 5 with respect to JavaScript performance for its next version of Firefox. While still in beta, Firefox 4 is within the 20 percent target performance of Chrome 5. However, Firefox 4 beta would be much more than 20 percent slower than the new Chrome 6.

Should that worry Mozilla or users of Firefox? Well, only if speed is the key metric for selecting a browser. Luckily for Mozilla, it’s not.

Mozilla Firefox looks beyond speed
Mozilla has always taken a broader approach to innovations in Firefox beyond speed alone. User productivity comes to mind as a key area of focus.

For instance, Mozilla Labs is working on a feature that could vastly improve productivity for knowledge workers, or anyone who surfs with tens of tabs open.

Mozilla engineer Aza Raskin explains Tab Candy:

It’s hard to keep everything straight with dozens of tabs all crammed into a little strip along the top of your browser. Your tab with a search to find a pizza parlor gets mixed up with your tabs on your favorite band. Often, it’s easier to open a new tab than to try to find the open tab you already have. Worse, how many of us keep tabs open as reminders of something we want to do or read later?
Enter: Tab Candy.

With one keystroke Tab Candy shows an overview of all tabs to allow you to quickly locate and switch between them. Tab Candy also lets you group tabs to organize your work flow. You can create a group for your vacation, work, recipes, games and social sites, however it makes sense to you to group tabs. When you switch to a grouped tab only the relevant tabs are shown in the tab bar, which helps you focus on what you want.

Not surprisingly, the Google Chrome ecosystem is attempting to copy Tab Candy in the Tab Sugar open source plug-in project. That Google isn’t tackling this type of user productivity feature themselves, like Mozilla is doing, can be traced back to Google’s apparent priority for speed versus productivity.

Google & Mozilla jointly growing browser footprints
While Google & Mozilla may differ in their approach to building browser make share, they both share a vision of the browser taking on a much larger role in computing.

For instance, Mozilla recently launched the Mozilla Labs Gaming division which is “committed to providing the game developer community with the platform and tools they need to make innovative games on the Open Web”.

The power of HTML 5 allows developers to create browser-based games that were previously constrained to native PC applications or game consoles.

According to Mashable, Google is also interested in the browser becoming the gaming platform of choice on PC devices.

Google has gone as far as creating an operating system that centers on the browser as the application runtime container and an application store for HTML 5 applications.

It will be interesting to watch Mozilla and Google’s browser investment areas in the future, particularly as Firefox and Chrome continue taking share of the enterprise browser market.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Node.js, a new open source JavaScript-based server side framework has become a hot new technology for web developers. While still early in its maturity and adoption lifecycle, Node.js recently gained HP/Palm’s endorsement with its inclusion in webOS 2.0. Learn about Node and its future prospects before your developers begin to endorse its use in the enterprise.

From browser to server
While JavaScript has been used in the browser for over a decade, its use as a server side application language has been gaining developer traction, primarily due to Node.js.

Node.js lets web developers write event-driven JavaScript applications that run on Google’s open source V8 JavaScript engine. For instance, Jackalope is a web application built in under 48 hours during the Joyent sponsored Node.js knockout competition. Jackalope provide real time web statistics on mouse movements and clicks on a website and scales with the number of users on a given webpage.

Scalable applications from less experienced developers
As an IT decision maker, Node.js holds the promise of enabling less experienced, potentially lower cost, developers to create more scalable web applications than they can build today with existing skills and languages.

Node.js attempts to achieve this goal through its asynchronous nature as described on the Node.js website:

Thread-based networking is relatively inefficient and very difficult to use….Node will show much better memory efficiency under high-loads than systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process–there are no locks. Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.

Node.js requires developers write event driven applications. The use of AJAX in modern web applications which utilize JavaScript, an event-based language, provides Node.js with a sufficiently large developer base to draw from. Whether developers have written server side modern web applications in PHP, Ruby, Python, Java, etc., chances are they’ve been exposed to some degree of JavaScript programming at the presentation layer.

The large developer base and growing community around Node.js were key factors in HP/Palm’s decision to utilize Node.js in its webOS 2.0 platform. Dion Almaer, Director of Developer Relations at Palm, explained in an email:

Node was an obvious choice for us. We had started to write a JavaScript service framework ourselves, but then Node came out with a great product and a great community. Rather than come out with our own system, we wanted to align behind something that was out there. We are webOS after all, and we’re always looking to align with the Web as a whole. We only innovate when there aren’t standards for us to work with (de facto or otherwise). The node team was also FANTASTIC to work with, and really helped us as we transitioned it to a mobile form factor.

Scaling applications – a reality check
Alex Payne, a developer at BankSimple, however provides a reality check of Node.js’ scaling aspirations. Payne explains the technical challenges between, as he calls it, “Scaling in the Small” versus “Scaling in the Large”.

Payne writes:

The power of today’s hardware is such that, for example, you can build a web application that supports thousands of users using one of the slowest available programming languages, brutally inefficient datastore access and storage patterns, zero caching, no sensible distribution of work, no attention to locality, etc. etc. Basically, you can apply every available anti-pattern and still come out the other end with a workable system, simply because the hardware can move faster than your bad decision-making

To further scale an application like the one Payne describes above, he suggest developers must only select a technology that with “slightly better” performance characteristics than the currently technology. On the other hand, Payne explains, a system with significant scale requirements has no single magic bullet technology choice. Payne explains:

When you’re operating at scale, pushing the needle means a complex, coordinated dance of well-applied technologies, development techniques, statistical analyses, intra-organizational communication, judicious engineering management, speedy and reliable operationalization of hardware and software, vigilant monitoring, and so forth. Scaling is hard. So hard, in fact, that the ability to scale is a deep competitive advantage of the sort that you can’t simply go out and download, copy, purchase, or steal.

Payne sees Node.js being a very attractive technology choice for developers dealing with “Scaling in the Small” scenarios. Other technologies such as Java or Scala, and a host of related architecture decisions are better suited for operating at high scale in Payne’s opinion.

Node.js in your PaaS of choice
For most enterprises, a fairly large portion of their applications could operate under the “small scale” limitation, opening the door for Node.js usage.

However, it’s important to note that, outside of the .NET market, modern enterprise web applications are largely Java based. Dynamic scripting languages haven’t crossed the mainstream enterprise chasm to any significant degree.

Maybe Node.js, like other dynamic scripting languages before it, won’t play a major role in your datacenter, but it could still impact your IT portfolio – through your platform as a service (PaaS) provider of choice. Node.js is an appropriate technology choice for web applications that need the elastic scale characteristics a cloud provides.

Joyent, a startup that employs Node.js creator Ryan Dahl, and Heroku, a cloud service provider, are both offering Node.js runtime environments in the cloud. It’s also within the realm of possibility that Google would support Node.js on its PaaS offering, Google App Engine (GAE). This decision may be accelerated by Google’s decisions in the Java ecosystem.

While the future of Node.js in the enterprise is not at all guaranteed, its ability to allow less experienced developer to create more scalable applications by leveraging skills they already have with JavaScript, bodes well for the technology.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”