A holistic view on webapp development
As our internal debate on the definitive (there's simply too many software zebra's around already) name for Zebra continues, its tagline is subject of less discussion: Zebra aims to achieve a "holistic view on web application development". Below, I'd like to contextualize this statement.
But before, let me digress towards the background behind Zebra, its "raison d'être" so to say. Zebra is the result of years of frustration. There, I've said it. :-)
Historically, we always had two lines of business at Outerthought. Beside Daisy and related services, part of our turnover is also based on "mentoring" services: guidance and advise for software teams. The teams we had the pleasure to work with in the past years were active in the field of business software, rather than building web applications. Furthermore, the kind of software they were developing always fitted in a larger plan: a service framework that allows for intercommunication between disjoint software blocks, a datastore hidden behind a service-based access facade, messaging-based integration for asynchronous updating - you get the picture. The web facade of all this was important, but not the focal point nor even the commercial make-or-break feature. The main value of such applications was in shepherding business-critical datasets rather than in whiz-bang (web) GUIs. For fat client application development, Swing RCP was our framework of choice, even though it was clear that -as a project- it wasn't the one that lived top of mind. But it did the job, we made it into committership, and all-in-all, it was something we could safely recommend to our customers.
With a maturing web UI runtime environment however (i.e. browsers behaving less erratical than they used to), and the ease of distribution/deployment that comes naturally with the web environment, our choice of web toolkits became a critical point of concern.
Apache Cocoon had been our first "webappdev" framework of choice, one amongst the many others in the Java ecosphere. While conceptually sound for publishing-oriented web applications, and even though we contributed the now standard forms framework ourselves, its complexity and consequently diminished productivity was proving to become a burden, both in Daisy's development as in mentoring projects with customers. Cocoon is riddled with choices and alternatives, and it requires a lot of knowledge and skill to make those correct choices. For us, that wasn't necessarily a problem, since we were one of those Cocoon powerhouses anyways, but as new colleagues joined, it became clear turning the right knobs to leverage Cocoon efficiently was harder than it should be.
Adding onto that, in our Daisy line of business, we became increasingly involved with the archetypal web development project flow. It is then and there when we figured out that - of all the Java webappdev frameworks out there - very few if any had a truly holistic view on the entire process, and that, if we would want to achieve better productivity, we would have to come up with something better.
One of the main problems we saw was the scoping of the many webappdev frameworks out there. Looking at the truly popular ones, we saw that the ones that resided at the lowest levels became the frameworks of choice for - how shall I say this - business software development teams. The less opinionated ones, the ones with the fewest code and conventions to abide, the ones with the least choices being made for its users. Think Struts and friends.
Besides those, there also was a set of industry-governed ones, like JSF and friends, which heavenly depended on editor and tooling support. Those were however less in use at software development companies, and more inside organisations which made software as a necessity rather than as a means of living - think banks, government, institutions.
Finally, one had the "frameworks du jour", fast-moving targets which oftentimes don't excel in degree of documentedness, in API and code stability, and which - apart from the singular sweet point or golden concept that they were built upon - often fell apart when being used by so-called lesser gods, or rather John and Jane Doe the business developer: the people who churn out great software, but who simply don't want to keep track of 15 different mailing lists, websites and blogs, assembling required knowledge for a tool which fluidly transforms itself from useful to brainfart under the touch of their trembling fingers.
Add the typical webappdev process to that mix, and you had a recipe for disaster: consultants or analysts working on wireframes, domain experts on the model, designers on the look and feel - a hardship case for any framework that had a Grand Technological vision, that explored clever ideas, yet was only useful by that 10% of IT people who were prepared to devote all their waking hours to it. And then some.
So that is where we were: lots of experience in the field, knowledge about many frameworks, but unsatisfied with most of them, and some pet peeve that a framework should provide strong guidance to help the lesser gods, however also should grasp the larger picture: that of larger teams collaborating on a single application, of larger applications rather than one-off websites, but at the same time also of the facilitation of the process rather than only technology-assisted brain acrobacy.
Enter Zebra, or rather our idea of holistic webapp development. Once it's there, Zebra should allow a team of people to collaborate on larger-scale web application or web-enabled software products. It will provide a working environment for both the software developer, the front-end UI engineer and the graphical designer as well as the information architect working on wireframes and navigational structure.
We don't intend to write all of Zebra from scratch, but rather re-use and integrate where possible. Especially on the browser side, there should be opportunities for re-use. On the serverside, we have opted for a strong resource-based design, or ReST-style of web development. At the same time, we would like to redo what always has been the best part of Cocoon: XML pipelines to render resource representations.
Adding these concepts and techniques into a solidly designed and reasonably "finished" framework will be our challenge for the coming six months, with four engineers working on it full-time. We'll obviously regularly report here from what will prove to be exiting times. And yes, Zebra, or whatever the resulting product will be called, will be provided under the same liberal, commercial-friendly and no-strings-attached open source license as Daisy.
Kudos to Schaubroeck for -again- being exceptionally clueful about the economics of open source, and providing us with funds and engineers to make this joint dream happen.