AJAX, Open Source, and Business Models

Had I but world enough and time . . . I would do an audio mashup of these two conversations. That is, assuming I couldn’t warp space and time and cause the two discussions to have occured together in the first place.

The first audio source would be this panel from the recent Usenix conference in Boston on Open Source Business Models – moderated by my colleague Stephen Walli. The panel was on June 1st, and included Brian Aker (MySQL), Miguel de Icaza (Novell/Ximian), and Mike Olsen (Oracle/SleepyCat), discussing various issues about building communities of users, benefits of different licensing models, software patents, and the challenges of good business execution, all in the context of open source. (Audio is at Stephe’s blog, comments also at Brian Aker’s)

The second audio source in my mash-up / remix would be two episodes of RedMonk Radio, Episode 12 Part 1 and Episode 12 Part 2. (These are both joint podcasts with the DrunkandRetired.com Podcast where they are episodes 53 and 54).

The focus of the second discussion (not a panel but a podcast conversation) was “The Business and Technology of AJAX,” and participants included Cote (RedMonk), Charles Lowell (The Front Side), and André Charland (eBusinessApplications).

The benefit of bringing them together would be to ask the Open Source panel about AJAX and to ask the AJAX panel about Open Source.

The “Business and Technology of AJAX” discussion covers what brings enterprises to AJAX – pointing out along the way that it may be the best current contender for “Magazine-Driven-Architecture” – and each of the companies describe in detail what particular piece of the overall AJAX puzzle they are focused on. They also cover some of the challenges of AJAX interoperability – given javascript’s limited (read: nonexistent) mechanisms for packages and componentization, developers need to “play well” together to enable the integration of multiple AJAX toolkits / frameworks.

What they don’t ever mention is why they’ve chosen proprietary licensing as a business model, or how they differentiate their offerings against the broad variety of open source AJAX frameworks.

In the “Open Source Business Models” panel, there was lots of good discussion about the pros and cons of various licensing models – including Miguel de Icaza’s assertion that if he were starting a new business now it would not be open source based. One of the intriguing suggestions from that panel would be the notion that subscription models may be the next major step for Open Source based business models where dual licensing isn’t an option.
The fact that AJAX code runs primarily in the client browser, in JavaScript, would seem to make real proprietary models difficult, though obviously one can separate the ability to view source from the right to use, modify, and redistribute it. But I have a hard time imagining subscribing to an AJAX library or framework, just as I have a hard time imagining purchasing an AJAX component.

But why? What is it about AJAX development in particular that makes it seem awkward to rely on a set of proprietary AJAX components?
Components or Libraries (for charting, graphing, data manipulation, etc) have been common (and commercial) in the .NET and J2EE worlds for a while now, and of course for C++ going back to well before my days as a developer.

I guess for me it comes down to the “view source” culture of web design on the client tier. Web developers have always “borrowed” css hacks, javascript snippets, and browser layout techniques from each other, because, for one thing, the browser has always made it so easy. Recently, the “view source” culture of web design has been evolving into a real “open source” culture with projects like Dojo, Prototype, script.aculo.us, MochiKit and others formalizing the rights to use and extend.

It may be that I’m underestimating the value a well-designed AJAX framework under a proprietary license can offer – but my gut still says these frameworks will ultimately evolve in the direction of either dual licensing (we’re free if you’re free) or open source plus paid support.


  1. You may very well be right. As your website declares “It’s early days yet.” So, for our part, we’re just keeping our cards close to our chest until we see the flop.

    We’ve considered many different licensing models, and we may very well go in any of the directions you propose. Ultimately though, the decision will be a pragmatic one. I.e. what’s the best way to put food on the table. It’s a difficult decision since most open source projects are spear-headed by people who are independently wealthy, or in the employ of an independently wealthy corporation. That’s not to say it can’t be done, but it is certainly a calculated risk for a group whose sole asset is a single product.

    Of course, as you said, there must be some differentiating factor between commercially available components/frameworks, and their open-source counterparts.

Comments are closed.