A kinder, gentler open source CEO

CEO dinners are usually pretty airless affairs - when you get that many egos in one room, there's not much room left for oxygen. Open source CEOs are a different bunch. They don't have that kind of rabid/scary elevator pitch thing going where they have to convince you in 15 seconds or less to give them all your money.

This week I attended an Open Source CEO dinner put on by Andrew Aitken of the Olliance Group and Mark Radcliffe of DLA Piper. What struck me at this dinner was how relaxed and interesting it was.

Following the management maxim, "the fish rots from the head down" I conclude from my dinner that the open source industry itself is a kinder, gentler place. Here are a few thoughts on why this would be so:

• Collaboration is a business mindset. Open source CEOs don't see every other CEO/company as an enemy in their zero-sum strategy to take over the known software universe. They bring a community-minded approach not just to their technical work but also to their business activities.
• Open source popularity is based on customer pull, not PR push. The popularity of an open source company is measured by SourceForge, not by amount of hot air emitted by the CEO and their PR machine. I don't meant to imply that these CEOs cannot be as arrogant as their proprietary brethren, just that they don't get the opportunity to spout off if nobody is downloading their products. Proprietary company CEOs can spout off as long as they can find a VC to foot the bill.
  

The open source world is still a very young industry. Mainstream technology companies now have lobbyists and stadiums named after them and all the other trappings of established businesses. No doubt the day will come when even open source CEO dinners become dull and lifeless affairs, but I sincerely hope those days are a long ways off.

The Tragedy of the Corporate Wiki

If you want to see the possibilities and limits of Web 2.0 as they apply to the enterprise, there is no better place to look than a Wiki. In part because they are so easy to get started, they positively invite a fatal lack of planning.

Wikis start out wonderful but rapidly morph from a grand experiment in bottoms-up community to a wasteland of out-of-date marketing collateral. As such, they become exhibit "A" that the self-service concept only goes so far in IT.

Without up front planning, clear ownership and constant maintenance, the primary service offered by self-service IT is the ability to shoot yourself in the foot. David Precipio recently had a good post about the future of Wikis that got me thinking about ActiveGrid's own less than stellar corporate Wiki.

Six months ago, we launched a bold new corporate wiki that rapidly became an object lesson in why wikis get a bad rap. Here are some of the lessons learned from our own experiment in wiki-style self service:

1. Designate a wiki "csar": just like our communal refrigerator, every so often, someone has to come in with a big garbage bag and clear out all the stinky stuff.
2. Define required functionality: it is amazing what a wiki won't do out of the box. Ours doesn't keep people logged in on their computers, has bizarre navigation and an almost unusable search functionality. Some critical functionality for us is the ability to publish MS Office documents (particularly tables) directly to the wiki.
3. Pay for an expert who can set it up right: we are using Twiki, which needs someone with perl expertise to administer it and its many plug-ins.
4. Create a clear update process: in addition to an overall csar, there should be a clear owner for each section and a process for updating document on a regular basis.

Web 2.0 tools like wikis are just tools. Their value depends in great part on how they are applied. For Web 2.0 tools to be successful in the enterprise, IT will need to provide tested components, usable tools and a clear process that enables user self-service to provide a net benefit to the enterprise.

Adam Carson of Morgan Stanley made a similar point recently at the Office 2.0 conference (podcast here), when he pointed out that Morgan Stanley's use of wikis worked because of, not inspite of, heavy involvement from IT.

Ajax Needs Eclipse Like A Hole in the Head

Infoworld recently announced a new Ajax tool for Eclipse, called , RAP. While this is a logical step forward for the Eclipse community, it is an evolutionary dead-end from a Web 2.0 viewpoint.

The goal of enterprise Web 2.0 is to democratize the development of web applications by lowering the learning curve. Enhancing Eclipse does nothing to solve the fundamental skills gap between the Java "high priests" and the traditional application developers who are skilled in visual tools like Access and PowerBuilder.

Eclipse is the heavyweight champion of the heads-down Java server programming world. Ajax is the lightweight champion of the rich internet client world. These are clearly different tasks, so presumably would benefit from using different tools. Other than masochism, why would someone decide to saw logs with a hammer?

Given the cost and difficulty of hiring Java developers, putting them into the UI design role is a waste of resources. In addition, the skills that make a developer good at server programming do not necessarily translate into web page layout skills.

At ActiveGrid, our goal is to enable application developers to assemble web applications visually without needing deep technical skills in Java, Javascript, css, etc. This vision requires two components:

1. Studio for lightweight page assembly: Web 2.0 application developers need a visual and lightweight tool for assembling web pages - they need a DreamWeaver for Ajax.


2. Java server framework for seamless services integration: the web pages created by a Web 2.0 application developer should integrate seamlessly with a standard Java back end using something Json/Spring/Hibernate server.

While Ajax for Eclipse represents an incremental step forward, it is not at all clear that this is the best way to build Ajax clients. We are betting that the right tools for building Web 2.0 applications will unlock a wave of developer productivity within the enterprise equivalent to what simple blogging tools have done for web publishing.

SAP decides Chuck Phillips was right, buys Business Objects

There have been two high-drama tech strategy faceoffs in recent times: HP's contested acquisition of Compaq and SAP's decision to grow organically versus Oracle's acquisitive route. Just for the record, I called both of these wrong, believing that HP should stick to it's knitting and that Oracle was buying itself more trouble than growth.

In both cases, it turned out that treating the tech world as a maturing market ripe for consolidation was the right approach. HP has profited well by its Compaq acquisition, while Oracle has outpaced SAP thanks to its string of acquisitions.

As a board member of Reportive, I presented to SAP at the beginning of the year and were told that SAP had more than six internal business intelligence reporting products already. Clearly SAP is not lacking for BI technology. Instead, they are following Oracle's lead by acquiring companies with related technologies they can cross sell.

The challenge is that Oracle has Chuck Phillips, a former Morgan Stanley tech analyst superstar (fun fact: his phone number at Morgan was 1-800-MR CHUCK). Chuck has had the enterprise software acquisition market mostly to himself for the last four years and has made the most of it by cherry-picking his acquisitions, including Hyperion and Siebel Analytics in the BI space.

Oracle has also had four years to learn the difficult art of post-merger integration. Any bets on how well the integration between a stodgy German company and an arrogant French company will go?

Earlier this year, SAP politics drove away their internal technology wizard, Shai Aggassi. This effectively eliminated any possibility that their grow from within strategy would work.

Imitation may be the sincerest form of flattery, but in this case, it is flattery that is likely to cost SAP dearly to the benefit of Oracle.

ps. there are several good ZDNet articls on this from Josh Greenbaum, Dennis Howlett and Dan Farber