Wednesday, July 28, 2010

Day to be acquired by Adobe - implications?

Today, Adobe announced to buy Day Software, another WCM manufacturer based in Basel, Switzerland, who uses the same technology foundation as Magnolia. As an initiator of the JCR standard and main contributor to Jackrabbit (the JCR reference implementation), Day is certainly important for the JCR ecosystem.

Let's have a look at the possible implications of the deal for Magnolia.

Adobe bought Omniture not even a year ago for 1.2B$, which was/is the leader in web analytics. With Day's CQ (their CMS), Adobe now has the final part in their portfolio to create, analyze and publish content. (I couldn't find out yet what part "Adobe Publish" plays. Seems to be an SaaS platform, so probably not competing with CQ.)

With Adobe, Day can now enter the US market, something that was difficult until now (even if they are no longer Day). Adobe buying Day further validates the JSR-170 standard, makes Magnolia's technology stack better known and more attractive for potential buyers. Interest in Magnolia will rise along.

Adobe might well underplay the repository part and the visibility of JCR might decline in turn. We typically do not sell Magnolia because of JCR (although it does happen), and once we have a prospect, saying that he gets the same repository technology he would buy from Adobe will certainly be soothing any worries. Good for Magnolia again.

On the technology side, Adobe will either strengthen JCR and keep Day's CTO and JCR brainchild David Nüscheler, or David will leave to pursue his vision regarding repository technology elsewhere. David will get a lot of $ out of the deal, so he will have little reason to work in a direction he doesn't like if the alternative is to spend the rest of his life on his own island watching whales make love in sunset.

In either case, it should not mean too much worry for repository implementations. Even if Day under its new owner stops contributing to Jackrabbit, JBoss just launched ModeShape (tested extensively using the best test app they could get - Magnolia CMS). Good thing Magnolia is independent of the underlying repository implementation.


The business aspects

Adobe is building huge integrated application suites and I bet that CQ will not become cheaper by being part of that. On the contrary, Adobe aims to provide value through an integrated publishing chain for the customer (creation, analytics, publishing) and will monetize that value.

Adobe buying Day brings insecurity to the current Day prospects (and clients) and will result in more prospects leaning towards Magnolia. In addition, many people don't want to talk to the likes of Adobe because they rightly fear that Adobe will sell them every product in their portfolio, even if all they ask for is a WCM.

The market will split between those seeking an expensive integrated application suite (Adobe Livecycle) and those seeking a powerful and focussed WCM product that is easy to use, extend and integrate with their business needs (Magnolia CMS).

Summary

Adobe buying Day will be good for Magnolia and Magnolia customers; it will most likely not be good for Day customers (the aim of a takeover rarely correlates with the goals of the existing customer base, otherwise the existing customers would have bought something else). Thanks to Adobe buying Day, Magnolia's technology stack will gain more credibility, and with clients like the US Navy (navy.com), EADS.com, Sony Playstation and many other multi-nationals in its portfolio, it is easy to see that Magnolia CMS is a very credible alternative to becoming dependent on a single integrated product suite delivered by a rather closed-sourced billion $ company.

Tuesday, April 27, 2010

Using Magnolia's inplace-templating for hot-fixes

I just realized that we forgot to provide a mechanism for the Google-Site-verification meta-tag when we migrated our corporate homepage to Magnolia 4.2 two months ago. For those not acquainted with the subject-matter: this is a way to prove to some third-party service you actually own the site (as in "have the right to modify content"). There are various ways to do so, but the fastest and least intrusive is to add a meta-tag to your html-head section like so:

<meta name="google-site-verification"
content="eGPInzT6lx6Kff8Hb2T3SCvUmnjVWeBg76G_y7PXxBk">
Now, in previous versions of Magnolia that would mean I have to grab a developer, explain what I need and hope she finds time for my request within her tight schedule. Even if she wouldn't be overly busy, starting up a development environment (IDE), checking out the project sources, adding the needed functionality, testing, and then deploying to a live instance (which more likely than not involves someone from operations, too) would be a matter of least an hour, but more likely a week would go by before you see the change in production – plus it is definitely not worth the effort for such a small and single change.

So, after this somewhat long introduction to the issue at hand, Magnolia has a solution that is simple enough for me to use. It is the "inplace-templating" module, which we install by default with Magnolia STK (but STK is independent). It simply allows to edit Freemarker templates directly in the browser, and then enable and activate them.

Here are the simple steps:

1. find the main template in the Templating Kit menu:



2. Open the editor and add the missing meta-data field


3. Check enable template (see above screenshot)
4. Activate the template
Done.

You can check the site's html source to see the change:
So not only is it really trivial to adapt your templates on the fly (BTW, you can also map the templates repository to your filesystem via WebDAV and use your favorite text-editor to change the templates); the real benefit is that you can use this mechanism to do urgent hot-fixes without involvement of anybody else.

Once things work as expected, simply notify your developer and she will roll the hot-fix into the next regular release. This way, nothing gets lost, and the whole process is highly efficient.

Tuesday, April 20, 2010

Magnolia's Standard Templating Kit reduces project risk

Today, basic web content management functionality has become a commodity readily available in a thousand shades. Where does Magnolia CMS provide value not available elsewhere? It depends on your specific use-case. To some people, Magnolia's usability is key. Others need Magnolia's flexibility, the ability to easily integrate and adapt to any business requirements or Magnolia's outstanding scalability.

However, no matter what your use-case is, to provide value, your website will typically be custom-built on top of what any "commodity CMS" provides. And it is here that Magnolia CMS provides unique benefits not found anywhere else, as you'll see in a minute.

With version 4, Magnolia CMS has introduced a ton of functionality for the front-end (publishing side) of content management. The "Standard Templating Kit" is a powerful framework to create your own custom sites. It provides:
  • core logic to make custom templating easier and more powerful than ever before
  • support for accessibility, SEO, multi-site and multi-language content
  • about 50 production-ready content types ("paragraphs")
  • nearly 20 production-ready page templates based on typical use cases (e.g. home page, section, article, event, news etc.)
  • a configuration framework that allows you to extend, replace or customize any aspect of STK
To showcase its functionality, a complete production-quality website is provided as an example that can be easily adapted to your needs and provides an excellent starting point to define your requirements.

As should be clear from the above list, the STK provides significant value in itself. Consider the following graph. It compares the functionality provided by a demo site, a kick-start-kit or Magnolia's Standard Templating Kit (STK):



We know that the STK provides you with a significant head start, because so much of what you need is already provided. The next graph shows the effort remaining to build your custom website given the previous examples:


Compared to other options, the Standard Templating Kit significantly reduces the effort to build your custom website. Less effort generally means you will be faster, but more importantly, it means your project will be much more predictable. You have less unknowns. And for project managers, "unknowns" means project risk.


This is why ultimately, Magnolia's Standard Templating Kit greatly reduces the likelihood of a CMS project failure.

Monday, March 08, 2010

Growing the Community with the Magnolia Store


One of our goals for 2010 is to grow the Magnolia community significantly. We aim to do this on various levels, e.g.:
  • by providing better infrastructure
  • adding new communication channels,
  • improve the product
  • …and making what has been achieved more visible
The following new development definitely relates to last point in the list.

With 4.3 Magnolia CMS will sport yet another new feature – the Magnolia Store. The store will allow Magnolia users to check which modules are installed locally, download newer versions of these, download additional modules and view what is happening in the larger Magnolia community. Below is a first wireframe.


One of the reasons we want to provide this feature directly in AdminCentral is that today, the information which modules are available is maintained in too many places – at Magnolia itself, we list modules on the wiki as well as in the official documentation site. It would also be nice to have that info on the corporate site. Then some of the info is stored directly inside the module descriptors. Finally, contributors typically maintain that info on their own websites as well.

The results is a duplication of effort, maintenance hell, and most importantly it is difficult for users to find out about available modules. Today, the store looks as follows:

The Magnolia Store has been developed together with OpenMind (as you can see, the community is already hard at work) and will initially be hosted and maintained by Magnolia. It is implemented using Magnolia CMS. One of the ideas is that anybody who submits modules for the store will be able to get an RSS feed that allows him to to embed only his contributions on his own site.

Being server-side, we will be able to extend and modify the store's contents even after it is released. It will also allow us to track which modules are most interesting and add features like rating or commenting. Most of all, it should make the available modules more visible and motivate community members to contribute existing Magnolia modules.

Besides showing available modules, the store will also act as yet another communication channel, this time directly with the community. We will use it to announce available training sessions, new blog posts or anything else that the community might be interested in.

Eventually we will also directly support commercial usage of the store; for instance to sell modules or training. Right now, our main goal is to show you which modules are already available and provide a platform for our community to show their custom Magnolia extensions.

We are looking forward to see you join in and add your contributions!


Tuesday, February 16, 2010

Oracle, Sun & Java

Magnolia CMS is running on the Java platform. According to Wikipedia:

Java refers to a number of proprietary computer software products and specifications from Sun Microsystems, a subsidiary of Oracle Corporation, that together provide a system for developing application software and deploying it in a cross-platform environment. Java is used in a wide variety of computing platforms from embedded devices and mobile phones on the low end, to enterprise servers and supercomputers on the high end. Java is used in mobile phones, Web servers and enterprise applications…

Now that the deal between Oracle and Sun is through, it is interesting to see what this deal could mean for Java, and in turn for Magnolia CMS. As stated above, Java is used anywhere, but most interesting for us it is used on enterprise servers and for enterprise applications. Now, if anybody on the planet can claim to be "enterprise", it's got to be Oracle. It is a safe bet that Oracle will be very interested to keep Java healthy, for various reasons:
  1. many of Oracles enterprise applications are written in Java
  2. many of Oracles customers run server software written in Java
In the last couple of years there was a lot of discussion about Open Source Java. Whatever the outcome there, as much as Oracle means enterprise, Oracle means proprietary. It is unlikely that Oracle turns into a major driver of Open-Source Java or Open-Source in general. That might be regrettable, but doesn't mean anything worse than Java has been under SUN, which until recently was not interested in Open-Source Java either.

Unlike SUN, Oracle makes heaps of money and can afford to drive Java further to increase its value chain and fend off the likes of Microsoft, who with their own proprietary .net platform are the only real alternative for the enterprise business Oracle is interested in.

What it means for anything Java that is non-enterprise is anyones guess, but that is of little concern for us, as Magnolia is running on a server.

So (enterprise) Java will be stronger with Oracle, and I for one am happy that a solid and strong company like Oracle is brewing our Java now.


Wednesday, February 03, 2010

Groovy.times{Magnolia}

Forbes has published an interesting article about CTO's favorite choices of programming languages. Its author Dan Woods argues that Groovy combines the best of Lisp, Ruby and Python, but in addition:
"From an operations perspective, Groovy is deployed like Java, so data center staff that can handle Java won't be surprised by Groovy."
Dan ends his article with the words
"… if you are starting from scratch on an advanced Web site, it will be hard to do better than Groovy"
Of course, we at Magnolia CMS could not agree more. Magnolia is written in Java and provides a fantastic framework to build web sites efficiently.

However, developing and deploying apps in an enterprise environment like the Java platform involves a certain effort. Typically, a developer uses an IDE (Integrated Development Environment) in which code is written, compiled, deployed to a test server and tested. This cycle is well defined and has massive benefits in the Enterprise world.

Now as Joe Walker rightly notes:
"There's a fairly obvious link between developer productivity and the edit/compile/test cycle. One of the big things wrong with Enterprise Java is that you swap the edit/compile/test cycle for an edit/compile/deploy/test cycle and one of the things right about PHP is that edit/compile/test is just edit/test."
When you quickly wish to try out something new, build a prototype or add a feature for a demo, a more agile framework would be considerably more fun for the developer, could save a lot of time and lead to a better result. More agile means that the edit-compile-deploy-test cycle needs to be simplified.

Enter full Groovy support in Magnolia. With the next release (4.3, out in March) we will introduce full-blown support for Groovy, which allows for a much more agile approach to implementing new functionality for your web site, while retaining the full power, scalability and security of the java-stack.

With Groovy you can add new functionality at runtime without a edit-compile-deploy-test cycle. The edit-compile-deploy-test cycle is reduced to edit-test like in PHP. This really cuts down on the time it needs to try out some stuff, build ad-hoc functionality or prototypes/demos. It will also be extremely helpful when building import scripts or run reports.

View Greg's video of what we have achieved with Groovy support in Magnolia so far.

Tuesday, February 02, 2010

Getting serious

Magnolia today announced the appointment of Andrew King as the new Head of Business Development for Magnolia Americas. Andrew is coming to us from competing Alfresco, and as such he brings with him excellent industry knowledge, and he gets Open Source. Combining his expertise with the outstanding product that Magnolia CMS really is leads to excellent motivation on all sides, and we look forward to make many more customers happy than we already did.

I am really excited about Magnolia making headway into the US. After all, I personally founded Magnolia Americas in summer 2007 and spend considerably time there laying the foundation of our success. With Andrew, we hired a "native" who understands the US market and has worked with European companies before. This will be of great benefit for our clients as well as our partner channel in the USA. Developing the latter is Andrew's first priority, in line with our corporate strategy of growing with our partners. Our non-compete partner strategy should be a strong incentive for potential partners in the USA, and we look forward to partner with some excellent companies in the USA.
Having Andrew on board is certainly a milestone for our US business. Expect more good news to come!

Wednesday, January 27, 2010

ModeShape - a unified content bus for Magnolia?

While Oracle is working on delivering everything you might ever need from a single vendor, the real world is a mess. Always has been, always will be. (Reminder: politics has to do with people, not technology).

The real world means that you have a lot of information hubs (call them silo's if they are proprietary and provide no open API to access their content). Content Management Systems like Magnolia CMS have provided a very open architecture to access these hubs, in part because Magnolia is running on the Java platform, which has been built for such integration, and in part because Magnolia's design is so open. However, each such integration still means the developer needs to understand the target API, a fact that quickly becomes expensive.

Wouldn't it be much nicer if the developer could just ignore the fact how and where data is coming from, and simply use JSR-170 to access it?

Enter ModeShape:

ModeShape (formerly "JBoss DNA") is a JCR implementation that provides access to content stored in many different kinds of systems. A ModeShape repository isn't yet another silo of isolated information, but rather it's a JCR view of the information you already have in your environment: files systems, databases, other repositories, services, applications, etc.

To your applications, ModeShape looks and behaves like a regular JCR repository. Using the standard JCR API, applications can search, navigate, version, and listen for changes in the content. But under the covers, ModeShape gets its content by federating multiple back-end systems (like databases, services, other repositories, etc.), allowing those systems to continue "owning" the information while ensuring the unified repository stays up-to-date and in sync.

So, if all goes well, ModeShape will provide a seamless extension of our existing content repository architecture. Instead of e.g. creating a new workspace and importing data from a third party system, you could just use ModeShape and add a connector to said system. If you are lucky, such a connector already exists. ModeShape is LGPL and as such I hope that it will gain wide adoption as a transparent wrapper for JackRabbit. Used in this way (provided the performance hit is small), nothing changes from the perspective of Magnolia (or the developer) but eventually, it will simplify content integration on the JSR-170 level, something that would definitely be a boost to the importance of the specification.

And with some luck, the world will be less messy even for those that don't shell out for Larry's vision of one provider for all things IT.