So you use Google Analytics. It’s free and it’s pretty cool (when it works). You can find out how many people have visited your site, where they are coming from, etc. So my question is… now what? How does that really help your business?

I know a ton of people that use Google Analytics and the like for their business web site. Don’t get me wrong, some of the information is useful at a high level, but it doesn’t give nearly the insight needed to make any real business decisions. For example, I can’t even tell if a web site visitor is coming from a particular company (or if they are surfing from home). Being able to tell that 10 people from Novell have visited my site in the last 3 months and spent a total of 70 hours browsing the site would be a huge trigger for a business decision (i.e. find the nearest sales person to call Novell immediately).

Another important component missing is that when a sales guy goes to make his first call on someone that has registered on the web site, they are flying blind. They are left with very little information on what that person is really interested in. If the sales person is lucky, the person who registered entered in enough information that they can figure out generally what the person is interested in talking about (so better than blind, but let’s call it one eye open). What the sales person really needs is insight into what that person is really after and how informed are they already (i.e. reading between the lines before making first contact). What pages have they viewed on the web site, did they download the whitepaper on how product compares to competition, how long have they been coming to the web site and how frequently, etc. There is no way to get this information from Google Analytics.

Seems to me that what normally happens when management gets a hold of the login for Google Analytics is that marketing gets yelled at for “not driving more traffic” to the web site and the web designers get yelled at for the “web site not being sticky enough” which has no business impact other than lowering moral.

I stumbled across this great blog by Kirk Crenshaw about how marketing and sales are at odds with one another. We come across this all the time where the sales team feels like marketing is not providing leads worth acting on and the marketing team feels like the sales team doesn’t put any effort into acting on the leads they provide. When in truth, both sides are right. As Kirk states, the real problem is “lack of communication” between both sides. Usually this is never addressed directly within an organization and is left for the smack talk at happy hour.

One of the big reasons for this communication disconnect is that neither marketing nor sales have visibility into what the other is doing. I think one of the reasons for this is that they are using completely different tool sets to get their job done which provides no integration between them. For example, in a typical situation where the marketing team is launching an e-mail campaign, how do they know if it brought the sales team any leads of value? Can the sales team even see that a lead came from a particular marketing campaign?

There are tools that can provide this level of integration (hint, hint). However, they are only part of the picture. The generals from both sales and marketing have to acknowledge the gap between their two teams and that they are on the same side. Only then can the sales machine really begin to hum (fueled by marking of course). The key is communication which has to happen from the top down.

The OSI deserves a round of applause today, as they announced their first approved attribution license. The original draft of CPAL (Common Public Attribution License Version) can be seen here, and was submitted by the folks at SocialText.

What is most important here, is not only that they’ve approved an “Exhibit B” License, but the timing of such an announcement. GPLv3 was recently announced, and for most of us in the SaaS/Web2.0 world, it landed like a great big thud, as it has no provisions for the Google Effect, i.e. Google mods open source code, and doesn’t contribute it back. Since they’re not “distributing” it, the GPLv2/3 doesn’t cover hosted applications as distributions and so they merrily fork away.

The SaaS loophole is essentially plugged with this new license for those that adopt it. Its common sense, but not so common to folks like Eben Moglen at the FSF which recently lashed out at Tim O’Reilly over his criticism of the GPLv3 loophole. Then again, no one ever accused the communists at the FSF of having common sense.

Congrats to the OSI and SocialText for their hard work. More information here.

To understand why standards fail, first have to look at what standards ultimately achieve which is choice of implementation/vendor for users. An example of where choice due to standards comes into play is choosing a web server verses choosing an AOP framework. When considering which web server to choose will be evaluating based on merits of the implementation such as reliability, cost, easy to use/configure, etc. When looking at AOP, the previous evaluation criteria come into play but also must consider the risk of being locked into a particular flavor of AOP provided by a vendor (i.e. AspectJ, JBoss AOP, etc.). If choose a particular vendor and then later decide move to another vendor, the cost of migration will be much higher since is not standards based will likely have to re-write a good portion of the work already done for the initial vendor to make it work with the new vendor. There are a number of other reasons use of standards based technology is good such as easier to find talent already familiar with the technology, larger pool of support resources, etc.

Hopefully everyone agrees that standards based technology is generally good for end users, so what’s the problem? The two main problems with specifications are 1) the process takes too long and 2) the end result does not meet the needs of the users. Both of these problems generally stem from the fact that standards bodies are almost always driven by companies. These companies favor their business interests over the interests of their customers (as expected).

Why specs take forever

Any time you bring people together to make joint decisions it is going to take a while to reach consensus. The more people you add, the longer it takes. However, often delays in reaching consensus on specification items are not based on differences in technological philosophies, but based on how close vendors are to already having that item already implemented within their product. If they are a long ways off and know that their competitors are close, they will delay it (technology filibuster). This allows the vendor to catch up with their development so are not playing catch up in the market after the final spec is released.

I personally think an example of where this occurred is with the EJB 3.0 spec. This spec basically kicked off in earnest early 2004 and had two draft releases within a year. At that point, the spec was in pretty good shape and seemed to be not too far from being completed. However, it was another 14 months before reached final approval. If you are not familiar with the EJB 3.0 spec, it would basically call for an implementing vendor to have some sort of ORM technology and an architecture for implementing annotations (which was AOP based for most vendors). There was a particularly large vendor participating in the spec that did not have these technologies available internally when the drafts were released. I’ll let you connect the dots…

Why specs are weak

Often specifications are produced that cover such a small set of functionality that they are relatively useless. Specs that fall into this category usually started with much loftier goals, but the feature set got whittled away until it was left without any bite. One of the main reasons this happens is because vendors cannot agree on features that they believe they can or should implement. In an effort to move the spec forward, the group will concede to either removing the item from the spec (or when we’re lucky, mark as optional). Again, the vendor wanting the feature to be removed either does not want to be left out in cold to play catch up with everyone else or the vendor wants to leave the feature out of the spec (in the case they already have it implemented) so can be considered a “value add” that they can charge a premium for. A good example of the “value add” angle is there not being anything mentioned in the J2EE spec for clustering other than the ‘distributable’ tag within web application deployment descriptor. Most modern application servers support clustering for web applications, ejbs, jms, etc. So only reason I can see for this not being standardized is so vendors can charge more for their “clustered” version and locking users in.

Impact of delayed and weak specifications

In the big picture, users just need what they need to get their job done. If they can’t find that within a standards based technology, they have to find it elsewhere. Spring is a good example of this. J2EE 1.4 was so bloated and complicated that enterprise application developers started looking for alternatives that allowed more flexibility and ease of development, testing, and deployment (i.e. don’t have to buy 5 books to understand how to use the technology). I feel that Java EE 5 could have been a viable alternative to Spring and seen wider adoption if it had been released in 2005. Since JEE5 took so long, Spring gained wide adoption and now is the defacto standard IMO.

So when see vendors complain about non-standard open source projects becoming the defacto standard, can’t help but think is their own fault. After reading this blog from Pierre Fricke of Red Hat, I wonder if the commercial vendor representative who spoke out about this even understood the reason why this trend was occurring.

I personally believe in standards and have been an expert member on several JSRs. However, if the members of the standards bodies do not start recognize that the developer community is less tolerant of lengthy delays in releasing and won’t accept specifications that don’t adequately meet their needs, the developer community has alternatives and will use them. For the commercial vendors that don’t want to ultimately loose out entirely, they may want to consider changing their approach to working on specifications.

Both Dave and now Matt have posted blogs on open source companies that compete amongst themselves, instead of going after the big money their proprietary competitors hold. I do agree with them, that if an OSS company is focusing on its OSS competitors, it will likely fail as a venture. Common sense dictates you follow the money, and in most markets, “the money” is in the pockets of the proprietary players.

Why does this happen? The main benefits, in my view, of adopting an OSS business model are: a/ disruption and b/ commoditization. I believe much of the OSS vs. OSS competition we see is based on fear; the fear of not being able to compete with an equally disruptive force, and losing control of the rate of commoditization in the space. After all, OSS companies typically don’t fear their proprietary competitors (they’re easy to pick on), but an OSS competitor armed with the same tools as you, can wreak havoc on a market, leading to the “race to the bottom” effect – where markets are commoditized to the point of meager profits. Hence, the goal of most OSS companies is to control the rate of a/ disruption and b/ commoditization – control those rates, and you control your market share and revenue growth.

Dave suggest a few examples of some companies that ignore other OSS vendors in their own markets and are winning:

Who does Zimbra target? Exchange, not Open-Exchange. Who does Alfresco target? Documentum and Microsoft Sharepoint, not Drupal. Who does JBoss target? BEA and Oracle, not Jonas (or Tomcat or whatever.)

Interesting set of examples… The JBoss/Jonas story proves his point: At one time, JBoss and Jonas were similar in their technological merits. JBoss, however chose to ignore Jonas and target the big fish; IBM, BEA, Oracle. Where is Jonas today? RHT bought JBoss, dropped Jonas from their distribution, and Jonas flounders about somewhere in EU with Michael Hasslehoff fans. Clear winner: Jboss. Alfresco / Drupal is not apples to apples, so I’d ask where are the viable Alfresco competitors? Alfresco has cemented its leadership as the only viable OSS DMS vendor, as new entrants would have to deal with a high barrier to entry. Clear winner: Alfresco. Open-Exchange – I’ve never heard of them, and chances are in a few years, they’ll be relegated to be a niche player thanks to Zimbra.

So what is Dave telling us with his citations? OSS companies focusing on the proprietary competition win-out in the end, but if history is a guide, they also manage to squash their own OSS competitors by doing so.

Matt expanded on Dave’s point, and inched toward the monopoly topic:

[…] if a market only has room for one open source vendor, it’s not a market worth competing in. I’m not sure why VCs don’t get this, but I refuse to believe that the first open source vendor in a market is necessarily the best/the ultimate winner. The market is, or should be, too vast for any one open source vendor to consume all of it.

I don’t believe that the “first open source vendor in a market is necessarily the best/the ultimate winner”, but I do believe that the first one in a market raises the barrier to entry, effectively closing the door behind him. Would you want to enter a market against Alfresco at this point? How about competing against JBoss? (Heck, IBM had to go and buy Geronimo, just to sick some sort of leashed dog on JBoss.) Any takers on starting a new MS Exchange competitor? I disagree with Matt here, I think the VCs have it right – they’re looking at how your new startup plans to compete against FREE, and I’d love to be a fly on the wall for that pitch.

This remains an interesting topic for me, as I’ve always wondered if OSS business models by their very nature lead to monopolies and maybe oligopolies. I’d love to hear examples where they don’t – where, as Matt claims, the markets are vast enough for everyone to play.

I’ll note that there are interesting things happening in the server/network monitoring spaces and there’s JasperSoft/Pentaho as well. It will be interesting to watch how these companies grow and compete. My guess is that a few years from now, one OSS vendor in each of those spaces will exist, relegating its OSS brother to some insignificant niche.

Matthew Asslet has just posted a summary piece on 4 open source startups to watch. You can see the article here. There are some interesting open source companies on that list (We’re on the list). It’ll be interesting to see how we all evolve.

Its good to be watched.