As mentioned in my previous piece I’ve been doing some prototyping using SpringSource’s Grails. Grails can be thought of as the top of the stack. If you pick up Grails you would naturally pull in the other pieces of SpringSource, including vFabric and ultimately CloudFoundry. In a future post I will deal with what happens when you stick Grails onto CloudFoundry, but at this stage I’ve been assessing the health of the SpringSource Ecosystem.
Successful Open Source initiatives run a fine balancing act between Utopian ideals of open Source Purists, and the hard-nosed commercial realities of paying developers to write good code. For Enterprises to adopt Open Source technology they need to be convinced that it is of good quality and properly supported and maintained by Vendors who are on a sound commercial footing. However, the innovation is driven by Open Source purists who in many cases are working pro-bono. Some of them are in the process of defining a business model with a view to becoming rich in due course, and some of them are just giving something back to society, either in their own time or by agreement with their employers.
The combination of interests is described as an “Ecosystem”, and it is important that it is balanced. Too little investment by established vendors, too little stability and supportability in the finished product. Too much dominance by established vendors and entrepreneurs don’t see opportunities, people stop doing “pro-bono” work and innovation slows .
The first thing to note is that the consumer of Grails is dependent upon the health of a number of interlinked Ecosystems. Grails is built on Spring, Groovy, Hibernate and, of course, Java (specifically JEE), and is developed in Eclipse and deployed onto Tomcat, and some relational database or other (VMware is strategically devaluing databases as well as Operating Systems) . These ecosystems are of different sizes and levels of maturity and have different control by VMware. Governance of Spring, Groovy and Grails is still tightly-held by SpringSource (i.e. VMware). Tomcat is an Apache project with an open governance model and Hibernate is controlled by Red Hat. There are thus hidden dependencies between Open Source Projects at the Vendor level. At my last post I hadn’t realized that Hibernate was part of the framework.
The first question is “does it all work”? The answer to that is that it does seem to work surprisingly well.You write a domain model (think of this as a textual version of an entity-relationship diagram) and with a few button-presses something approximating a web application drops out. Furthermore there is an incremental change path from the auto-generated application to something a bit more user-friendly. It must be said that my prototype isn’t very far down that path, but I can see that it could get there.
Grails is built on a huge stack and the new-adopter (amongst which I count myself) does struggle to understand all of the context of all of the layers. In my case the main initial difficulty was a tendency to drop into Java. You can embed random bits of Java into Groovy and it usually works, but to get the benefit of the framework, it is better to work in Groovy, which is a loosely-typed language closer to javaScript than to any other language I’ve used. To get things to work properly it is also important to understand what is actually going on at the database level through the Hibernate layer, which is actually quite close to the surface of the abstraction provided by Grails. If you go with the grain of the framework, by-and-large there are only a few “wierdnesses” that are unexplained by ignorance, and require you to restart Tomcat or clean your Eclipse Workspace.
So far we have really been dealing with the quality of the software provided by SpringSource and Red Hat, not by the rest of the ecosystem, and here it gets interesting. The first area worth commenting on is the level of Documentation. An Ecosystem can be very good at enriching Open Source documentation both by posting formal structured documents and by asking/answering questions on newsgroups. As you go up the stack from Java through Hibernate, Spring, Tomcat and up to Groovy and Grails, the documentation gets noticeably thinner. Grails has quick-start and reference documentation from SpringSource which generally stops being useful as soon as you hit anything complex, but there is comprehensive tutorial documentation from another part of the Ecosystem, IBM. The level of newsgroup support for Grails is still quite limited, when searching for things you quite often end up back at the same posts you have already seen. Correspondingly, the Groovy layer is better documented, and Hibernate even better. I haven’t had to delve into the documentation of the other layers yet.
The second area of interest is plugins. In the previous article we mentioned Security plugins provided by SpringSource, but there are also free plugins provided by third parties from the Ecosystem. You would not necessarily expect these to be of as high quality as SpringSource’s own plugins, nor to be for core functionality, but they can enrich the framework very significantly. I looked at plugins to resolve the problem of keeping my entity-relationship diagram in sync with my code, and I found two ecosystem plugins that cna generate UML diagrams from Grails domain models. They both sort-of-worked, one worked really well. Documentation was limited, but it does seem that the Ecosystem is capable of (and motivated to) deliver useful function.
Finally, it’s worth noting the way that VMware is using its Springsource development tooling to market to developers. if you use the Eclipse development tooling provided by SpringSource (and everyone would), every time you start up a Spring/Groovy/grails project you get a “dashboard” with an RSS feed from SpringSource in the fetching green color-scheme, telling you about the latest tcServer seminar – how much cheaper it is than other application servers, announcing the availability of additional Eclipse plugin to put it onto CloudFoundry, offering training courses, pointing you at helpful videos about other SpringSource commercial offerings. They say “the hand that rocks the cradle is the hand that rules the world“, and for applications that are currently in their infancy, whilst VMware will let other members of the ecosystem help with the baby, it wants to make sure SpringSource has its hand on the cradle.