The Keene View on Web 2.0, Ajax and SaaS

For cloud computing to take off, there need to be tools available that enable a developer to build and deploy an application without having to download anything to their desktop. This requires an on-demand development tool that sits on top of the cloud and provides a development Platform as a Service (PaaS).

There are two paths that a vendor can take to create a development platform for cloud computing: cloud-first or tool-first.

• Cloud-first approach to PaaS: first build a cloud platform, then build a development tool that runs on top of it. This is the approach pioneered by Force.com and followed by Coghead and Bungee Labs.


• Tool-first approach to PaaS: first build a development platform that is host-able tool (e.g., studio runs in a browser), then "push" that platform into the cloud. This is the approach taken by WaveMaker.

For Force.com, it made a great deal of sense to take the cloud-first approach. SalesForce.com already had a robust cloud platform and expertise in building proprietary development tools to create their CRM application. There was also no requirement to make Force.com work on any other cloud, because SalesForce is aiming to be the only cloud you will ever need for all your enterprise apps.

For most software vendors, however, the cloud-first development process has distinct disadvantages. First of all, it puts you in the data center operations business, which requires a very different DNA than software development. Next, it makes development itself difficult, because the cloud adds a level of indirection and complexity to all development tasks. Finally, you will be forced to do cloud port eventually to get to a SaaS cloud people want to deploy on, like Amazon EC2 or Google App Engine (assuming they ever exit the Python ghetto).

A tool-first approach to PaaS development is much more straightforward. You start by creating a host-able development studio (pretty much rules out Eclipse plugins) and do your build and test on standard hardware. After you have build a solid product, you add multi-tenancy to the studio and customize deployment for your cloud of choice (or use a partner like Elastra to do the deployment and administration for you).

A final oddity of the cloud-first vendors is that they have all delivered proprietary development platforms. This provides a "roach motel" level of lock-in - your logic and data can checkin, but just try moving them to another RIA or Ajax platform! Again, SalesForce can throw its 500-pound gorilla weight around and make the Apex language successful. It is hard to imagine, however, that 5 years from now people who have learned the Coghead language will be in more demand than, say, Java developers.

Labels: Bungee Labs, Coghead, force.com, paas, platform as a service, WaveMaker

WaveMaker just released a new version of its open source development tool, available here, that includes out of the box support for the Postgres/EnterpriseDB database.

Before now, Postgres developers had very limited choices for building graphical front-ends to their databases. Tools like Navicat provide support for building client/server applications, however web application development requires complex hand-coding in PHP.

With this new release, WaveMaker is offering a visual development environment for Postgres that greatly reduces the amount of code required to build a rich internet application on top of Postgres. By eliminating much of the Web 2.0 learning curve, WaveMaker greatly increases the number of developers who can build Ajax applications.

This release also reaffirms WaveMaker's commitment to the EnterpriseDB Blade Program which is building a trusted ecosystem around the Postgres platform.

Labels: EnterpriseDB, Postgres, Rich Internet Application, WaveMaker, Web 2.0

McKinsey & Company published a report predicting the market size for Software as a Service (SaaS) will exceed $37B market over the next 5 years. In particular, the report described the need for Independent Software Vendors to SaaS-enable their products using special-purpose SaaS development tools. Matt Asay also wrote recently that the growth of the top 60 software companies is driven by SaaS.

McKinsey claims that traditional J2EE and .NET platforms are poorly suited to building SaaS applications. According to McKinsey, this opens up a $3B market for Platform as a Service (PaaS) products from new entrants like WaveMaker, Coghead and SalesForce. From the article:

Although SaaS development platforms like SalesForce and Coghead have gotten a lot of attention, this market has so far been remarkably closed and proprietary. The Platform as a Service leader, SalesForce, has both a draconian hosting policy (host your apps and data anywhere, as long as it’s with us!) but also a proprietary language (who needs Java when you’ve got Apex!?).

Moving forward, the same trends driving open source adoption everywhere else in the industry will ultimately drive SaaS adoption of open source, particularly by ISVs whose business plan does not include a low multiple sale to their proprietary hosting provider. Future SaaS platforms will converge with traditional tools, offering on-demand development based on traditional programming languages with built-in tools for mash-up based development for basic users.

Development Problems for SaaS

SaaS is highly disruptive for existing hardware and software providers. SaaS platforms are different from traditional computing platforms like J2EE and .NET in three ways:

• SaaS platforms contain new core components, such as web services APIs to integrate to other applications and usage-based billing capabilities. This disrupts existing platform providers like BEA and Microsoft.


• SaaS platforms are designed for multi-tenancy, including global and tenant-specific data schemas, multi-layer administration and virtualization for scalability. This disrupts traditional ISVs like Oracle and SAP.


• SaaS platform are delivered on-demand, not on premises. This threatens the business of traditional hardware providers like IBM and HP.


• SaaS products need on-demand customization tools. As SalesForce has demonstrated, a complete SaaS application needs its own customization tools if it is to compete with enterprise solutions like Siebel and SAP.


• SaaS products need on-demand integration capabilities. This includes ability to integrate with on-premises data (a notorious weakness of pure-cloud solutions like Force.com) as well as with on-premise and on-demand web services.

SaaS Architecture Requirements

McKinsey identified three elements of a SaaS architectures:

1. Development environment: an on-demand development platform for creating SaaS applications. This platform should be able to ship along with the application itself to allow customers to customize their application.


2. Run-time environment: an on-demand infrastructufre to deliver applications. This can be a proprietary hosting environment like SalesForce, or an open hosting environment like Amazon EC2. Ideally, the customer should be able to deploy applications on-demand or on premises depending on their security, data integration and other requirements.


3. Ecosystem for adding new capabilities to applications (e.g., SalesForce AppExchange). This ecosystem should also be able to access enterprise data and services located inside the enterprise firewall.

SaaS Is Make or Break for ISVs

According to McKinsey, SaaS has greatest impact on ISVs, delivering a 50-70% improvement in the level of features that can be delivered for a given investment in development and infrastructure.

For ISVs, SaaS platforms offer low upfront cost, rapid time to market (productive tools + pre-built components like billing) and high quality service delivery. In short, existing ISVs have a limited window to migrate their offerings to the SaaS platform or risk being obliterated by newcomers who get there first.

The lesson of SalesForce versus Siebel Systems is clear: existing ISVs should migrate their presentation layer to SaaS quickly while preserving their existing back end servers. Preserving existing back end logic requires a SaaS platform that supports traditional languages like Java.

Which Platform Will Win the ISV Business?

A battlefield is emerging between established mega-vendors and pure play SaaS vendors. The following factors will separate the winners from the losers in this market:

• Build a robust offering: cutting edge technology, reliable, high quality.
• Enable extensive customization: provide additional components that address SaaS-specific needs (e.g., authorization, billing, monitoring & management).
• Monetize effectively: McKinsey identifies this as the most important success factor. The winning platform vendor will be the one which most effectively creates economic value for its ecosystems!
• Drive ecosystem growth: enable partners to make money within the platform vendor’s community through collaboration, sharing of tools and best practices.

Although many of the early SaaS platforms are based on proprietary languages and tools, Gartner predicts that 90% of SaaS software will be based on open source within 2 years.

Evaluating SaaS Platforms For ISVs

Here are important criteria for ISVs to consider in evaluating SaaS platforms (sometimes called Platform as a Service, or PaaS):

• Open hosting: can I move applications I build to another SaaS hosting providers? Many SaaS platforms lock the ISV into a proprietary hosting provider (e.g., SalesForce). ZDNet says that ISVs need to offer their SaaS software both on demand and on premises.
  
• Full platform: does the SaaS platform offer a complete development solution with presentation layer, business logic, security, database and web services? Some SaaS platforms only offer part of the development stack (e.g., DabbleDB, Tibco GI)
  
• Standard language: does the SaaS platform support development using a standard language such as Java? Many SaaS platforms are based on proprietary languages (e.g., Apex, the proprietary language for SalesForce).

Table: A Comparison of PaaS Vendors

* Proprietary language

Peter Laird also has a good SaaS platform review and Phil Wainwright’s has a good comparison of PaaS providers.

SaaS Platform Product Review - WaveMaker

WaveMaker is an open source, visual development platform for building Web 2.0 applications. The WaveMaker studio can be installed on a developer workstsation or delivered on-demand. WaveMaker creates standard Java applications based on Spring, Hibernate and Dojo that can be deployed in a SaaS or on premise architecture.

For ISVs, WaveMaker offers several compelling benefits:

1. WaveMaker's visual studio provides a faster and more natural way to build rich internet applications than traditional hand-coding using Java and struts
   
2. WaveMaker is completely open, making it portable across hosting providers and even enabling applications to be deployed on premise
3. WaveMaker includes a complete development platform based on open source standards such as Spring, Hibernate and Dojo
4. WaveMaker is based on the Java language, making it an ideal choice for ISVs who already develop in Java and don't want to migrate their existing server code.
   

WaveMaker can be downloaded here.

Summary - What ISVs Need From SaaS

Every ten years there is a dramatic shift in the development tools world: in the 80’s to client/server, in the ‘90s to three tier and now in the 00’s to SaaS. In each of these shifts, the dominant development tools providers have been supplanted by a new generation. This time around, the seismic shift is being driven by the on-demand architecture and the ISVs have the most urgent need to rebuild their solutions to remain competitive.

Over the next five years, we will see the 500 pound gorillas of the development world like Microsoft’s ASP.NET and Sun’s J2EE unseated. In their place will be new software platforms based on traditional languages that are specially designed to enable development of SaaS applications.

Labels: paas, platform as a service, saas, salesforce, software as a service, WaveMaker

Lewis Cunningham, a database architect for EnterpriseDB, recently posted a review of WaveMaker Visual Ajax Studio that included an aha moment:

When I created my data model, it automatically turned that into a series of web services. This means that the data interface is completely separate from the logic to use that data, allowing data to be decoupled and changed at any time. You can build your UI without ever seeing your database.

Lewis has uncovered an important shift in development being driven by the Web 2.0 architecture: scaffolded development. Ruby on Rails originated the idea of scaffolding as a way to get a web application up and running quickly without having to connect all the back end pieces.

As the developer fills in the back end details for data and web service binding, the scaffolding goes away. Thus ushers in a whole new era of Web 2.0 rapid application development - in which business users can mock-up an application and iterate quickly on a user design, then hand off their prototype for IT to develop (with or without underlying dummy data).

Go ahead, download Wavemaker and get see where Web 2.0 and RAD are taking us!

Labels: EnterpriseDB, RAD, ruby on rails, WaveMaker, Web 2.0

Web 2.0 Expo was last week - 10,000 people attending a trade show for a market that doesn't exist anywhere but in our own minds. As is usual when we let our imaginations run wild, every one of those attendees was looking for something different.

For example, I was on a panel session entitled "Web 2.0 and the Breathing Enterprise" - it was a good session, but darned if I know what a breathing enterprise is, any more than I know what Enterprise 2.0 is.

After the second day, our team was thrilled because we had gotten over 200 leads and given almost 100 product demonstrations in two days. During that same time period, however, we had 4,000 WaveMaker downloads and over 100 new registrations to our WaveMaker community.

I'll take 100 people who have downloaded my product and used it enough to want to be part of my community over 100 tchotchke-seekers any day!

Labels: WaveMaker, Web 2.0 Expo

[This article is based on a talk by Scott Miles, WaveMaker architect and module owner for Dojo Grid, and Steve Orvell, WaveMaker engineer and core committer for Dojo, that they gave at the Visual Ajax User Group]

Ajax developers expect too little of their tools! Why do we put up with endless code/debug cycles with our favorite Ajax library just because there is no way to visualize a UI while you are developing it?

Imagine life without Firebug. Now estimate the amount of time you spend in Firebug just trying to figure out why a particular widget didn’t render the way you wanted it too. A WYSIWYG Ajax editor takes away a great deal of needless widget layout pain.

Just as importantly, a WYSIWYG Ajax editor provides a much easier on-ramp to learning Ajax programming, opening up a much larger market opportunity. Today, the perceived difficulty of learning Ajax can drive developers often choose proprietary solutions by default.Until it is easy to build Ajax user interfaces, the ability to build rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools.

Why Visualize Your UI?

Why do you want to visualize your UI while you are building it? As the client gets thicker, the interactions get more complex. As interactions get richer, the potential for wasting a lot of time coding grows. To torture a metaphor: in Ajax, a picture of your UI can save a thousand lines of code.

Alex Russell of Sitepen talked about saving ourselves from the unweb at the Visual Ajax User Group on the value of Semantic HTML for building Ajax apps. From our perspective, the semantic web may be coming, but it ain’t here yet (look here for more on the open web). In particular, HTML parsing and rendering can be slow. While other visual design tools may take different paths, the particular approach that WaveMaker chose was to use JSON (Javascript Object Notation) instead HTML/XML.

How a WYSYWYG Ajax editor works

A WYSYWYG Ajax editor is meant to make Ajax widget layout easy, without hamstringing the developer. The general things that any visual Ajax editor needs to be able to do include:

1. Ajax page designer: the page designer includes palettes of widgets, a WYSIWYS page editor, and property inspectors to change widget properties.


2. Drag and drop: developers can move widgets from the palette onto the page designer.


3. Visual feedback loop: developers can see how their page will look and change widgets on the fly to see the effect on the design (e.g., sizing, positioning).


4. Generate Ajax code: the Ajax editor generates the appropriate css, html and JavaScript to implement the design at runtime.


5. Import/export widgets: there is a straightforward way to create new widgets and import them into the Ajax editor to create a robust ecosystem of 3rd party widgets.

Rules for making WYSYWYG-able Widgets

Ideally, a WYSYWYG editor should be widget agnostic – it should be able to support several different Ajax widget libraries. More importantly, people who build widgets should design the widgets up front for visual tool-ability. Good widget design can reduce or even eliminate the back-end coding needed to bring a widget into a visual Ajax tool.

WaveMaker is a visual Ajax designer that can host a variety of toolkits and widgets. Our experience developing WaveMaker has enabled us to crystallize seven widget design principles that simplify the task of hosting the widgets in a visual design tool:

• Portability is critical: no matter how good a tool is, developers need the flexibility to switch tools. If the output of a WYSIWYG Ajax editor can’t be edited in vi, then the proprietary lock-in may outweigh the tool’s short-term benefits. Similarly, a widget that introduces its own markup language will require its own proprietary tools (think Silverlight).


• Performance counts: an Ajax editor needs to produce Ajax apps that have acceptable load times and responsiveness, making it easy, for example, to produce minified JavaScript.


• Well defined dependencies: make it easy for the tool to discover and incorporate images, css and other libraries required by a widget.


• Limit create only functionality: a WYSIWYG tool need to be able to change properties like sizing and positioning dynamically, not just at the time of widget creation. Having to recreate the object every time a property changes is inefficient.


• Straightforward APIs: widgets should follow an API naming convention (e.g., for getting and setting attributes) that simplifies exposing properties through a visual tool.


• Automatic re-rendering: Widgets should also be responsible for updating their visual representation when their properties change. One good way to do this is via property setter methods.


• Make it easy to expose events: a naming convention where all event methods start with onFoo makes it easier for a tool to be smart about what events a widget can respond to and then expose them in a straightforward way.

A good example of a WYSYWYG-able Widget is FCKEdit. This is a heavy-weight widget that is completely self-contained and comes with an Ajax-friendly JavaScript integration technique. On the other hand, FCKEditor does not expose resizing hooks (we had to figure that part out on our own).

Dojo Dijits contains a whole library of WYSYWYG-able Widgets. A visual Ajax tool like Wavemaker can easily wrap Dojo widgets with Javascript “meta-data” descriptors that allows the studio to create generalized property editors. The same process can be used to make other Ajax widget libraries available within studio, such as Google Gadgets and Ext.

Tooling the Dojo grid

The trick in tooling a complex widget is to determine what behaviors to tool. The goal is to provide the right subset of features through the tool without preventing the developer from going in afterwards and creating what they need.

For example, the Dojo grid is tremendously capable. Not all these capabilities are accessible through WaveMaker, such as fixed columns, combined cells and subrows. Think about all the things you can do with Excel and how long it took for Excel to get it’s grid tooling right. In the same way, WaveMaker is exposing a subset of Dojo grid features today, and will increase the richness of those capabilities over time.

Options for representing the Dojo grid data included raw javascript, table markup and json.

An equally difficult challenge is deciding what code to generate to implement a given Dojo grid definition. In general, there are three options:

1. Semantic HTML: generate HTML that includes rich Dojo grid semantics


2. Raw Javascript: chuck HTML and define the grid in Javascript


3. JSON: uses an object notation instead of semantic HTML to speed parsing

The following three sections give examples of these different approaches

Semantic HTML Markup definition for a Dojo grid

The following example comes from the Dojo Nightly builds grid tests. It shows a way to use “enriched” HTML to define a Dojo Grid (a la Alex Russell). The really cool thing is that this code runs even if JavaScrip is turned off in the browser.

If you already know how to code html tables, this is an elegant approach. However, its elegance and readability is offset by the performance hit the application takes in parsing the HTML.

<table dojoType="dojox.grid.Grid"
 store="csvStore"
 query="{ Title: '*' }"
 clientSort="true"
 style="width: 800px; height: 300px;">
 <thead>
  <tr>
   <th width="300px" field="Title">Title</th>
   <th width="5em">Year</th>
  </tr>
  <tr>
   <th colspan="2">Producer</th>
  </tr>
 </thead>
</table>

Raw Javascript definition for a Dojo grid

The following example shows setting up a Dojo grid using raw JavaScript. Although JavaScript is powerful and expressive, this essentially junks sSemantic HTML concept in favor of just getting ‘er done. is, however, confusing and difficult to read.

<script type="text/javascript">
// a grid view is a group of columns
var view1 = {
 cells: [[
  {name: 'Column 0'},  {name: 'Column 1', width: "150px"},
 ],[
  {name: 'Column 8', field: 3, colSpan: 2}
 ]]
};
</script>

Json definition for a Dojo grid:

Json (JavaScript Object Notation) represents a third way to represent grids. To see this in action, look at the widget source tab in the WaveMaker page designer. The main benefit is that it is readable and plugs easily into a visual Ajax tool JSON provides a highly readable, name/value pair approach to defining widget parameters. Best of all, it provides a format for widgets that parses and renders quickly and enables easy data interchange between the visual studio, the browser and the application server.

dataGrid1: ["turbo.DataGrid", {}, {}, {
 column: ["turbo.DataGridColumn",
  {caption: "Name", columnWidth: "50px"}, {},
 column1: ["turbo.DataGridColumn",
  {caption: "Addr", columnWidth: "100px", index: 1}, {},
}]

Summary

Until there are visual tools that simplify the task of building Ajax user interfaces, the ability to create rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools. WaveMaker is an example of an open source development platform that includes a WYSIWYG Ajax editor. Try it out and let us know what you think at http://www.wavemaker.com/downloads

Labels: AJAX, DOJO, JSON, Visual Ajax, WaveMaker, WYSIWYG

Web 2.0 apps look all shiny and bright, but we all know what horrors lurk within the typical enterprise IT shop. Web 2.0 will not be able to transform the enterprise until it can deal with real world integration nightmares like CICS systems, flat files accessed through obscure SNA protocols and AS/400s programmed in RPG.

Who is going to tame all this real world IT stuff and bring it into the bright shiny Web 2.0 world? SnapLogic and WaveMaker, that's who!

WaveMaker and SnapLogic announced today a partnership to use SnapLogic's Really Simple Integration platform to wrap any legacy data source as a web service. Once SnapLogic has "tamed the beast", WaveMaker provides a point and click, WYSIWYG development platform to expose legacy systems via rich internet applications.

Although we are performing very different tasks, both SnapLogic and WaveMaker are getting incredible value from creating web service-based products. SnapLogic wraps any data source as a web service, while WaveMaker assembles applications from any collection of web services. Chris Marino of SnapLogic also blogged about our partnership.

The following marketecture diagram shows the power of this approach. Rather than a rat's nest of one-off adapters, replicated data and custom data conversions, there is one clean API to the data - web services - and one simple tool for exposing the web services - WaveMaker!
To demonstrate the power of the rich and thin approach to web 2.0, WaveMaker and SnapLogic will be demonstrating an application at Web 2.0 Expo this week that integrates mainframe, minicomputer and relational data into a simple inventory tracking and re-ordering sytem. Stop by our booths and check it out!

Labels: CICS, Snaplogic, WaveMaker, Web 2.0

A year ago, I bought a Dell desktop running Windows Vista. Last week, I finally got it working…mostly.*

This week, we are releasing WaveMaker for the Mac (OS 10.5 Leopard to be specific) and Safari. Although the Mac is a visual platform, it has always been behind on WYSIWYG development tools. With Wavemaker, the Mac is leaping back in front.

The WaveMaker Visual Ajax Studio download for the mac is at http://www.wavemaker.com/downloads or just click here.

After many years of languishing in the education and design ghettos, Mac has once again become the defacto standard of leading edge techies. I attended an open source CEO conference recently where I was the only PC user at a breakout session of 10 people.

Our press release included a spiffy quote from Jean-Louis Gassé, General Partner at Allegis Capital and ex-Apple executive: "WaveMaker's Visual Ajax Studio for Mac comes at a very opportune time. Apple is gaining momentum in the Enterprise and WaveMaker gives enterprise users an easy and visual way to build Web applications."

Mac developers had their moment, back there in the days of Hypercard and Filemaker pro. Now the Mac platform is becoming a defacto standard for developers once again.

Here are some of the key reasons the entire silicon valley seems to be moving to the Mac:

1. Ajax platform of choice: Safari is lightning fast and leads the pack in standards-compliance. I can't remember the last time I saw any web app demoed on Internet Explorer, and if Firebug* ever gets ported to Safari, Firefox will be in trouble.
2. Video platform of choice: we just went through a 3 week death-march to create a new screencast for WaveMaker. Of that time, about 8 hours was spent creating content - the rest of the time was spent wrestling with the brain-dead video software we were using on the PC (Camtasia). In contrast, my 12 year old niece just created a 30 minute class presentation using i-movie. Enough said.
3. The Incredible shrinking desktop: with more and more compelling web applications, I find myself spending less and less time working within my Windows desktop.
4. The disaster that is Vista: given that I have to relearn the whole user interface to move from XP to Vista, I might as well relearn an interface that actually makes sense.
5. That cool backlit logo on the Mac laptop: let's face it - the knowledge that you will look good in a coffee shop probably sells more laptops these days than Ghz or RAM stats.
   

When I was in college I saw Steve Jobs demo the Apple Lisa in front of about 30 of us Stanford Comp Sci nerds. It is still to this day the best demo I have ever seen, despite the fact that the Lisa flamed out famously. I know that Macs will never take over the world, but it's sure nice to see them back in the race.

Then there's also the part about it just plain works! Which brings us back full circle to my Dell/Vista saga: after spending dozens of hours, many hundreds of dollars on utilities that didn't work, and a spectacular lack of help from Dell (the answer ended up being on an Intel site, having to do with the Intel Matrix storage manager, not that you really wanted to know).

Interested readers may also want to check out another good blog post on why PC developers are moving to the Mac.

*corrected - original post confusingly said Firefox, causing a great deal of what passes for glee among the trolls ;-)

Labels: AJAX, development, Macintosh, RAD, WaveMaker

The Meteoric Theory of Applications (to paraphrase Mary Loomis) is this:

Applications are like meteorites - they never migrate, they just land and stick.

With all the excitement over rich internet applications and Web 2.0, there is much talk of a vast migration of applications from client/server to the web (Judith Hurwitz describes when not to salvage legacy applications). While this will undoubtedly happen, it misses a much more important IT skills migration.

The real power of Web 2.0 lies not in modernizing legacy client/server applications, but in modernizing the skill sets of client/server developers. If an app was built in VB or MS Access and it works, leave it there. The real question is what to do with the developer who built that app?

Developers with 10+ years of experience with client/server tools have no clear way to "upskill" to building Web 2.0 apps. Consider the skills that a typical Visual Basic/Visual Studio developer would need to learn to start building an Ajax application:

• New database: MySQL
• New server language: Java
• New application server: Spring ($26.39)
• New database access framework: Hibernate
• New client/server messaging layer: Json
• New client language: Javascript
• New client toolkit: Dojo
• New styling language: css
• New IDE: eclipse

No wonder there is such a shortage of Java web developers!

WaveMaker is focusing on the skills migration - how to enable non-expert developers to build Ajax applications by using visual tools (for a good review of WaveMaker as an alternative to VB, see Java at the eye of a perfect storm).

Last week, WaveMaker hit 1,000 downloads a day - seems like we hit a nerve!

Labels: AJAX, WaveMaker, Web 2.0

Our engineering team just released version 3.1 of WaveMaker with lots of new goodies, including auto-forms (generate insert and update forms automatically from a database schema) custom widgets (use any Dojo widget, roll your own widget) and application templates (with custom look and feel).

We are also gaining converts to the WaveMaker motto: Make Waves, Not Code!

WaveMaker is an open-source framework for making Java web development quick and easy (kinda like a visual RoR for Java).

Peter Svensson just posted review of WaveMaker that stated:

The WaveMaker IDE has a number of very good features, listed in no particular order;

1. It is Web-based


2. It runs on its own Tomcat-server with a massive supporting act (the download is ~90MB!)


3. It's fully open-source under the GPL.


4. It uses Dojo 1.0 components, so you create your page(s) visually.


5. Complex components like Tree or (above mentioned) Grid can be connected to services on the server


6. You can create services inside the IDE; WSDL, Database Queries or custom Java code.


7. It generates generic WAR archives, for crying out loud!

Peter has also given us a good deal of constructive feedback on how to make Wavemaker even better. WaveMaker is democratizing Java web development, one Swedish blogger at a time ;-)

Our 3.1 release has also been picked up by Ajaxian, eBiz, AjaxWorld and TechFunk.

Labels: DOJO, Java FX, Peter Svensson, WaveMaker, WSDL

With the success of companies like MySQL, JBoss, Cygnus and SleepyCat, open source software has introduced major changes to the way corporate IT adopts new technology. Yet open source business practices have a long way to go before the industry as a whole is fully embraced by CIOs.
At the Open Source Think Tank, a panel of ten CIOs declared that the patchwork quilt of licenses and business practices among open-source vendors is a major barrier to enterprise adoption of open source. CIOS believe that vendor standardization on a simple and commercially attractive business model will help drive broad corporate acceptance of open source software.

After attending the Open Source Think Tank held in February, 2008 at the Silverado resort, I am convinced that a best-practices model is emerging for enterprise open-source software vendors. In honor of the think tank event, I am dubbing these practices the Silverado Rules for Open Source Success:

Open-source vendors should adopt the following best practices to optimize community participation while developing a viable commercial business:
1. Fix the last mile problem
2. Optimize for community and commercial growth
3. Play by the community rules
4. Implement role-based pricing
5. Enable on-site and on-demand deployment
6. Adopt a dual license strategy based on GPL + Commercial License
Following these rules may not lead to guaranteed business success, but ignoring them may well lead to failure!

Please feel free to enter comments and criticisms on my blog.

Fix the "last mile" problem

Open Source Software (OSS) communities are outstanding at solving hard framework problems, but not so good at producing user-friendly solutions. Once the community has solved the hard problem, it tends to lose interest in solving more mundane problems like documentation, management and monitoring.

CIOs need open-source vendors to be more like commercial vendors in "putting a bow on the package. Corporate users are looking for open source products to have commercial-grade documentation, usability, installation and support.

Optimize for commercial and community growth

The first generation of open source companies were project-driven. Companies like MySQL, JBoss and SleepyCat created large communities and then struggled to evolve business models that commercialized that community. Often, they faced significant resistance from early community members, particularly on introducing more restrictive licenses that forced users to pay for things they had previously gotten for free.

The newer, second generation of open source companies is following the opposite process. Venture-backed companies like Alfresco, Mindtouch and Wavemaker started with a commercial focus and are now working to create vibrant communities.

These second generation OSS companies have a completely different set of challenges than the first generation. They have much more control over intellectual property and choice of licensing, but much more work to do on the community-building side.

Open source companies should see themselves as part of a larger supply chain, determine how to add upstream and downstream value. At WaveMaker, we are a major consumer of open source - our product is based on Spring, Hibernate, Json, Dojo.

We get value from their communities and in turn we add value to their communities by providing an open source framework for visual AJAX web development. Our goal is to broaden the overall size of all of our communities by democratizing the development web applications - essentially an open-source version of Visual Basic.

Play by the community rules

Communities are the life-blood of open source companies. Yet the process of creating a community is still more of a black art than science. Experts in community have developed a simple set of three rules for building successful community:

1. Set the rules early: spell out the role of the community in developing, extending and supporting the product. For example, define the ideal participants of the community, and the benefits they would expect to receive to entice them into membership in the community.
2. Play by the rules: once companies set the rules for the community, they should enforce those rules scrupulously, through active community management. Hell hath no fury like an open-source community member scorned!
3. Don't change the rules: as the business of the company evolves, there will be pressure to change how the community operates. For example, companies may decide that they want to take more support business from the community. Not a good idea - see rule #2!

Community experts also agree that the most important community building task is to create heroes within the community. The most effective way to do this is through dedicated community managers who go through a lengthy process to nurture and reward active community members.

Implement role-based pricing

I have written before that David Skok feels the success of JBoss lay in their ability to give developers a free product while charging commercial IT operations for support and management tools. CEOs of open-source enterprise software companies believe that a key element of any enterprise open-source company is realizing that there are no scalable dollars in selling to developers.

The role-based pricing approach can be summarized as follows:

• Developer use open source tools for free: making a product free for developers creates a "frictionless" entry path for new technology into an organization. Small scale, "under the desktop" deployments are also free, making it easy for IT architects to prove out a technology with small pilot projects. Developers should be able to use all the development capabilities of the product without restrictions (everyone hates crippleware!)


• Administrators pay for commercial support: when a project built with an open source tool is deployed into a business-critical environment, operations people will require commercial-grade support, including updates, patches and upgrades. Operations roles will also value management and monitoring capabilities that enhance the security, reliability and performance of the deployed application.

It is important to point out that role-based pricing does not mean charging administrators for the same thing that developers get for free. It means identifying services and functionality that are of particular value to administrators and charging for those add-ons.

The revenue opportunities in enterprise open source lie in selling support and value-added functionality for operations and production. Free development tools are the on-ramp to production revenue. This also ties the vendor's success to the successful deployment of the customer - the ultimate win-win for enterprise software.

Enable on-site and on-demand deployment

Moving forward, it is likely that the open source world will continue to migrate towards on-demand offerings, even for enterprise development platforms. Software as a service (SaaS) pricing is easier for business applications like Sugar CRM, but it will increasingly make sense for infrastructure software as well.

There are three drivers for this movement:

1. Low start-up cost for customer: with nothing to deploy on site, customer adoption is as easy as creating an online login.


2. Higher rate of conversion to paying customers: for vendors, SaaS customers often convert more quickly paying customers, a big improvement over the single digit conversion rates more common to traditional open-source communities.


3. Business model fit: subscription payments for on-demand services fit naturally with the existing open-source subscription licensing model.

Enterprise development software has traditionally been delivered on site. In the future, it is very likely that corporations will at a minimum want an option to deploy applications on-site or on demand (a feature already supported by WaveMaker Software, among others).

Adopt a dual license strategy

Over the last ten years, the open-source community has matured greatly. Although the GPL remains the most popular open source license (~70% of open source projects use GPL, according to Freshmeat), the most commonly used version was released in 1991. Much has changed since then, and to reflect these changes, the new Gnu Public License (GPL) v3 offers- among other things - greater compatibility with the Apache license while ensuring that open source contributors receive public acknowledgement for their contributions.

There are a number of other popular open source licenses, each with its strengths and drawbacks. For example, Apache allows big companies to "expropriate" the work of smaller open-source companies without even acknowledging that contribution, making many open-source startups are leary of adopting the Apache license.

In addition, traditional licenses like GPL v2 and Apache do not provide explicitly for SaaS distribution. To get SaaS companies to participate in the open source movement, the best solution today is to adopt the newer GPL v3 license with the Affero extension for SaaS usage.

The combination of GPL v3 with the Affero extension is new, but seems to have momentum. I spoke with a dozen CEOs at the Open Source Think Tank conference who indicated that they would be adopting this license over the next year.

WaveMaker Case Study

WaveMaker is an open-source framework for visual AJAX web development. WaveMaker uses drag and drop assembly to create database-driven web applications. WaveMaker applications are pure Java WAR files based on standard open-source components, including Spring, Hibernate, JSON and Dojo.

WaveMaker Software has adopted a dual-license model: open source users are free to use the GPL license; while commercial users who want support can use the subscription-based license. This allows WaveMaker faces to build a vibrant open-source community while simultaneously establishing a viable commercial business.

The WaveMaker download is available here.

Summary

For new open-source companies who do not have an existing user community, there is a great deal of flexibility in setting up the licensing model. For these companies, a dual license model along the lines pioneered by companies like MySQL, JBoss and SleepyCat is emerging as the standard business model.

I take full responsibility for any bad ideas in this document, but I also want to acknowledge the contributions of the following people who helped me evolve my thinking: Larry Augustin, Brian Gentile of Jaspersoft, Clint Oram of SugarCRM, Neelan Choksi of SpringSource and Raven Zachary of the 451 Group

Labels: affero, gplv3, olliance, open source, WaveMaker

With all the excitement around Java alternatives like Rails, a much more important and less commented upon migration has been occurring

For ten years, the ponderous J2EE standard has made the lives of Java programmers everywhere miserable. While various Java standards committees considered gravely what to do next, corporations have been steadily moving to .NET.

In our market research for WaveMaker, we have found that a over 30% of the corporate IT market has moved from Java to .NET. As with many other Microsoft technologies (SQL Server comes to mind), Microsoft has gone from having a laughable solution to getting the last laugh.

We have also found a surprising number of Java developers who tell us that the complexity of J2EE and the difficulty of finding experienced Java developers is forcing them to embrace .NET despite their loathing of all things Microsoft.

Spring and WaveMaker are two companies addressing the core problems underlying this market shift. Spring is the application server that J2EE should have been – lightweight and powerful. WaveMaker is the visual development platform J2EE never had.

Together, Spring and WaveMaker offer a compelling and highly productive alternative to .NET.

How compelling? One of our Fortune 500 customers built the same application (57 web pages, 28 database tables) in both .NET and WaveMaker. The app built with WaveMaker was completed with one third the man-hours and 98% less code (more on this in a later post).

The conclusion is stark - either the Java and open source community needs to put good productivity solutions in the hands of corporate customers, or the data center will go the way of the desktop.

Labels: j2ee, ruby on rails, spring, WaveMaker

Ben Worthen of the WSJ recently posted an entry about Web 2.0 adoption. He sited a Forrester survey that concluded Enterprise Web 2.0 solutions would gain broad adoption in 2008 despite clear CIO resistance to the siren call of blogs and wikis.

As a strong proponent of Web 2.0 in the enterprise, we at WaveMaker want very much to see a rapid adoption of these technologies at the corporate level. On the other hand, wishing won't make it so - the grab-bag of technologies and ideas that constitute Web 2.0 are bound to confuse the IT community.

There are two possible observations here:

1. Damn the data, full speed ahead. Just like drug companies that sink a great deal of money into disappointing clinical trials that they then attempt to spin into medical break-throughs, analyst firms like Forrester won’t sell many copies of a Web 2.0 report that concludes Web 2.0 ain’t happening in the enterprise anytime soon. Thus there is a strong incentive for the report authors to refute their own data in the survey summary.
2. Web 2.0 is being pulled into the enterprise, not pushed. Since the PC, all client-side technologies have been pulled into the enterprise by business users, not pushed into the enterprise by central IT. The main themes of Web 2.0 – rich interface, collaboration and user-driven content – have more to do with how users interact with their computers than with computer infrastructure.

At my WebGuild panel this week, Rod Johnson of SpringSource observed that open source technologies like Spring and WaveMaker build unstoppable momentum within the IT organization by solving fundamental problems that much bigger players either cannot or will not solve.

For Spring, the tailwind came the intractable complexity of the EJB standard that left developers desperate for a simpler, more lightweight java application server. For WaveMaker, the tailwind comes from the complete dearth of visual tools for web development that would enable MS Access, Lotus Notes and PowerBuilder developers to come out of the client/server dark ages and build the kinds of web-based applications that their end users want.

Labels: access, powerbuilder, spring, WaveMaker

I wrote earlier about the kinder, gentler open source CEO. Now we are seeing that nice guys like MySQL's CEO Marten Mickos can finish first. The Sun acquisition of MySQL (also here in the WSJ)is not just an endorsement of the open source business model, it is also an endorsement of the MySQL culture.

I first got to know Marten several years ago when we were both trying to pull a soured business relationship between MySQL and a former business partner out of the ditch. That salvage effort proved unsuccessful, but I was struck by Marten's maturity and ethics, two character traits not always common among Silicon Valley CEOs.

In Jonathan Schwartz' announcement of the Sun acquisition in his blog, he adopted (no doubt unintentionally) the Stanford motto "die Luft der Freiheit weht" (the winds of freedom blow). The freedom offered by MySQL extends well beyond their database to the vibrant add-on community that surrounds MySQL.

As my wife likes to say when she reads about yet another messed up tech company (not infrequently one run by her husband), "the fish rots from the head down." The converse of course is also true. Companies run by people with a clear vision can see that vision reach far beyond the boundaries of their organization.

Sun can greatly accelerate MySQL's push into the enterprise. This of course is good news for WaveMaker, as we are already partnering with MySQL to provide a visual development platform for enterprise developers to replace their existing client/server tools, be they Oracle Forms, Lotus Notes, PowerBuilder or MS Access.

Labels: marten mickos, mysql, sun, WaveMaker

We launched our new WaveMaker product last week in Boston. At its worst, a product launch tour can be a mind-numbing exercise in navigating the Mass turnpike while regurgitating at regular intervals an adjective-laden product pitch to barely conscious industry pooh-bahs. These soporific meetings are puncuated with frequent stops at Dunkin' Donuts (apparently the only chain allowed in suburban Massachusetts) for undercooked donuts and overcooked coffee.

Our tour last week wasn’t like that. Mostly because our story is simple – building web apps is too hard – and our solution is equally simple – a visual development tool that generates pure Java apps that run in any Java platform.

The best meeting of the week was with Judith Hurwitz, who wrote a great blog posting on our product launch, asking Is WaveMaker the Web 2.0 version of Powerbuilder? How often does a seasoned analyst describe a company meeting as fun!? Judith said:

Some meetings are just fun (I can’t always say that..sometimes I just want to run away and hide under my desk). But my meeting today with WaveMaker reminded me of the type of meetings I had in the .com days. I admit I was excited about what I heard.

I also had an interview with Jason Meserve of Network World on the launch of the WaveMaker product. This 15 minute podcast gives a good overview of our strategy and you can listen to it here. Finally, Paul Krill of InfoWorld had a good product write-up here.

Labels: Judith Hurwitz, powerbuilder, WaveMaker

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.
  

Labels: jboss, open source, WaveMaker

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.

Labels: BSG Alliance, Enterprise Web 2.0, WaveMaker

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!

Labels: Eclipse, powerbuilder, RIA, WaveMaker