Open Source Talent Drain - How Success Can Hurt Open Source Projects

I am attending the 451 Group Conference in Boston this week. Raven Zachary, the Open Source analyst for the 451 Group, led a session on the future of open source.

One issue Raven raised was the difficulty of scaling a successful open source project once it has become successful. The hallmark of a successful open source project is that the lead contributors hit the trade show circuit while big players like IBM cherry pick key project contributors to bolster their own offerings.

Raven gave the example of the Tomcat team, where a number of key contributors have been hired away, leaving the team roughly the same size it was 5 years ago, despite vastly higher usage and community needs. The solution would seem to be a model where the contributors could make enough money to keep working on the project as it becomes more successful (aka the JBoss model).

For long-term success, it may be that an open source project must be financially successful enough to cherry pick its own best contributors. Ruby on Rails may be the anti-example to this strategy, so it will be interesting to see how they handle their own success long term.

A related problem is that once an open source project is successful, its contributors can command significant consulting fees for doing work that others could do if the product had better documentation or usability. There is an odd negative incentive here, where making an open source product more user-friendly could cost the core contributors money. In the worst case, the incentive is to add cool but half-baked features so you have more stuff to talk about at conferences.

Some other interesting points from Raven's talk:

• Simplest definition: open source is community supported software that is freely available on the internet and which has minimal restrictions on redistribution. A more complete definition is here. Many popular open source products don't exactly fit this definition, so open source is at some level a business positioning as well as a development and distribution model.
• Support and services model is most accepted: customers are loathe to pay license fees to "upgrade" a supposedly free thing. I'm not so sure this is the whole story. I had a subsequent discussion with David Skok at the conference, and he felt the key to JBoss' success had been their ability to upsell management software to JBoss users on a subscription basis, taking their ASP from $10K to $50K.
• Vendor opportunity to reduce stack complexity: customers are struggling with how to manage 15 different open source vendors, each with its own licensing and support community. A related issue is how to handle integration issues between these products, an area being addressed by companies like Red Hat and SpikeSource. Our own WaveMaker product integrates over two dozen open source applications, so this trend is both real and accelerating.
  

When a rose by any other name is a clunker: when and how to rename your startup

Making the decision to name a company is always difficult. Making the decision to re-name a company adds even greater complexity.

After nine months as ActiveGrid, we decided to rename the company WaveMaker. Our board asked tough questions about our motivations, making us think long and hard about what was wrong with the current name and what we could accomplish with a new name.

How to tell if your name needs changing:

1. Customer misdirection. A bad name makes people believe things about your company that are not true. For example, our name, ActiveGrid, implied we had something to do with grid computing, which we did not. That meant that every conversation would start out but explaining that our name was ActiveGrid but we had nothing to do with grids.


2. Employee alignment. Another negative effect of a bad name is to distract employees. A name that implies they should be doing something else makes it hard to keep everyone's eyes on the same ball.


3. Analyst fatigue. In sort of a tech version of "three strikes, yer out" a name that has been associated with a number of grandiose but never achieved visions starts to become a PR team's nightmare. No matter how compelling the next vision, press and analysts may just not be willing to get suckered yet again.
   

Having decided to rename, you now face the renaming process. We decided to go with a naming firm that did both the naming and graphic work (we worked with SB Master of Master McNeil and she did an outstanding job)

1. Identify your market: who do you want to know about your name? If you don't know who you are selling to, any name should be fine. Once you know your target audience, make sure the name is one that will resonate with them.


2. Crystallize your story: what attributes define you and make you unique? What do you enable? Think not just about nouns but also verbs


3. Brainstorm like crazy: the most naming fun I ever was with Persistence Software, where we had a nice dinner party with lots of wine, then each picked books, opened them to random pages and picked 4 company names from each page. The name Persistence came from a book of Yeats poems.


4. Make sure you have multiple viable names: just having a name doesn't mean you can own it. You still have trademarking and url-ing to go. Of the two, checking the trademark is easier (you can do it here http://www.uspto.gov/main/trademarks.htm)


5. Beg, borrow or buy the URL. Every imaginable url is taken at this point. At the end of the day, we had two names that would work. Of course there were squatters on both urls: one wanted $35K, one settled for $10K, but only after we got to the point where if we didn't get a deal that day, we would have just kept ActiveGrid


6. Spend for a good logo and color scheme. After all this work, you would be crazy not to get a good logo, color scheme and powerpoint template.


7. Change everything. Now the fun begins. Change your collateral, business cards, the lobby sign, the web site. Then take a long vacation.

As you might expect, there is some good stuff about naming on the web, by Guy Kawasaki, Dharmesh Shah and a post on where famous company names came from.

We won't know for some time whether all this work has paid off. But the day we re-launched WaveMaker with our new name we hit a whole new energy level in the business. Now we've just got to turn that energy into results!

Nobody ever got fired for choosing open source?

Last week, Wavemaker Software and BSG Alliance hosted a CIO panel titled, CIO survival guide for Web 2.0. The CIO panel included Jim Sutter, former CIO of Xerox, Lila Tretikov, CIO of SugarCRM, Max Rayner, CIO of TravelZoo, Steve Douty, President of BSG Applications and former CIO of Hotmail, Larry Singer, former CIO of the state of Georgia and Andrew Aitken, CEO of the Olliance Group.

Today, Matt Asay posted a great summary of the WaveMaker/BSG CIO panel on his CNet Open Road blog, under the title, Any CIO Not Using Open Source Should Be Fired. It used to be that the safe choice was going with the the big enterprise companies and their big ticket proprietary software. A killer combination of low upfront cost and speed of innovation in open source software is causing CIOs to feel like open source is becoming the safer bet.

I posted my own summary of the event on the WebGuild site under the much less flashy title of What CIOs Think About Web 2.0. The net of all this discussion is that CIOs are very open to the value that new technologies can bring in democratizing the development of web applications.

So far, the tools for web development have been primarily in the hands of expert programmers working in core IT. Web 2.0 offers the promise of bringing easier to use web development tools to the edge of the organization, enabling more innovation at the edge of the corporation.

To help make this happen, the CIO's job will be to provide core infrastructure that enables innovation at the edge while preventing unintended damage. WaveMaker's role in this market shift is to provide a development platform that enables visual assembly of web applications at the edge that comply with core IT standards for security, data and governance.

Ready to Make Waves

Although the computer industry is still young, we have already seen several waves of development tools. These waves follow technology and architecture trends: new technologies like the PC make new architectures possible, like client/server, which in turn require new tools, such as PowerBuilder.

Each wave of development has had a distinctly character - either logic-based or visually based. The tools to support each of these waves have been tailored correspondingly.

While the last 8 years have been dominated by thin-client architectures and code-based tools for expert users, the rich client technologies and collaborative user expectations behind Web 2.0 argue strongly that a new wave of development tools is beginning.

Here is my take on the four big development waves:

1. Green screen (1960-1990): centralized development with code-based Cobol tools


2. Client/server wave (1991-1997): departmental development with visual-based tools like PowerBuilder, Notes, Access, Oracle Forms.


3. Thin client wave (1998-2007): centralized development with code-based Java tools


4. Rich client wave (2008+): Web 2.0 democratizes development and dramatically opens up both the responsiveness and functionality of the client with an avalanche of Internet-based widgets and services. Can today's code-based tools targeting expert Java and C# developers ride this wave? History would say no.

It is hard to remember today - when all the development tools are code based - that all the client/server development tools were visually based. Ten years ago, visual tools like PowerBuilder and Notes dominated the development world. Now, the programming world has shrunk to just two code-based tools - Eclipse and Microsoft Studio.

We believe that the industry stands on the edge of a new wave of computing, driven by the Rich Internet Application architecture. Web applications are moving from static, limited html pages to much more responsive and powerful widgets and services.

The explosion of widgets and services available on the Internet is driving a demand among business users for more useful business applications. As thing client applications get more visual, coding tools like Eclipse and Microsoft's mis-named Visual Studio are increasingly awkward.

To underline this point, a recent customer was able to re-build an application in our visual tools using 98% less code than in .NET/Visual Studio. Note that it is important for visual tools to support coding for advanced services - we are not advocating code-free development, just code-lite development, particularly for visual web applications.

After nine months of hard work, we are ready to start making waves. Over the next month, we will be introducing a product that will launch the next wave of enterprise computing. Our vision is to be the Powerbuilder of Web 2.0.

To underline our commitment to this vision, we have changed the company name to WaveMaker. And that is exactly what we intend to do!

Why Dojo 1.0 Matters - Ajax Now Enterprise-Ready

You can't swing a dead cat at a Web 2.0 conference these days without hitting a dozen Rich Internet Application (RIA) toolkits. The Olliance Group recently identified 58 RIA products, many of them either proprietary or incompatible with the other 57 approaches.

Just to set the stage, here is my personal definition for a Rich Internet Application:

"Rich Internet Applications match the responsiveness of traditional desktop apps by minimizing web page refreshes. RIA taps into the collective power of the Internet to supply widgets and services for building web clients, like rss feeds, Google maps and Youtube. The goal of RIA is not merely to emulate a PC GUI in a browser (aka the Silverlight sell-out), but to deliver browser-based clients which far outperform PC GUIs in speed and functionality."

Ajax* is a particular architecture for building RIAs that is favored by open source libraries such as Dojo, Jquery, Ext and dozens of others. The perpetual flamewars between adherents of the various Ajax toolkits is a huge gift for the proprietary RIA products like Microsoft Silverlight and Adobe Flex.

Many Ajax toolkits seem more focused on posting esoteric animated graphics widgets to the Ajaxian web site than they are on meeting mundane but critical enterprise needs. To be fair, whizzy graphics are an important element of RIA's appeal. However there are more fundamental concerns to address before RIA can be considered enterprise-ready.

Into this maelstrom of splintered efforts comes the Dojo 1.0 release. Dojo has been in development for 3 years, making it one of the more mature toolkits available. Dojo also has the backing of IBM, BEA and Sun and will ship standard with their Java servers.

Previous versions of Dojo were criticized as being too big and too slow. Dojo 1.0 attempts to address those issues. Even more importantly, Dojo has also addressed a number of the hard issues required to gain enterprise adoption:

1. Internationalization and accessibility: Dojo supports localization, keyboard navigation and vision-impaired users, making it appropriate for both global businesses and government applications.


2. Excellent data handling: the Dojo grid (plug: built by ActiveGrid's own Scott Miles and Steve Orvell) easily handles 100,000+ rows with dynamic loading and complex rows, making it suitable for building the most data-intensive web clients.


3. Interoperability: Dojo supports the OpenAjax hub, making it possible for an enterprise to integrate and support web applications built with different Ajax toolkits.


4. Corporate look and feel: Dojo supports the ability to define a corporate look and feel or skin that can be used across a set of applications.

Although choice in general is good, no CIO wants to be stuck supporting a dozen squabbling Ajax toolkits a year from now. Dojo 1.0 may not be the ultimate winner, but it sets clear expectations for what an enterprise-ready Ajax toolkit should be able to do.

*Ajax is an acronym for Asynchronous Javascript And XML (only the acronym Self-Contained Underwater Breathing Aparatus can approach Ajax in shear implausibility).