Open source doesn’t always represent best value

Despite much hype we did not see a breakthrough for open source CMS last year. When I launched the discussion last year, we  received some great comments, e.g. on intellectual property and warranty, suggesting that in some cases open source is not the right decision.

In the past decade, several governments have issued statements with strong support for open source, e.g.  UK government backs open source and Denmark’s endorsement of Plone. Often these statements were driven by an underlying desire to save money and drum up competition for Microsoft and the de-facto Windows & Office monopoly.

Our usual advice is not to start by deciding on open source or not. However, in our community of practice, many technology selection projects often start with a debate around whether open source is good or bad. Many members report that they have experienced quite expensive open source projects, indicating that open source is not always cheaper.

The open source debate is often based around emotions, eg. the very strong urge to avoid Microsoft. Cartoon by Hugh MacLeod

The open source debate is often based around emotions, eg. the very strong urge to avoid Microsoft. Cartoon by Hugh MacLeod

A significant factor in terms of value is the cost and quality of the implementation. If you’ve selected an open source system, say Drupal, WordPress or Umbraco, for your new website, but cannot find any experienced implementation partner, then you may be forced to take a step back and rethink your selection process. You might have enough resources to do the implementation yourself, but I don’t recommend doing it without proper training and expert assistance. Most open source projects have really weak documentation.

Also, if you don’t have any resources to engage in a vibrant open source community, you are missing out on one of the big advantages of open source. Except for the really big vendors, e.g. IBM, Microsoft, Oracle, which have decent communities for developers, most commercial vendors don’t have communities where you can meet other practitioners and share experiences.

If you are concerned about risk, it is worth noting that some relatively well-known open source projects, e.g. Mambo got in trouble back in 2005 when most of the developers associated with it decided to start Joomla. HyperContent, another open source CMS, was announced dead in 2008. Commercial systems don’t live forever either, but typically you can continue to buy support from the vendor.

Your requirements may deflate the value of open source. Those with strong requirements for Microsoft Office integration, e.g. seamless Word integration, might struggle to find an open source solution that support the requirement, while many commercial alternatives have offered this for 5+ years.

The past decade saw the rise of the so-called “commercial open source vendors”, e.g. Alfresco, eZ or Jahia. These vendors have open source solutions, but earn their money on selling enterprise licenses, training, and support agreements. Some even do consulting. In their own words, they provide the best of both worlds, although I’m yet to see any of these firms develop a serious community.

In your view, when does open source software not represent the best value?

I am presenting on Thursday 7th January in London at a free event run by BCS – The Chartered Institute for IT on Public Funds in the UK: Open Source for Document and Content Management. Whether you can make it to London or not, I invite you to participate in the discussion by posting a comment below.

I think you are getting it wrong.

Companies buy open source because is better, not cheaper.

To think about open source as free as in beer is quite right but no the only criteria for choice. It is true that with open source you don’t have licensing cost upfront or in every upgrade. No cost of ownership.

It is also true that it is reliable, precisely because it is open. What about Apache, Linux, NetBSD, Samba, Drupal, SSH, Zope, etc…
Apache is the number one web server on the Internet with more than 106 million websites, far from Microsoft. Linux is the number one server operating system on the Internet. I ran Windows servers before I changed to CentOS and my headaches are gone!
Open source is contributed by passionate people just for the sake of making it better, not just with financial interests. That, IMO, is the best ownership. For most closed source software, that feeling of responsibility that any one and every one can see the code and hence you might be held responsible simple won’t be there.
Open source enhances and improves security (due to the open peer review, open source software bugs are usually fixed before they are exploited) and encourages open protocols (internet’s and world wide web’s recently rapid growth is based on open standards and open source code, such as BSD’s TCP/IP and DNS code, the NCSA and Apache web servers, and the Sendmail email routing software).

Support is normally where anti-open source advocates come in. I honestly think that open source offers the best support, in cases you have competent people in your team (who is easier to find than for a closed system), the community or in the same way you get it with licensed software, via a vendor or shop.

Every time you can find more and more specialized vendors supporting open source who are reliable, and I am not talking just about Red Hat or IBM, if you choose Drupal for your CMS, companies like acquia, Development Seed and others.
You mentioned that all these “commercial open source vendors” like Alfresco do not develop communities like Microsoft… you are wrong. The communities are around the products they support not themselves. Same for Microsoft. You have communities on Windows, Office, Sharepoint…
You talk about risks? Like in the case of Mambo diverting into Joomla… This is normal!! you can always take an open source project and fork it! I see more risk in betting for a closed product that if it dies, you are basically dead as well.

If we talk about Drupal it powers websites like United Nations (end of poverty campaign), World Bank, Warner Bros, Discovery Channel, AOL, Sony, NATO, MTV UK, BBC, the Onion, NASA, Greenpeace UK, New York Observer and thousands of others.

You mention documentation worse in open source, and I couldn’t disagree more. It is often better in open source as well. Most popular open source solutions are extremely well documented and a variety of free and commercial technical support options are available. Due to the nature of community development, documentation and instructions are often written from a variety of viewpoints — creating well-rounded information, instruction and tutorials. In addition, open source projects can’t hide usage techniques, due to the free availability of the code. Free technical support is often available in the form of mailing list or newsgroup discussions.

In many cases administrators prefer closed source because it offers some kind of protection in that you can always say “we are talking to the vendor, they are working on it…”. So, the responsibility is conveniently shifted to the vendor. And this ripples up all the way to the top management. Net effect? Problem remains unsolved. Most surprising fact is that nobody seems to bother about it, but as I said every time more open source vendor are coming into the market so if there is no expertise in house you can turn to your vendor, the community or hire a couple of interns to help you developing at any level (not just through APIs, in the best case, or via the vendor…).

I would recommend to do not fall for the sales pitch. The samples they’ll show you will quickly differ from your reality and you will have to start customizing the software and then the more you know and have access to all the source, the more options to go somewhere else if not happy.

If people still don’t understand the open source is the way to go, they are missing something fundamental.

Did you know that Google is the biggest contributor to open source? All it releases is open source, from chrome, to wave or android. They have understood that in this era, to be the number one the customers should be the ones developing what they want, so the platform should allow that.

To a some extend that is the secret success behind the iPhone and its 100.000 apps, a good API and a lot of people developing, but the police role Apple plays is not something developers like, and that is why the top developers of iPhone have already switched to android. I believe android will be bigger than iPhone in a very near future.

What I am talking about here are the fundamentals of how companies are working know, far from the model we were taught in the MBAs or in the business schools. Before they decided what the client should have and got the most out of it. This way of thinking and acting is over.

Now the key to survive and grow is to let the clients decide what they want, enable them to do it, and with the minimum benefit to survive. Again Google is avery good example of this. Also from the pharmaceutical industry who through collaboration can get the most out of a spread community of scientist that otherwise they could not afford.

If you don’t follow this pattern you will disappear.
— dani, January 4th, 2010 14:25
By the way, I see you are using Apache, PHP 5.2.12 and WordPress, all 3 open source… Good choice Janus.
— dani, January 4th, 2010 14:25
I think that 2010 will see the rise of more pragmatic commercial open source vendors such as ourselves (Umbraco). Taking the best from the traditional closed source world (someone to call, official support, training, certification programs, SLAs, warranty, etc) without cannibalizing the ecosystem with a consultancy/professional services department. The latter is often kills the motivation for a professional ecosystem and then you’re likely to be better off with a closed source vendor with a bigger ecosystem (partner network).

When evaluating open source vs. closed source, I believe that the open source needs to be on pair with what you expect from a closed source vendor, especially when it comes to finding an integrator (Solution Provider) and getting the level of support/warranty that meets the demands of your organization. In addition to this, a good open source project will often have a great dedicated community which is the best (= most transparent) way to monitor the health of the project/organization.

When it comes to CMS I think that one of the areas where open source sometimes falls short is that they’re quite generic in their nature, where you might find a more specialized (vertical) closed source CMS which might fit better to your needs when it comes to OOB functionality.

Niels Hartvig / Umbraco
— Niels Hartvig, January 4th, 2010 14:25
I agree that it’s more complicated than “open source” versus “closed source”. I’ve argued that “open source is the wrong question”. Not the wrong solution, but the wrong way of driving the evaluation process. For me, there are three key aspects to consider:

* Who will be the authors, and how usable does the CMS need to be?
* Who will be the site owners, and how technical are they?
* Will there be any customisation/development, and if so, done by who?

I’ve covered this in a slidecast, done last year:

http://www.slideshare.net/jamesr/opensource-web-cms-the-right-question-audio-presentation
— James Robertson, January 4th, 2010 14:25
> when does open source software not represent the best value?

When the out of the box features of a proprietary product provide your organisation’s short term requirements, assuming you cannot find an open source solution that meets those requirements as closely.

(I use the phrase short term requirements to mean the next 1-2 years; looking at criteria beyond that is generally too speculative to be useful. And by requirements, I take a holistic view: software features, support requirements, training, et al.)

In relation to your comment about commercial open source vendors not creating sizable communities: this is hard to do because the company culture must embrace that growing the community is a long term investment that takes planning, commitment, time, cost, energy, and may from time to time compete with short term corporate interests (like exceeding sales targets, etc.)
— Sigurd Magnusson, January 4th, 2010 14:25
Just wanted to provide an example to illustrate that open source can indeed be costly.

According to an article on iTWire, The Spanish Presidency of the European Union has just awarded a 12 million Euro contract to their web site built on OpenCMS…

That is a lot of money to maintain a website (regardless if it is based on open source or commercial software).
— Peter Sejersen, January 5th, 2010 14:25
Thank you for all the great comments. I very much appreciate it.

There’s an additional aspect, that I’ve forgotten so far: Many customers do like to be treated like a key account and get the attention of a good key account manager. When it works, this can make a big difference in terms of the project outcome and avoid many problems. You can’t get this with traditional open source, e.g. Mediawiki or OpenCMS, which don’t have a company behind them.

Dani: In my experience, many consider and buy open source specifically to save money.

Cheers, Janus
— Janus Boye, January 5th, 2010 14:25
@PeterSejersen: I think that a very “generous” buyer is more to blame than openCMS and open source in general.

Finding one extreme example seems a little unserious and populistic IMHO. Let’s raise the level on this blog, no
— Niels Hartvig, January 5th, 2010 14:25
It do agree to some extend that open source doesn’t always represent the best value. One example is around OpenCMS version which I used for one of the projects. It lags the basic content publish functionality, its inability to have staging and production environments. We ended up writing a custom code. It is very important to understand requirements and product’s capabilites before blindly selecting open source product just to save money.

Cheers,
Shishank
— shishank, January 5th, 2010 14:25
@James Robertson: Great presentation and an interesting angle to look at “open source” vs “closed source”!

One thing I disagree on though is the general statement that “low cost” is a benefit of an open source solutions.

The cost for implementing and maintaining an open source solution can be the same or even higher than that of a commercial solution, depending on the goals of the organization implementing it, available resources, time lines and a million other factors. (But of course the same factors can make it the better solution)

Of course cost ist not the only factor determining the value of a solution but certainly one of the most important ones.

Oliver Jaeger / e-Spirit
— Oliver Jaeger, January 12th, 2010 14:25
Over the years we have integrated a number of different closed source CMS’s into various companies such as Obtree, Immediacy and Microsoft CMS.

We made the decision 12 months ago to concentrate solely on Umbraco and for us it has been a great decision. We recently beat 3 of the top closed source .NET CMS’s in a 4 way pitch where we were brought in as a last choice and a kind of ‘lets just see what Umbraco is like’, not expecting it to be any good.

In our opinion, CMS’s all do the same thing – manage content, be that in slightly different ways. The main differences being cost of licence and quality of implementation by the partner or implementation specialist. You can pay upwards of £20k for a closed source licence, but if the implementer isn’t up to scratch, then it doesn’t matter how much you pay, it still wont be any good and the project may be a failure.

The thing with Umbraco is it can do anything its closed source competitors can do, but the money you’d spend on the licence fee you can spend on the implementation, meaning a better quality implementation all round as you don’t have to scrimp on development.

Anyway, thats my 10 pence worth…long live Umbraco and open source is what i say…and we’re very excited about 2010, we’ll be going along for the ride all way
— Adam Shallcross, January 12th, 2010 14:25
Not sure if the open vs closed source debate is that relevant for CMS these days.

Any platform will incur considerable cost of ownership in terms of development and maintenance over the long term, it’s just that some do not carry up-front licensing fees. Let’s face it – on a £250k development, the licensing fees for most middle-market commercial CMS platforms can be a relatively small proportion of the overall project cost.

Platform governance can be as much an issue for closed source as open source. Mambo users may have been left with egg on their faces a few years back, but RedDot users are looking pretty twitchy at the moment too.

As has been pointed out already, the role of the implementor is pretty key. if you have a good long-term relationship with a competent implementor then that’s half the battle won.
— Ben Morris, January 23rd, 2010 14:25

A breakthrough for open source CMS?

By Janus Boye

Open source content management systems have made major progress in recent years. The systems have matured usual weaknesses such as usability, integration, lacking features and weak documentation has been addressed. In addition many large and complex organisations have adopted open source CMS and are now running busy sites on the platforms.

For buyers, a significant barrier to open source adoption has always been the lack of large competent implementation partners with open source CMS experience. In the past, open source CMS developers used to be mostly freelancers or boutique consultancies with less than 10 experienced developers. Very often these had low rates, but weak project management and a poor track record. Today most system integrators and digital agencies, even the large ones, have experience with open source CMS.

The increased adoption by viable implementation partners has been partially driven by the many government agencies that mandate the use of open source, often due to the systems’ strong support for standards. This has forced large digital agencies, e.g. LBi and Sapient to build skills with several open source systems. As a testament to this, LBi hosted an UK Umbraco meetup at their London offices earlier this month.

When looking for an implementation partner, consider specifically asking for open source, as many of the partners still promote commercial alternatives, e.g. Day Software or Sitecore, as those projects tend to be more profitable for them.

The marketplace for commercial and open source systems are equally crowded. A long list of open source projects will meet your requirements, have relevant references and a few available implementation partners.

To expand on our recent CMS Shortlist, here are the open source tools that we consider good candidates for your shortlist:

  • Drupal

  • eZ

  • Joomla

  • Plone

  • TYPO3

  • Umbraco

In certain regions you will find strong penetration of other viable open source systems such as Alfresco, Hippo, Jahia, Magnolia, SilverStripe, Squiz and even WordPress used as a CMS.

I still commonly get the question whether open source CMS comes with any major disadvantages. For a while my answer has been no. Open source tends to share some of the weaknesses found in commercial systems, but today there are no good reasons for automatically excluding open source from your CMS selection.

eZ Systems won Web Idol at Philadelphia 2009

Congrats to Norwegian open-source vendor eZ Systems, on beating the competition and winning the Web Idol competition at the J. Boye Conference in Philadelphia last week. Presented by co-founder and CTO Bård Farstad, the demo looked fairly similar to eZ’s previous wins in 2006 and 2007 at our European conference, but as always it was not the judges or yours truly, but solely the audience vote that decided.

As usual the 6-minute demos gave a very realistic impression of how well vendors demonstrate their own product in front of buyers. One of the vendors showed a Microsoft PowerPoint presentation coupled with and an unusual video from the office, while another vendor tried to role-play their way through the demo.

During the 6 minutes eZ demo the audience saw several updates to a sample site, including the addition of video and a multi-file upload of several photos of the audience. Not enough to impress the judges; Tony Byrne from CMS Watch in particular expressed that he was left a bit dissappointed, while Lou Rosenfeld was not entirely sure who eZ Systems was trying to target.

The list of companies eZ Systems have beaten in the Web Idol competition includes vendors like Ektron, FatWire, Hippo, Mediasurface, Sitecore, Terminalfour and Tridion. Sitecore is the defending champion from our 2008 European conference, but decided not to compete in Philadelphia.

Does this mean that eZ Systems is a good fit for your projects? Not necessarily, but I would say that winning 3 years proves that eZ is capable of showing a very experienced audience something more appealing than their competitors. Do make sure to get a live demonstration before you select your next web platform and don’t be any less critical than our Web Idol judges. Also remember that you are unlikely to get the CTO of your Web CMS vendor to carry out the demo – if you do, probably only for the pre-sales engagement. You are more likely to end up dealing with a local system integrator that might ask for 60 minutes to show what the eZ Systems CTO could convincingly show in 6 minutes.

I hope the Web Idol contestants at our European conference in November will show new demos that can really impress the audience and the critical judges.

Use EPiServer for your website and keep SharePoint behind the firewall

Congrats to DSB, our former monopoly railway company in Denmark, on a recent relaunch of their website at dsb.dk using Swedish CMS vendor EPiServer. DSB seem to have come up with a successful recipe by adopting EPiServer for their public website and keeping SharePoint behind the firewall for knowledge sharing and collaboration. If you take a closer look at the site, please note the harmless URLs. Also, Urchin Software by Google is used for website analytics.

EPiServer opened their office in Denmark early in 2007. This represents a major milestone in terms of establishing local presence. I’ve talked to many customers around Europe who use the same combination of EPiServer and SharePoint. In some organisations they are closely integrated, e.g using EPiServer Connect for SharePoint, while in other organisations the 2 overlapping products simply co-exist. Both products are based on the same underlying technology, but many editors and business users considers EPiServer easier to use and implement, at least for public websites. In general, if you have requirements like accessibility or multiple languages, you’ll probably need an alternative to SharePoint.

EPiServer has grown in recent years, yet it can still be hard to find experienced implementation partners  outside Sweden. I witnessed an extreme case of this last month, in Geneva where I met an English and a Swedish consultancy pitching for the same project and both offering EPiServer. If you don’t mind travel costs, there is always the option to put consultants on the train and have them travel to you.

Finally, it is interesting to note that DSB is still listed as a featured case study on FatWire’s website. FatWire CMS used to be the engine behind the DSB site and the English part of the DSB site is still based on FatWire. If they also migrate the English site, I expect that the link will stop working as it is vendor specific. FatWire no longer has an office in Scandinavia, so perhaps that’s why nobody noticed that they actually migrated the site. This does not reflect particularly well on FatWire and serves as a useful reminder to the rest of us: be careful with where and when your let yourself use as a reference. Successful cases studies are extremely valuable for vendors and this is worth remembering, in particular when you negotiate discounts.

Update Dec 23: DSB is no longer listed as a customer case study on the FatWire site

Thanks for this blog post – it’s interesting to get a top-level insight into the DSB site.

The only point that I strongly disagree with is at the start of the third paragraph: “EPiServer has grown in recent years, yet it can still be hard to find experienced implementation partners outside Sweden”.

EPiServer now has over 250 partners around the world. There are still some countries where partner support is light but here in the UK there are over 35 partners including my company, Netcel, which is one of four UK companies accredited as an EPiServer Premium Partner. We have developed and now support over 15 EPiServer sites for clients. Other UK partners have similar levels of client engagements.

So although I agree that partner support cannot be found in all European countries, your statement that “it can still be hard to find experienced implementation partners outside Sweden” is factually incorrect.
— Tim Parfitt, February 3rd, 2009 0:17

Even Google discontinues products

By Janus Boye

November brought bad news for all Livelyzens. In a brief blog post, Google officially announced that they would shut down Lively.com in order to "prioritize our resources and focus more on our core search, ads and apps business"

Lively was one of many services that came from the Google Labs environment. The service was released in July 2008 and introduced an innovative, 3-D social platform, where users could build their own interactive rooms and embed them into web pages. But only 4 months later Lively was discontinued, leaving the active user community in a sad state.

As a response to the sudden lock-down, the community has created an online petition, which many have signed, adding comments like "Lively has given me so much - please don't shut it down" and "Lively is more than a chat in 3D. [...] it is a world of feelings." All a little sad really, in so many ways...

Yet while the shut-down is indeed sad for the many users, it is also a timely reminder that

  1. You need to be careful with any beta release.

  2. Vendors -- including big vendors more often than not -- sometimes discontinue offerings

The case with Lively illustrates that Google is a business just like any other and that businesses need to make money. As they themselves write on their blog: "[...] we've also always accepted that when you take these kinds of risks not every bet is going to pay off. That's why [...] we've decided to shut Lively down at the end of the year."

In a future Google in the Enterprise Report, we plan to take a close look at Google based on our many on-going conversations with customers about their experiences. Thanks go to my colleague Peter Sejersen for his eagled eyed analysis of the Lively situation.

Smart practitioners have harmless URLs

I’m not that technical, but I’m frustrated that the problem with harmful URLs doesn’t seem to want to go away. Microsoft’s very own Jon Udell started 2008 with a very well written comment on .aspx considered harmful, but .aspx is still the standard default used in most SharePoint 2007-driven public websites.

Over at CMS Watch, I did follow up on Udells comment with a posting on Location matters: URLs should be short, meaningful and permanent.

Read more

Swedish CMS-vendor EPiServer keeps growing – still without setting foot in the US

I’ve been tracking Swedish CMS vendor EPiServer since late 2005. Many milestones later the company has now expanded far outside beyond its home shores, but unlike other ambitious and growing vendors, they have so far resisted the usual European temptation to attempt venturing into the US market. Quite unlike local competitor Sitecore, which have built a very visible presence in the US over the last few years.

In recent news from EPiServer they announced the release of the second edition of EPiServer CMS 5 in early October 2008. CMS 5 R2 has several improvements for editors and also a few more business user reports. Moreover, in October, EPiServer World reached 5,000 registered members, which is quite impressive for a CMS vendor community.

As a Microsoft ASP .NET 3.0-based Web Content Management system, EPiServer CMS seems to have been able to successfully fight off the immense interest in SharePoint 2007, even for public websites. Now 2 years after the release of MOSS 2007, my impression is that even Microsoft has recognised that their portal product has some shortcomings, and until Microsoft significantly improves the product, there is still a large market for website vendors like EPiServer.

Still, if you are considering EPiServer CMS for your projects, I would recommend that you set aside adequate  time to select the right implementation partner, in particular if you are based outside Sweden, where competent help may be harder to find. Some European countries, like Austria and Switzerland, still don’t have any local EPiServer partners according to the listing of partners. If you are in a country without a local EPiServer office, interesting things have sometimes been known to happen when you talk to system integrators that have proposed EPiServer. Some might pull in help from HQ in Sweden, while others may work with another regional office.

Finally, I recommend taking a closer look at the detailed EPiServer evaluation in the Web CMS Report from CMS Watch.

No easy upgrade for Sitecore customers

By Janus Boye

While Web CMS vendor Sitecore has been busy promoting the new user interface in its recently released Version 6, the company has attracted quite a bit of criticism from existing customers for the new version's lack of an easy upgrade path.

In a recent blog posting by Sitecore's VP of Technical Marketing, Lars Nielsen, he discusses their upgrade strategy and explains the company's choice between delaying the release of Sitecore 6 or let the database conversion tool follow afterwards. Similar to many other vendors in this situation, e.g., Microsoft, Sitecore decided to get the new product out the door and worry about upgrades later.

The definition of immediately afterwards may extend beyond the 2 months that have transpired since V6 came out, but I see that Sitecore themselves have still not upgraded their very own website. According to Sitecore, an alpha release of the upgrade tool is expected this week, but there is no news on when customers can expect a final release.

Regardless of vendor, upgrades are never straightforward, and you typically want to wait until the vendor has gone through the pain itself before teaching them the ropes. In this case, though, it is telling that Sitecore has focused more on pleasing new prospective customers and less critical analysts alike with exciting new demos rather than supporting its faithful customers.

If the past is any guide, do remember to budget and plan any upgrade carefully.

Location matters: URLs should be short, meaningful and permanent

By Janus Boye

In a refreshing blog entry from last week, Microsoft evangelist Jon Udell considered .aspx harmful. Udell boils it down to futureproofing and style.

We've been writing about the importance of URL's since 2005 (e.g. Portal Software: Passing Fad or Real Value?, State of the Art for Enterprise Portals) and in The Web CMS Report and The Enterprise Portals Report we cover the URL structure for each and every vendor.

Interestingly almost every vendor criticizes what we write about them when it comes to URL conventions, with a few open source vendors as the exception. Either the vendors with harmful URLs assert that it is a non-issue or they keep repeating that their professional services team can easily implement redirects or rewrites or other hacks to create shorter, better URLs. Rarely do they remember that if you do create redirects those too also need to managed.

With lack of understanding from the vendors, many enterprises find themselves tied to both vendors and technology. An unfortunate example is Italian car manufacturer FIAT, which uses BroadVision on their website with a URL that looks like this:

http://www.fiat.com/cgi-bin/pbrand.dll/FIAT_COM/home.jsp?BV_UseBVCookie=no

The URL is fascinating reading: You'll find the BroadVision cookie flag at the end, after JSP technology mixed with a DLL and CGI (!) earlier on. I've seen longer URLs, but the problem here is certainly both futureproofing and style, as Udell points out. I would add security to the list of problems, since a transparently programmatic URL is easier to hack.

Not only should you ensure that your site has short, meaningful and permanent URLs, but as buyers you should also try to influence the vendors so that they understand the issue. This matter is relevant to every single project, so customization should not be required. This should be out-of-the-box!

Further reading: Take a look at a 10-year old article from Web inventor Tim Berners-Lee: Cool URIs don't change.

State of the Art for Enterprise Portals

By Janus Boye

Portal software technology has been around since 1998, and while portal implementations still often suffer from many shortcomings, the industry has also come a long way.

As our understanding of portal technology has evolved we've elaborated a set of common, sometimes decisive, portal scenarios that describe different business problems. These scenarios, however, range widely from the simple to the more complex.

While we favor scenario-based analysis, it still begs a question: can we generalize more broadly about features and attributes that are universally essential to successful portal projects? Have we learned enough to identify a current "state of the art" in portal functionality across all types of enterprise scenarios? I think so.

Beyond Scenarios

Many vendors call their products "enterprise portals," but our research finds that in reality, different tools do better and worse across these different scenarios -- and also vary substantially in complexity and cost. As such, scenarios are essential to help you focus on your concrete needs and project goals.

Nevertheless, portals are mature enough that we can start talking about baseline capabilities and practices. As part of my ongoing research with technology buyers for the new Portal Project Starter Kit, I've identified a set of features and attributes that any enterprise portal in 2007 should be able to boast. These range across the different services a portal offers, its technical aspects, as well as important vendor intangibles. Any portal project worth its salt will benefit.

State of the Art, Circa 2007

I'll divide state of the art into the same dimensions that we employ in our evaluation reports:

  • Services

  • Technology

  • Intangibles

Every portal vendor will say that everything below is possible with their platform. That's because portals are, if nothing else, web application development platforms. Given enough time, money, and risk aversion, you can get them to behave almost any way you want.

The key thing is what a product wants to do natively. Each vendor with a mature offering should be able to provide these capabilities out of the box, without you having to customize the product first.

Portal Services

Generate short, meaningful, and permanent URLs

This is the web after all, even if the portal is running on your intranet. Good URL practices translate into better search results and ranking, easier use in printed media and e-mails, as well as fewer problems with broken links when technology changes. And technology always changes.

Replace select portal functionality with third-party services

You may want to plug in a third-party workflow provider or replace the incumbent search engine. You should be able to do this easily, without worrying about complex integration.

Natively provide lightweight collaboration services

Self-evidently useful for departmental project teams, simple collaboration should be included in any portal product. Collaboration tools cover a wide range of functionality, from discussion groups, wikis, project areas, and even the concept of presence.

Easily support arbitrary content and data models

This means your content and data can be organized according to your own requirements, effectively enabling you to leverage existing investments in information architecture.

Navigation controlled by business users

This removes developer bottlenecks and empowers the business folks to change the navigation as they see fit. Also, the portal should allow designers to break out of the simple document-directory-based navigation paradigm.

Search all of different content types within the portal repository

Just like using the popular Google search engine, your search should not be confined to a subset of content, but rather work across all the content that resides in the portal.

Integrate with third-party Single Sign-On solutions

Security, identity management, and ease of log-on are always important, but most organizations have already made significant investments in this area, with many having dedicated resources doing nothing else than managing user directories (e.g., Active Directory or LDAP). The portal should be able to leverage this, as well as any existing security infrastructure in place, while enabling the user to avoid logging in twice.

Technology

Application Server freedom

At some point you may decide to change the application server or middleware running underneath your portal. This change should not affect your portal. Refrain from writing proprietary or vendor-specific code and you should easily be able to switch platforms. This is particularly germane in the Java world.

IDE of choice

Developers can be a talented, but high maintenance participant in your portal project. Letting them use their favorite tool for development surely makes them more productive.

Fast installation

First impressions matter and this should be a good one. A fast installation accomplished in a couple of hours can help the project move along to the real work of helping the business.

Control configuration management and deployment

Moving code and configuration changes among different environments such as staging and production should be possible in a simple, controlled manner. An important detail here is that you can deploy changes and also roll-them back again, without having to deploy everything from scratch. Modifications made in one environment should not have to be redone in another environment, but rather a simple deployment should suffice, ideally without restarting the portal or appserver.

Easily expose application data

Without writing code, business users should be able to expose application data throughout the portal. This could be customer information leveraged by the sales team or inventory data used in the logistics department. Application data is valuable and a portal should provide a simple magnifying glass into the organization. (Of course, true application integration is another matter.)

Better than linear scaling

When you grow your portal installation you should be able to benefit from economies of scale, so that each added server or cluster member should provide synergies towards a faster user experience.

Intangibles

Community rating of portlets

All vendors and open source communities brag about the depth of available, 3rd-party portlets. Reusing and sharing components is already a great idea, but without community ratings it can be prohibitively difficult to assess the quality and usefulness of available portlet code.

Widely available community support

Whether formalized in a user group or using an informal network, community support is a fast and effective way to get answers to your questions. Moreover, location still matters. Local consultants that can support and guide you can make a decisive contribution to your implementation.

A Word About Standards

Vendors may say, "don't worry about URLs and communities, since our wonderful standards support guarantees your investment."

Sure, unlike most other adjacent technologies (such as content management), the portal marketplace boasts many relevant technology standards. However, I encourage you to look beyond industry standards and leave it to the vendors to fight about who has the best implementation of JSR 168, BPEL, EJB, SOAP, and so forth. Don't get me wrong -- these standards matter and are helpful -- but you should look at the market from a broader business and technical perspective.

Final Advice

I intentionally do not crown vendors for each area covered. Different vendors perform well in different areas. So instead of discussing vendors here, I encourage you to start your analysis by identifying which scenarios you need to cover, and then moving on to researching enterprise portal vendors.

Use "state of the art" as your baseline and revisit it regularly during implementation. Your portal might get a stamp of approval from the toughest judges of all -- your colleagues.

Good luck with your projects!

Why do CMS projects go over budget?

By Janus Boye

Nobody likes it, but too many IT projects cannot deliver on budget. Frequently additional funds need to be allocated to meet the agreed deliverables and even then, features are often slashed in the final weeks to meet the budget or deadline.

Many articles have been written on reasons why IT projects in general are often more expensive than expected. See for example:

Common reasons? You'll recognize the litany: weak project management, bad planning, communication shortfalls, excessive focus on technology at the expense of business processes, and organizational problems.

Of course, these shortfalls also apply to CMS projects. But in this article I'll focus on the origins of CMS-specific cost overruns. I believe at the root of these overruns lies a few common myths:

  • "It is just a website / intranet / portal project – how hard can it be?"

  • "Our recent search and imaging projects went smoothly, so why shouldn't this one?"

  • "We know .NET, so we can easily implement any .NET-based CMS."

  • "The CMS has WYSIWYG editing, so our smart colleagues in the communications department don't need to be trained how to use the system."

  • "Our application developers understand our network and security infrastructure."

Underestimating complexity

Still today many senior level executives do not think a website or intranet is something special. To them, applying a CMS is just another project. It's about getting started, getting it over with, and then moving on to another project.

Many executives have family members, often younger ones, who publish their own personal website or blog and happily talk about how easy it is to maintain. When consultants and experts then arrive and claim that it is not so easy after all, it seems strange and hard to understand.

Introducing a content management system is far from an easy process. It causes many changes throughout the organization and affects nearly every department. A new CMS typically needs to be integrated with the existing IT landscape and even with "out-of-the-box" tools, implementation times rarely come in under 6 months.

Other additional important aspects are also often underestimated. These include:

  • Hardware requirements. This applies especially to content delivery (i.e. consumption) environments, which are often under-equipped, especially for dynamic page generation. And of course, the machines used by your content contributors need to perform speedily for famously impatient editors. In most enterprises it's not easy to procure additional or more powerful hardware at the last minute. Moreover, more hardware typically means more software licensing as well.

  • Additional modules might actually be needed after the initial deal is struck. CMS vendor salespeople are just as candid or opaque as other software salespeople. They'll do what it takes to close the deal, and they may ink a contract without telling you that additional modules will be required for your project. Sometimes these modules can be both expensive to buy and complex to implement.

  • There are constant requirements to patch, upgrade, revise, and improve almost any content management system. Your initial deployment rarely makes people happy; expect to really hit the mark on version 2 or 3. This leads to consistent implementation costs over the lifetime of the system, which is one of the biggest hidden expenses, and potentially a major resource drain.

  • Varied IT support is needed. Integration with the existing IT landscape entails content and application integration, but also working within the existing network and security infrastructure. To do this well, you need diverse IT talents on your CMS team, including system and network administrators. Particularly in a major enterprise, experienced application developers alone will rarely cut it.

  • The discipline is new and complex. Content management -- especially Web content management -- is a relatively new discipline with a wide variety of approaches for solving basic problems. Vendor techniques and established operational patterns are much more diverse than in, say, the document imaging community, where technical and organizational norms have ruled for some time now. As Enterprise Search Report readers know, search technologies are also deceptively complicated, but amazingly easy to test: just install, index, and show query results. The results are good, or not. No CMS project of any meaningful size ever works that way.

Inexperienced project team

The lack of norms and patterns cited above gets compounded by inexperience. In most CMS projects almost nobody on the project team -- from IT to management -- has actually implemented such a tool before. Here's where an outside integrator can certainly lend expertise, but your implementation partner might solely have experience with another vendor, or an older and quite different version of the vendor's product you chose. As readers of The CMS Report know, even dot-releases can bring major changes.

This is the background for one of my old rule of thumbs: A system integrator rarely makes a profit until the 3rd project with the same version from the same vendor. Changes introduced in new versions -- or a loyal customer selecting a CMS that its favored SI does not know -- often causes the faithful partner to make an overambitious proposal, forcing them to charge high rates on any change request to break even on the project.

It is thus a potentially expensive proposition to become among the first customers deploying a new version. Nicholas Carr asks whether that "IT matters," since it does not offer any competitive advantages; I'll simply just say that there is a first-mover disadvantage in fast-evolving technology markets, most notably CMS.

I've written previously on selecting the right implementation partner. For this article I'll just say: make sure your partner has good references, with at least 3 of them using the same version as yours from the same vendor.

Many systems integrators are very technically skilled, with strong competences in Microsoft technologies, Java, or the LAMP platform. Same probably goes for your own IT group. Don't be naïve and think that this translates into a capacity to successfully implement any Microsoft, Java, or LAMP-based CMS without significant problems. The reality is unfortunately not that simple, since developers still need to learn how the system works with specific content types, its interfaces and methods, and in many cases also a proprietary development environment.

Unexpected training costs

Training matters. The majority of enterprise employees might be familiar with completing simple tasks inside a browser, but rarely so for editing text and images over the web. Your marketing and communication people may be used to writing for paper, but not for the online medium. The fact that most content management systems are rarely as easy as they seemed in the sales demo compounds the problem.

On the one side the vendor claims that very little training is required. On the other side your loyal colleagues are frustrated. They are doing the best they can, but it is very hard for them to grok a CMS and how it works. To get the new tasks, capabilities, and responsibilities properly anchored you'll need a significant investment in training. Most vendor documentation is not really geared towards business managers, and you have customized your CMS in any case.

Inasmuch as getting up to speed takes time for contributors, it's quite risky to get started with the training just a week before going live. This is late in the process to discover that the training needs were underestimated. You may cross the finish line with a couple of technology-enthusiastic colleagues, but after a while these staffers will become your new webmaster bottleneck. More funding will be required to develop and organize effective training sessions if you want to decentralize some of the tasks.

Remember that the necessary organizational changes can’t be "trained" and will take time to settle. You should also realize that the most significant aspect of the training, in particular for your non-technical business users, is not tied to a specific tool, but rather in getting them used to writing suitable text for the Web, applying metadata, and generally understanding how to use the new medium.

Be realistic – and think about value

Indeed, many enterprises face a rude shock when the 2nd year of their CMS project finds costs approximating the 1st year expenses. Experience from more mature markets (e.g. ERP, CRM) suggests that the majority of costs occur after an initial systems deployment. Be realistic, exchange experience with other companies, and avoid the surprise.

Methods such as Total Cost of Ownership (TCO) or Return on Investment (ROI) might be employed by your vendor or your implementation partner to justify the significant expense here. These models, simplistic or advanced, may not take into account all cost factors, and as such, a narrow focus on TCO or ROI can get you into all sorts of trouble if you use them as justification and then blow your budget.

Instead I urge you to focus on the value drivers in the project. What is the value for the organization to have a well run website? What is the value of higher quality content or better online customer service? What drives this value and how can it be optimized?

Costs are important, and a smart manager will estimate them properly and contain them carefully, but a visionary manager will take a wider focus on value.

Make The Group The Guru

by Janus Boye

In a recent Harvard Business Review article called "Your Company's Secret Change Agents" , the authors suggest a bottom-up approach to creating lasting organizational change.

Of course, content management, intranet or really any digital project can change organizations dramatically.

Typically "champions" are educated and trained with the intention that they should be change agents for the rest of the organization.

The authors argue that

"too often, these individuals generate unconstructive dependency from their teams."

I would agree with this, having often seen a "them and us" mentality in projects.

Instead the authors suggest to make the group the guru.

As they say:

"Because the innovators are members of the community who are 'just like us,' disbelief and resistance are easier to overcome."

Portal Software: Passing Fad or Real Value?

By Janus Boye

We have been here before. A few years ago vendors were touting personalization software. A major buzzword of the dot-com age, personalization would ostensibly solve a series of business problems and enable a new IT paradigm. Many personalization projects failed due to lack of adoption, long implementation times, problems with the technology, lack of clearly defined business goals, integration and testing difficulties, and cost overruns.

Today many companies are experiencing the exact same difficulties with a new breed of enterprise software called portal software. Nearly every major software vendor has created an enterprise portal solution, which in many ways has replaced their personalization hype. Certainly the CMS market is young and immature, but I would also caution buyers that the market for portal solutions is younger and much more immature.

In fact, I question the whole concept of portal software. Based on a series of issues I have found with portal applications while working on CMS projects during the last few years, I am not convinced this is an investment each and every company should consider.

Brief History

A few years ago the term "portal" emerged in connection with major websites such as AltaVista, Google, MSN and Yahoo!. A portal offered a single entry-point to content and functionality. In today’s world we have portal software, which is roughly an attempt to recreate Yahoo! within the enterprise.

But you should consider the question: What does a portal really mean for my enterprise? Your answer will vary depending on your company. More importantly ask yourself: What is the difference between a Web site and a Portal? In this article I would like to challenge the commonly-held notion that you need portal software to create a widely functional Web site.

Strengths of portal software

In my view there are primarily two benefits that portal software can bring:

  • Enabling business users to visually arrange design elements (via pluggable portlets).
    Portal vendors have taken steps towards the holy grail of enabling non technical business users to dynamically arrange and rearrange informational elements on a page. In practice, however, there is little evidence that portal users routinely modify default interfaces, and the overall design of content pages tends to resemble a stack of cards, which can be more or less usable depending on circumstances.

  • Enterprise Content Integration.
    Portal software can certainly be useful in an intranet where the company wants to present a unified interface to many back office systems and provide a single sign-on to those systems. In my view this is probably the best use for portal software today. The important thing to remember, though, is that you are unifying the interface, and perhaps creating a crude "dashboard," but not actually unifying the underlying logic and content models unless you invest in more costly and difficult application integration.

    Nevertheless, for true content integration across multiple repositories and applications, most experienced developers will also prefer to work with portal software rather than a CMS. Portal vendors -- either themselves or through close partners -- bring stronger integration facilities with superior options for rapid development and deployment.

    Fortunately, today technical standards are emerging that are relevant for integration. JSR-170, from the Java community process, specifies a standard API to access content repositories via Java 2, independently of implementation. JSR-168 is also relevant as it aims to enable interoperability between portlets and portals. Unfortunately few vendors support these, and for the Microsoft-based world there are still no good answers. Both were designed by committees so contains the basic minimum set of functions supported by each major vendor. In my experience, to make use of all the really useful portlet features that a portal vendor can offer, you will end up with a non-standard portlet.

Weaknesses with portal software

The problems with today’s portal solutions come in different flavors; business and technical.

Generally the market for these solution is immature. While portal vendors might have used various tricks to make the version number seem high, prepare yourself for challenges with unproven technology. New versions may or may not be backward compatible, service packs might require significant recoding, and do not expect the technical documentation to be entirely correct and updated. Of course, licensees say many of the same things about CMS products, but generally, portal tools are newer still.

Here is a brief overview of more weaknesses, starting with potential business shortcomings.

  • Costs.
    Most portal software is based on an application server (either MS-based or J2EE). As application server pricing has plummeted, vendors have tried to reclaim what was lost with increasingly higher licenses on portal software. Pricing for commercial portal software is typically done either per CPU or per user. Keep in mind when you sign a software contract, that implementation costs for a portal project are typically at least 4 – 5 times the initial license fee.

  • Usability.
    Out-of-the-box most business users will be intimidated by the user interface offered. If you speak to existing portal users they will most likely call their portal software a nice demo, but very cumbersome to work with. Arranging and placing portlets on major sites can be a very time consuming effort. As the site structure grows, the navigation load time can increase dramatically. This is a problem web content management systems experienced years ago, but most have solved today. If you add a new menu item or rearrange the navigation you might be forced to place the portlets from scratch again. Most portal interfaces were far from designed for business users but instead IT staff.

  • Consider the screen above (click for larger version), an out-of-the-box installation of Sun Portal with FatWire Content Server. Users require significant training before they are comfortable working in this super user environment.

    Among other problems, the occasional business user will find it very hard remembering what all the button and functions do. Of course, businesspeople may have the same difficulty using the applications (like this CMS) in a stand-alone environment, but in the latter case there is at least some context and the opportunity for in-line explanatory text that the squeezed portlet environment typically does not afford.

  • Bookmarks.
    With freedom to rearrange the design of the page, freely move portlets around, many portal users have realized that this comes at the expense of working bookmarks. This means that after brief time, visitors cannot expect their bookmarks to work, as the portlet they bookmarked might have been moved or might contain something new and entirely unexpected. Effectively the only page you can reliably bookmark is the frontpage. Any bookmarks below this level may not provide the expected result, unless you during the implementation spend time constructing the URL in a way so that bookmarks work. The problem with this implementation effort is that it runs counter to the provided flexibility to freely rearrange and reuse portlets. And unless you invest time on it, all pages will also have the same title, which makes it even harder to work with bookmarks.

Technical weaknesses

  • Performance.
    Working with portlets typically requires thousand lines of code to be executed quite often, while the end result may be just a few lines of HTML. This puts strain on servers and requires projects to invest considerable time in caching and performance tuning. . Many firms acquire expensive high-end hardware to run portal software. It is a fact that most content is not dynamic and as such there is no need to deliver it dynamically. Do consider mixed publishing (dynamic and static) as an option to reduce the hardware investments needed.

  • Obtuse URLs.
    This is related to the bookmarking problem above. It seems like most vendors do not care about human-readable URLs. Well, humans do. Portal software is notorious for incredibly long URLs. This has several drawbacks, not the least of which is search engine optimization on public sites. Consider this URL from the BEA WebLogic-driven TDC Kabel TV, or this IBM Websphere Portal Server URL from the Copenhagen Stock Exchange.

Issues of integrating portal software with your CMS

Portal vendors have discovered the importance of content management and tackled it with different approaches. Initially most portal software was entirely without any content management functionality. This is no longer the case, as vendors like Plumtree cried out for "no empty portals," and licensees came to see the need for a concurrent CMS investment.

To get a larger piece of the overall pie, portal vendors have developed strong alliances with major CMS vendors coupled with either 1) acquiring a CMS package (done by IBM, Plumtree, Broadvision, and Microsoft), or 2) building their own CMS (e.g., Oracle and to some extent BEA).

For the business user, working with CMS and portal software typically means working with 2 different interfaces. Yes, these can be integrated into one, but in my experience this can be quite difficult and therefore few licensees actually do this.

For a web editor this must lead to the question: Why is a CMS not enough? You can draw a line between the two, as many have done, by saying that the CMS is responsible for managing content and the portal for delivery. This leaves an important grey-zone for the business user: Where do we place navigation, site structure and preview? How do we ensure that the non-technical business user can control the navigation and preview content with the actual site layout?

A really nice CMS feature is the ability to edit text directly on the site -- either through in-context or pure in-line editing. When put together with a portal solution, this is extremely tough to implement, as you then will need a way to write changes from the portal to update the CMS. What this means for many users, is that a key CMS out-of-the-box feature can not be used. There are techniques that a CMS vendor can use such as “preview this page in the portal” or using a preview version of the portal in the same editorial environment as the CMS. With the use of portlets to delivering the content to the end-user, this still makes the content manager’s job difficult as she will never be able to preview all the combinations that an end-user might select and this means the content manager can never answer a basic question; “how is this going to look on the page?”

Reconsider the business requirement

In fact most site visitors do not require portal functionality. This is especially true for public Internet sites. I have been in many presentations where I have been asked about providing the end-user with a “My Yahoo” type experience. When I ask how many customers they surveyed to get this requirement the answer is usually “what survey?”

The last time I came across this was for a local government council office. Most visitors of local government sites don’t want to rearrange their own pages and portlets. They just want to know when the next garbage collection will be or what times the local swimming pool opens. If my local council proposed offering me a portal, I would tell them to spend the money on a decent search engine. Forget about the personalized portal experience – just show me the right content and show it to me quickly.

Most vendors now speak to the Intranet use case, or the holy grail of an "Enterprise Information Portal," or EIP. Consider, though, the top features repeatedly requested on corporate Intranets:

  • enterprisewide search

  • employee directory

  • common guides and handbooks

  • instructions and other HR information for new employees

  • links to commonly-used internal applications

Do you really need portal software to accomplish these? Maybe you should start by creating a small-p portal deploying a simple website on top of any existing Intranet sites, and invest in big-P portal software only after you have put in place successful processes for publishing and aggregating high-value, highly-sought information. You may find you don't need portal software at all.

In any case, don't use the crush of a software deployment as an excuse for getting organized about the information needs of your employees -- you'll probably just fail on all counts.

This is because building and maintaining any Web site or intranet requires work. Writing quality content requires even more ongoing work. Using portal software is not a silver bullet. It is complicated and will require major efforts to get up and running and to maintain. Presented with proper alternatives the business case would most likely benefit immensely from reconsidering the requirement for portal software.