Monday, August 28, 2006

Magnolia peak

For some reason, this week has seen a strange peak in Magnolia interest. Magnolia has reached a traffic rank of 13'057 on alexa (that means we are currently ranked the 13'057th place of all alexa-tracked websites on earth, which should mean pretty much any website).

Now maybe that doesn't sound so thrilling, but if you know that at the same time our main perceived competitor's rank isn't even available because they are not in the top 100'000 sites, thats not too shabby. Not that I want to make much out of it, but it feels good.

Also, we are likely reaching a cumulative 150'000 downloads in the next 2-4 weeks, another milestone.

What else is news? An impressive list of large companies is in contact with us, we will be closing a number of significant deals in the next few weeks, and today has seen some serious interest in Magnolia from a very large company. Lets keep our fingers crossed!

And I will be in Paris launching Magnolia France later in September, just after the Geek.Meet.

Now all I need is time to write all these press releases…

WebObjects will be open-sourced

This must have been one of the longest running tragedies in recent computing history. The short story is that WO (as WebObjects is known by its afficinados) is an outstanding piece of software if ever there was one, but never got off the ground commercially, was copied by Open-Source programmers, dropped its price from 50k to 600USD (IIRC) to free, and finally will be released into the open.

Parts of it (the Enterprise Object Framework) stem from the client-server time before the web as we know it was born. Apple (who bought it with its aquisition of NeXT) is using it to build their Web 2.0 suite of apps like .Mac or the iTunes music store, so the capability of it is proven beyond doubt. A couple of years ago I compiled a list of companies using it, and just about every major bank was on that list.

Alas, somehow WO never took off. Other frameworks copied the concepts or even the API. Just a view days ago, jope 1.0 was announced, which might have played a part in the decision to finally open-source WebObjects.

For me, this is several years too late. Would WO have been open-source in 2003, we might have used it to build Magnolia. Today, we are rewriting one of my last remaining apps of that time – an associative web shop that I wrote for the Kunstmuseum Basel – to Magnolia.

Congrats to Apple (and specifically Steve Jobs, who apparently wanted to open-source WO back in 2004) for finally doing it. I hope it picks up speed!

Tuesday, August 22, 2006

workflow state of mind

Today John and I sat together to do some final testing of his decision table implementation. As so often the problem was with the data (data is root of all evil), not the software.

During our obligatory lunch pizza I mentioned to him that I think that programming with and for workflows differs from "normal" programming.

As a "normal" programmer, if I change code, I can compile it, test it, run it and if it does what it should, thats fine. In other words, I am pretty free to change all aspects of my system. Granted, I need to make sure that if I change the API, I change the implementations that use my API, but the whole process is pretty much independent of a time component.

When you deal with workflows, the picture changes profoundly. Why? Because everything you do needs to be done in such a way that long running processes still work.

At first that sounds pretty trivial, or logical. But if you work on a project that has processes running for a year and longer, the impact of this requirement is quite massive. It means that whatever you do (to improve the system, to fix a bug), part of the system will still need to run with the previous, maybe buggy logic. It means you cannot just change things, you need to find a way to know what you are allowed to change, and what not.

It would be nice if a system understands that a "normal" programmer is in a different state of mind, and provides mechanisms to protect her. For instance, once you launch a flow, all definitions could be versioned, so that the programmer is free to change them later without affecting the running system.

Alternatively, instead of versioning, a tool could warn me that there are still running processes that use a definition that I have just changed.

In the context of OpenWFE, workflow definitions are versioned, and the workflow that you launch has a copy of its definition stored with the engine. The same is not true however, if you define (sub-)processes to be loaded at the startup of the engine (a library). These are not versioned, but instead are valid as long as the engine runs (they can be overwritten if you want, since in OpenWFE's Scheme-like semantics, a function/method/flow-definition is the value of a variable, so you can change that value at runtime). Thus, if you change them, and restart the engine, running workflows use the new version of the library, not the one that was present when the workflow was launched. So there is a difference between a sub process defined in a "normal" workflow definition and one defined in a library even when they are syntactically equivalent.

This difference is exactly the difference you need to take into account if you start working with workflow engines. A workflow programmer needs to be in a "workflow state of mind", and take into account that whatever he changes, there might be running processes that depend on previous versions of a what he is changing.