A tragic event, but don’t blame open source

Developing software is not an easy task, and developing a second generation system from scratch can turn out disastrous as Wednesday's announcement from Umbraco clearly showed. They are abandoning Umbraco v5 and this is a pretty big deal with some very serious fallout for a lot of people. For those not aware Umbraco v5 was released as stable in January, courses and a major conference targeting v5 was sold and websites was built on top of it.

You cannot blame open source – quite the contrary

Reading the many reactions on yesterday’s announcement I came across a tweet saying this was one of the many pitfalls of open source. I fear we will now see the old closed source CMS vendors crawl out of the woodwork and use this event to spread their open source FUD.

I strongly disagree with that notion - I’d say that this is a one of the pitfalls when dealing with people who - for one reason or the other - didn't manage to cross the finish line. Open source – if anything – only reduce the fallout, simply because open source make it really hard to hide behind a skilled sales organization and shiny product presentations.

If there is any truth in the open source argument it’s that an Open Source project may lack some of the organizational components which can reduce the risk of a thing like this happening, but so can a commercial company.

What I think is worth taking away from the closed vs. open  argument is the fact that a commercial vendor would hide the horrors as best their marketing department could, they would keep on-boarding customers, sell them support hours to fix things and admit to as little as possible. I know, because I see commercial venders do vaporware with things like shiny Marketing Suites and then hear their partners lambast it off the record - and we used to be a closed source shop ourselves. Hiding failure is simply easier when the vendor controls the information flow and things happen in the hidden.

Rewriting a system from scratch

This was supposed to be Umbraco’s next generation CMS, completely replacing their version 4. Not going forward with v4 must be based on their lack of faith in its quality and its architecture's ability to evolve. In the words of the v5 lead architect: "there comes a point where you've replaced so many parts of the car that you're left only with the original chassis, and you have to attack that problem if you are to make fundamental improvements."

Doing a complete rewrite is a very risky way to reinvent yourself, as is well explained in Joel Spolsky's “Things You Should Never Do, Part I”. One of the primary pit falls is the second-system effect where you try to solve all the problems you had with your previous version at once. This can lead to a bloated and over architected code with abstraction layers that does not withstand the test of reality, and when you release it, shit hits the fan (pun intended).

Composite C1 1.0

We know from firsthand experience that a complete rewrite is a risky business. In early 2007 we stopped major development a previous generation CMS, pulled out pen and paper and created a brand new .NET CMS from scratch - a CMS focusing on powering corporate websites, giving high usability for all people involved and tooling for a diverse group of devs. Just like Umbraco we released a version 1.0 after eighteen months of design and development and – boy – it was not a pure joy to work with. But here similarities seem to stop.

Composite C1 1.0 sucked because it was missing fundamental features, had bugs and we had not spent any time on optimizing performance. Things that you can fix without killing the patient. We partnered up with a few trusted web agencies and started building websites on the brand new platform. Working very closely with a small group of customers and developers allowed us to learn, react and fix things - fast and in a priority making sense to developers and consumers. Time passed, we continually cleaned up, optimized and added needed features in a way we can fully vouch for.

It took 17 months of continuous field testing and improving to get from the initial 1.0 release to a CMS that had the stability, performance and feature set good enough to enter the battle arena with older and more matured systems. After 7 or so releases, in the late summer of 2009 Composite C1 1.2 SP2 became the awesome product the core group had hoped 1.0 would be, except no 1.0 release can be like that unless you have very dedicated and patient customers and community members. For more details on that journey, check out our closed source and open source timelines. For a short intro to Composite C1 CMS visit our page on CodePlex.

Our experiences with a rewrite

The rewrite ended up well. We had a sane architecture, a super tight code base, this was my third CMS rewrite and we were extremely pragmatic and skeptical about feature creep and introducing new abstractions. Getting tons of features into 1.0 was not a concern. Building a .NET CMS that could one day have those features was. And we matured the platform hand in hand with partners, customers and the community our open sourcing of Composite C1 have yielded.

A rewrite is a process and you have to bite the bullet, hang in there and act responsibly. Today Composite C1 have gone through many rock solid major releases and our community and list of references is steadily growing.

I have no way to validate if it is true when the Umbraco project say v5 is beyond repair - I guess they are the best judges - but no matter what, a brand new CMS is not likely to be kick ass 4 months after you have your first customers on it, but obviously you should see clear improvements and I guess they were missing from v5.2 since such a monumental decision was taken.

The v5 fallout

Beside from the ever-faithful fans which any major IT company and open source project seems to suffer from, people are obviously going to be shocked and some pissed about what just happened. This is nothing short of a complete and utter break down and a lot of money and confidence will be lost because of this. Going back to a v4 the vendor just spent two years leaving hardly feels like a good outcome – I agree it’s the best outcome if what you just built is a complete dead end – but please don’t call it a good outcome.

Web agencies are going to have an awful hard time convincing customers to switch to Umbraco after this. Already we have had several agencies coming out of the blue, telling us they need a new way to go. They say they cannot pitch Umbraco again with full confidence.

Growing our community and user base is obviously something we strive for (I truly wish we had anything close to Umbraco’s skills in that respect), but this way of growing really doesn’t become me. This event is just sad. We would much rather grow lonely on the fact that our long hard work on Composite C1 have given us a cleaner, more stable, versatile and modern platform that went trough the growing pains years ago.

Who is then to blame?

From the v5 RIP announcement it sounds like you could blame the second-system effect and the Umbraco organization’s inability to avoid it. You could blame the guys who thought up the feature list – I haven’t seen it, but the feature list was most likely way too ambitious and trying to embrace tons of cool technology from day one. Then you could blame the developer lead for not standing his ground, cutting features and not keeping things as simple as needed. But since the buck doesn't stop there you could blame the guy that labeled the code as RTM, stable, ready - signaling you should go use this and bet your livelihood on it - clearly without the extended beta and RC periods a 1.0 release like this would need.

Perhaps impatience is to blame - not giving v5 the time that a brand new product truly need to get finished, tuned and tooled.

In short, you could blame the way the Umbraco project wrote, managed or killed their v5 - I feel there is a component of irresponsibility at play somewhere in the process. But please do not blame open source or the community for not stopping this earlier.