Haven’t posted lately. Not sure why (the kid’s summer vacation didn’t help much), but just couldn’t find the time. I read a good article on Acquisition and Integration in the September edition of Harvard Business Review (Rules to Acquire By - Bruce Nolop) which gives insight into how Pitney Bowes does acquisitions.  I especially liked the differentiation between “bolt-on” and “platform” acquisitions.

 However, even though all the points were right on, but I thought it was interesting that for the most part focused on things that need to get done before an acquisition takes place (probably makes sense given his CFO perspective).  I would like to see a similar article on “post-acquisition” since I have found that even if an acquision is made for all the right reasons - unless great care is taken for the first 12-24 months of the acquision to the integration process - the acquision will fail to live up to its promise (or just fail…)

Patents aren’t cheap, but they are important. Besides the time and effort, it will cost you somewhere between $5K-$15K per patent. As a startup you ‘ll need to worry about a patent portfolio that provides you with real value besides the obvious one - responding to a VC’s query about the IP protection you have, barriers to entry etc. So how do you go about creating a patent portfolio? Here are some of the considerations you should take into account when deciding what to patent:

• Freedom of action - what is key to making sure that you can build the products you need to be successful, without anyone being able to stop you.

• Leverage for partnering - allows you to provide unqiue partnership value that (hoepfully) people are willing to pay for. And it is cool to say “patent pending technology”.

• Block competition - keep others from doing the same thing. But don’t really count on this, since this is usually relatively hard. Given that there is usually more than one way to do things - how do you tell if a competitor is actually using your IP without a costly trial.

• Due diligence and M&A - worst comes to worst, you can sell your IP portfolio. However, this is really a last resort since patents without skills are usually not considered all that valuable as an acquisition. However some key patents can  increase your value in an acquisition.
• Generate revenue (and especially profit) - this actually a possible, but very difficult, business model to implement (e.g. Qualcomm as an example). Be honest with yourself - what are the chances that someone will pay big bucks for access to your patent portfolio….

The basic steps in creating your patent are:

• Invention - Discovering something that is unique and valuable and then deciding which parts are worthy of the time and effort of a patent.

• Competitive Analysis - Should be done by the inventor, rather than attorney, since the inventors understand the domain better than anyone. You can find helpful resources at http://www.uspto.gov/ and http://www.google.com/patents.

• Provisional Patent -doesn’t really provide protection, buty does allow you to set a date of inventtion. For the few hundred bucks it costs, it is usually worth it. In your provisional patent you should document as much as you can about the invention. Don’t forget you only have a year to submit the actual patent - don’t wait until the last minute.

• Write patent  - Expect to spend significant time writing, explaining and reviewing.

• Submit and wait - and decide where you would like to submit.

• Modifications - the patent office will probably come back with questions and issues (though not quickily, it can take a couple of years for a patent to be reviewed)..

Selling IT to corporations is hard (well, selling to anybody is hard) and requires a lot of resources (especially around presale - POCs, Bake-offs, etc.) So a lot of VCs are looking to the open source model for salvation - not Open Source in its purest (as published in The Cathedral and the Bazaar), but as a way to lower the cost and frcition in selling to the enterprise.

The logic behind it is that the techies (especially in larger organizations) will download the software, play with it, and start using it in a limited way. This can be either as part of a project to solve a specific problem  (e.g. we need a new documant management systems), or just something that interests them as part of their job (why pay for a FTP client and server if you can just use FileZilla, or pay for a databsae if you can use MySQL). So the thinking is that this solves the issue of both penetration (the user find the stuff themselves), expensive POCs (the users will create the POC themselves) and the length of the sale cycle.

The second part of the open source equation is that users will become an active and viable community - both recommending and improving the product directly. Linux is usually given as the prototypical example - with a vibrant user community and a large number of developer\contributors. The allure behind this idea, and the feeling that you have more control (you can modify the code yourself, no vendor tie in, a community of developers\contributers) is what differentiates Open Source from just Freeware.

So how does a company make money off an open source product:

1. Sell services - any large organization that uses a product wants support, and will pay for it.

2. Sell add-ons, upgrades, premium versions - once they get used to the product, they will be willing to pay for added functionality

What doesn’t seem to work is proving a dumbed down, or partial functionality product to get people “hooked” and them sell them the full version, or leaving out important features.

So should you turn your enterprise software product open source. Before you you do here are a few things to consider:

1. How will the techies find your product? Is it a well know category (so that when  they need to find a CRM system, and the search for vendors, your product will show up - e.g. SugarCRM,).

2. Do you really have a technological breakthrough - or are you trying to sell an enhnaced version of a well established product category? If you do have a real, viable techical breakthrough - your code is open and you can be sure that the first people to download your product will be competitors looking for the “secret sauce”.

3. There are a LOT of Open Source projects out there -  take a look at Sourceforge, there are at least 100K projects out there. You’ll need to put effort (probably at least 1 or 2 people) to make sure that you stand out from the crowd and start growing a user community.

4. The open source download to sale conversion rate is low somewhere between 1 in 1,000 to 1 in 10,000, so you have to make sure that you get enough users to be viable.

5. It is a one way street, you can make your code open source, but it is really impossible to take back that decision once it is out in the wild.

6. Choosing a license - GPL gives you the most control, but many organizations don’t like it’s restrictions. Apache license seems to be universally acceptable - but gives you almost no control.

7. You need to decide what you will do with user submissions - and make sure you get the copyright for everything that is submitted.

Mashups both for prosumers (a new term that I had first heard from Clare Hart at the “Buying & Selling eContent” conference) - high-end consumers and creators of content and for scripters (my own term since I am not sure what exactly to call these high end-users - for example the departmental Excel gurus that create and manage departmental Excel scripts and templates).

The search for tools that empower these domain experts to create applications without programming has been around since at least the 80s (i.e.  4th generation programming languages) - which led to various new forms of application creation - but the only one that has really evolved into a “general use”  corporate tool for non-programmers has been Excel (though not really a 4GL). The reasoning behind those tools was to put the power to create appplications into the hands of the domain expert, and you will get better applications, faster. One new evolution of these types of tools are Domain Specific Languages (DSL) that make programming easier by focusing on a specific domain and building languages that are tailored to that domain.

So much for the history lesson - but what does that have to do with Mashups and  Situational Apps?  Well they both focus on pulling together different data sources and combing them in new ways in order to discover new insights. Mashups seem to be the preferred web term, Situational Apps is a term coined by IBM for the same tyoe of application in a corporate setting.

These types of applications (and application builders) have a lot in common:

1. They all start from a data feed of some sort. either RSS or XML.

2. They focus on ease of use over robustness.

3. They create allow users to applications easily to solve short term  problems.

Many of these tools are experimental and in the Alpha or Beta stage, or are Research projects of one type or another (QEDWiki, Microsoft Popfly, Yahoo Pipes, Intel MashMaker, Google Mashup Editor). As these tools start maturing, I think we will see a layered architecture emerging, especially for the corporate versions of these tools.  Here is how I see the corporate architecture layers evolving (click on the chart to enlarge it):

I think the layers are pretty self explainatory, except for the top-most Universal Feed Layer which is simply an easy way to use the new “mashup” data in other ways (e.g. other mashups, mobile).

If you look at the stack there are players in all layers (though most of the mashup tools I mentioned above are in the presentation and mashup layers), and the stack as a whole competes very nicely with a lot of current corporate portal tools - but with a much nicer user experience - one that users are already familiar with from the web.

One important issue that is sometimes overlooked is that mashups require feeds - and even though the number of web feeds is growing, there is still a huge lack of appropriate feeds. Since most mashup makers rely on existing feeds they have a problem when a required feed is not available. Even if the number of available feeds explodes exponetially there is no way for the site provider to know how people would like to use the feeds - so for mashups to take off, the creation of appropriate filtered feeds is going take on new importance, and the creation of these feeds is going to be a huge niche. Currently “Dapper” is the only tool that fills all the needs of the “universal feed layer” - site independence, web based and an easy to use, intutive interface for prosumers and scripters.

I have been thinking lately about the meaning of strategic software in the enterprise. I have had a number of conversations about interesting, useful applications for business, which were usually shrugged of since they aren’t “strategic”. I think the holy-grail of “being strategic” in enterprise software is a mistake, and explains why enterprise software has fallen out favor with VCs. It is impossible (or at least very, very expensive) to become strategic, and it takes a long time. Strategic, at least in these conversations, means inventing some piece of software (infrastructure or solution) that is so central to the needs of the organization that not having it become a critical showstopper. Becoming strategic moves the buying decision to the senior executive level at the customer, rather than through projects or end-users. It requires a skilled sales force and longer sales cycle – but has much, much higher revenue per sale.

The Web (especially 2.0) is different. The adoption mechanism of a software solution is viral – users enticing other users to join in the fun. This seems to be diametrically opposed with the strategic software paradigm – this type of adoption has to be simple enough that end-users can use the software and get value without the need for a centralized decision, IT department or skilled sales force. Since users use applications (and not infrastructure) viral adoption happens at the application, not at the infrastructure, layer (while most strategic software is in the infrastructure, not application layer). Of course apps drive infrastructure, so this type of software adoption in the enterprise will have a profound effect on enterprise infrastructure and architectures (e.g lets see how SOAP vs REST plays out for services). This type of adoption scares the pants off CIOs who crave centralized control and walled gardens.

This is the crux of the Enterprise 2.0 dilemma for software startups – how to get viral rather than strategic adoption in the enterprise. The best way to do this is by creating network effect applications that have value to enterprise users stand-alone (of course initially delivered over the internet as a service). If you have such an application, I’d love to hear about it.