Thoughts on Content Management and Open Source.

Friday, July 28, 2006

Open Source Governance within the Enterprise

I recently spoke to a friend of mine, who works for a large financial services company, about their open source policies and practices. The big financial services companies are, in general, slightly ahead of the curve in their use of open source. That, and the fact that they are also highly regulated and have a potential high risk exposure, makes financial services a good place to look for open source governance models. Why do you need an open source governance policy and procedures? Because open source software can be acquired differently than commercial software. Unlike commercial software whose acquisition can be regulated as it goes through a budgeting and accounting process, open source can be freely downloaded and used without institutional awareness.

Like it or not, your company is probably using more open source software than you are aware of. In fact, if you are building web applications in anything but .NET, I would be surprised if you didn't use some open source framework or development tool in your custom application. You would be crazy not to. Companies that have not adapted to the existence of open source usually have what I call a "flavor of the month" architecture where the next application is built on what was written about in the last post on Slashdot or The ServerSide. I am not saying variety is a bad thing. There just needs to be a reason to use something different - like different requirements.

Here are some things that this company does to manage software in a world where open source exists. I have heard similar processes at other major companies that I have spoken to so this company is not unique.
  • Define what open source is. They exclude Linux (which they consume like commercial software with support contracts and all) and open source software bundled in commercial products.
  • Accept that open source is out there and has potential value.
  • Sponsor a cross line of business open source review board. This organization is responsible for responding requests to use a new open source application.
  • Manage a list of all usages of open source software within the firm. If you want to use an open source application, for research or production purposes, you consult the list for the software and version that you want to use. If you find it being used, you communicate your use to the "open source librarian." If it is not currently being used, you submit a request to the open source review board. They will tell you if there is a preferred alternative or put it on the list.
  • Publish a handbook explaining the policy and processes around open source software.
Does this type of program scale down to smaller size companies with less technology discipline than a large financial services company? I would say yes and, in some ways, it should be easier. There does not have to be a dedicated review board. An enterprise architect or architecture group should have an awareness of what software is running on the network: commercial and open source. This knowledge will help them:
  • Standardize on some core frameworks. This will reduce maintenance costs and help with interoperability. Again, homogeneity is not the goal. Especially in a web services world, applications do not have to be built on the same platform. You just need a better excuse to deviate from the standard than "I wanted to see what all the hype was about for Ruby on Rails."
  • Get to short lists of components quicker. It is easier to select from a list of pre-qualified options than comb source forge or Freshmeat every time you want to use a component.
  • Reuse your understanding of licensing implications. There are many open source licenses and some play better together than others.
  • Identify internal experts. If you know that an application was built on a technology, you can ask the developer who built it what they thought of the technology and best practices.

So, if your company is using open source software (and, chances are, it is) it is best to get a handle on what is being used and how.

Labels:

Monday, July 24, 2006

Google is in my kitchen

I have taken a certain amount of pride in not being swept up in the Google craze. Yes, Google is the only search engine that I use and when I want to get directions, maps.google.com is the URL I enter. However, I have held back from getting a GMail account or setting up a Google Calendar. That took a lot of will power last year when people were introducing themselves as "Hi, I am so-and-so, do you want an invitation for a GMail account?"

What is my beef against the Goog? Nothing really. I have just had the same Yahoo! mail account for 8 years and I can't imagine giving it up. In fact, my loyalty to Yahoo! has become a cornerstone of my thinking about digital businesses. The idea is that you can't compete on functionality because it is less expensive for a competitor to copy your functionality than it was for you to build in the first place. To bring an innovative feature to the market, it takes a lot of design and trial and error. When you copy a feature, you get to learn from your competitors mistakes and take a more direct route to a better solution. What keeps customers is data which translates into switching costs for users.

Email is particularly interesting because it is not just the inbox. That can be easily imported. It is the entry for you in all your friends and associates address books. So, when you change your email service provider, you have to tell everyone your new address and they have to update your contact information. I know there are services like Plaxo but they creep me out too much to use. As an aside, never send out the mail address that comes with your ISP. That will unnecessarily tie you to that ISP even if there is a better option out there. Most of the current AOL users that I know don't care for the service but just keep paying AOL to keep their email address. Most colleges and universities have free email forwarding services for alumni. If you are not totally ashamed of your alma mater, you might consider taking advantage of their email forward service.

So, back to Google. Hell or high water, I am keeping my Yahoo! mail account. But, recently Google has been working its way into my life. I just got another Dell laptop and, what do you know, Google Desktop was pre-installed. In setting up the computer, I anguished for a couple of minutes over whether to uninstall it ("It is going to slow up my machine." "It may help me someday and, besides, I want to know what all the fuss is about.") Google Desktop stayed. Then a colleague from CM Professionals sent me a link to a Google Spreadsheet. Of course, the first step was to create an account.

At first, I thought the temptation of Google was threatening my data theory. But now I am thinking that it is supporting it. Google is trying to lure me with data that I don't have: indexes of my local files, spreadsheets that my colleagues created. Once they hook me in to registering and using Google tools to collaborate with my colleagues, they will be able to offer me other services. I would have to say it worked. I registered with Google.... Using my Yahoo! mail address ;).

Labels:

Tuesday, July 18, 2006

Migrating from commercial to open source CMS

I just saw a post on the Bricolage developer list asking if anyone has any experience migrating from Vignette to Bricolage. I don't know the context of this migration but I am definitely seeing a trend. Two of our current customers are hanging up their mid/upper tier WCM licenses in favor of simpler open source applications. We have one customer who is migrating from Rhythmyx to Plone and another customer who decided not to use their corporate standard of FatWire for a new web property they are launching. They are using Bricolage. Interestingly, cost was not the primary factor. Both clients wanted to have something simple to use and and easy to extend.

Labels:

Thursday, July 13, 2006

IBM focuses on Drupal

My colleague Ben Menoza, just passed on this article about IBM Developer Works analysis of open source and cheap software to build a community website. They looked at Drupal, Ruby on Rails, Mambo, Typo3, Movable Type, WordPress, and TextPattern. Based on their requirements, Drupal came out ahead. In particular, they recognized ease of installation, shallow user learning curve, user management, the community, and the flexible theme framework.

Labels:

Wednesday, July 12, 2006

Open Sourcing Windows?

A reader sent me along this really interesting post on a Microsoft employee blog floating the idea of open sourcing Windows. The comments are insightful with a little bit of zealotism thrown in here and there ("No real Free-Software developers would dare even look at it, in case they got tainted"). The general consensus (if there is one) seems to be that open sourcing older versions Windows would be useful to people still running those operating systems and getting little help from Microsoft or other software vendors who are not excited about supporting outdated versions.

optaros.com on eZ Publish

As is the case with most internal projects when staff utilization on client work is through the roof, our project to deploy www.optaros.com on eZ publish seemed to go on forever. But, thanks to some really dedicated individuals, we finally got the project over the line and we are live. With our first CMS based release of www.optaros.com[1], the retail view of the site does not change at all except for URL changes (except if you are a German speaker in which case you will be thrilled to know that the whole site is translated into your favorite language)

Being an internal project, a lot of people were involved during short bursts. I think in general, they found the eZ publish syntax easy to pick up given enough examples. Our business users had no trouble learning the user interface. Other features we like include easily configurable content classes (through the UI, you can create custom content classes) which we use heavily. Among the content classes we created were Partner Company, Person, Case Study, Promo, Career, and White Paper. This allows us to surface different pieces of content throughout the site with different views. For example, the same Person class is used to contain the information here as here. Localization and Versioning are excellent. Also eZ publish has a nice way to handle multiple sites including different language translations of the same site or totally different sites. We could have done a domain based mapping (i.e. http://www.optaros.de rather thand http://www.optaros.com/de) but we decided against it for various reasons.

One thing to be aware of when deploying an eZ publish site. Performance. Don't let the "PHP" fool you. eZ publish does a lot of work on the rendering side. If you look at the code, you can kind of guess why. There are lots of includes and text transformations. For example, when you have an HTML text area, it is really stored in XML so there is a view of that field that you have to invoke to render the XML as HTML. From an architectural perspective this is very nice. It means that you could override this view for a different device such as a PDA. However, if you want to host on really really cheap hardware (such as a virtual host with 256MB of RAM), this level of abstraction is costly on limited server resources. eZ publish has lots of tuning parameters. Some of the best documentation is on the eZ publish forum here and here. You definitely need a PHP accelerator such as eAccelerator or APC. You should configure template, view, and, if necessary, static caches. Still, hosting a dynamic ("fried", not "baked" as Tony Byrne would say) on really weak hardware is ambitious no matter what technology you are using.

Overall, eZ publish was a good choice for this site. It might be for your as well but it all depends on your users. eZ publish does not have an in-site editing model. That is, there is a distinct back end for managing content and a front end for viewing content. This made sense to our users. They were able to map pages they saw on the "retail" side with the page tree on the management side. However, I have seen business users who want to edit the content that they see on the fron end right there. Some of the other CMS that do this nicely are: TYPO3, Lenya, Plone, and Joomla.


Notes:

1: I know you are asking yourself, how could a company that Seth Gottlieb works for not have a Web CMS? Here are the answers.

  • Most of the poeple in the company know HTML and source control. Our marketing person could usually find someone to make a text change.
  • We do all the formatting in CSS. This allows us to make a formatting change in one place and have it reflected all over the site.
  • We like to experiment with the design a lot. It is easier for a creative developer that can cut HTML code faster than you can use a word processor to work in static HTML than presentation templates.

But now times are changing. We are around 60 people now and growing rapidly. Our marketing department needs direct control over the website without being dependent on consulting resources. We are publishing our site in multiple languages (French is coming out soon). We get all that from eZ publish.

Labels:

Monday, July 10, 2006

Sean Kelly's Better Web Application Development Screencast

Sean Kelly, from NASA's Jet Propulsion Laboratory (no, not Sean Kelly of cycling fame), has a funny screencast comparing web application frameworks. While there is a clear bias toward Python and Zope (the JPL used Plone for the Mars Rover Site), it is good entertainment mixed in with some very valid points. So, if you like Python, or if you like Java and have thick skin, it is worth a look. It reminds me of my days back in college trying (fruitlessly) to make the case for IBM PC DOS over my roommate's Mac 512. Hearing myself say "C Colon Backslash Data Backslash ... Backslash ... Backslash," I knew that every "Backslash" was a another hole in my argument.

Similarly, Java is not as efficient as many of the newer frameworks. Moving most of the code into XML configuration files has not really solved the problem, just moved it. Sean calls all the XML work that you need to do with Java nowadays "XML Situps." I am not a total Java basher. But I do think that Sean raises an excellent point: if you want fast turn around in your development cycle (code, review, fix), which is what is good for web application development, an interpreted scripting language gives you an edge over a compiled language.

Noticeably absent from this comparison is anything from the PHP world. Sean just reviews J2EE, Ruby on Rails, Zope (Plone), Django, and TurboGears. We have a couple of project teams using the Symfony framework and they love it.

Labels:

Saturday, July 08, 2006

My Washington Gilbane Slides

Here are the slides from my presentation at the Washington Gilbane Conference on Content Technologies. This was the first time Gilbane held a conference in DC and it was the first one to have an industry (in this case Federal Government) focus. I was only able to stay one day but the sessions I attended were good. The crowd was a little small but they seemed pretty engaged. I wouldn't be surprised if this turns into an annual event.

Google Hires Plone Founder

Alexander Limi, co-founder of project and Plone and the main person behind the Plone user interface, recently announced that he has accepted a job offer at Google where he will join their user interface design team. When I first heard this news, I was concerned about the version 3.0 release which is designated as a UI focused release and which Limi has a central role. I am somewhat comforted in knowing that Limi will actually have more time to work on this effort than he currently does thanks to Google's generous one day a week policy. Google already supports many open source projects through its Summer of Code program

What about Limi's company Plone Solutions? Limi will remain on the board and remain active on projects that Plone Solutions is involved with (most notably LinguaPlone.)

I can see why Google recruited Alexander Limi. Both Limi and the Google design teams appear to share the same design values of simplicity and cleanness. Limi is famous for taking out more code than he puts in to keep the UI from becoming clunky, uncluttered, and non-compliant with accessibility standards (Plone is one of the most accessibility compliant CMS available. So much so that many government organizations use Plone to ensure their compliance). Also, Plone's focus on accessiblity has a side effect of making the generated HTML particularly usable by search engine crawlers.

So, I wish Alexander good luck on the new job and I am sure that the Plone community will keep him honest on his promise to stay involved.

Labels: