Lloyds - Insuring Open Source

In a move that removes yet another barrier and FUD point from Microsoft, noted insurer Lloyds of London has moved to offer indemnification for open source software for IP claims.

"A Lloyd's spokeswoman was unable to confirm details, but St. Clair said the insurance would initially cover the open-source LAMP stack, which consists of the Linux operating system, the Apache Web server, the MySQL database and the Perl, PHP and Python scripting languages. Other open-source products may be added in future depending on market demand."

This is important on several fronts. First off it indemnifies one of the most critical components in the growth of Linux, the LAMP stack. We are seeing adaption of Linux largely because of this stack. New web services company are constantly built on this stack all the time. By offering indemnification Lloyds believes the IP stack of Linux is relatively clean. This is another vote of confidence for the transparency of Linux and the open source development process.

Much has been made the role of patents, OSRM commissioned a study that Linux infringes on potentially 283 patents. Here's the dirty little secret in software development today. Since they have allowed software patents nearly everyone's software violates someone else's patent. That's the truth. The fact that Linux potentially violates only 283 patents should be a good sign.

Right now everyone with a significant patent portfolio usually signs a cross licensing agreement with each other. The real question is what is going to happen once one of these large patent holders decided that they need to more effectively monetize their patent portfolio? It's hard to say. However attempts by relatively small patent holders (15-20 patents) to monetize somewhat dubious patents have not been hugely effective. While they do generate some revenue, no one has become a billionaire doing it. Indeed certain groups have banded together to fight patents, pooling their resources.

Getting this sort of indemnification for Linux and the entire LAMP stack is a great sign. Getting closed software indemnified at all is next to impossible. Most software companies like MS self under-write their indemnification policies. The last time I tried to get a closed source software solution indemnified, I was unable to do so. This is one of the most critical developments for Linux for continued acceptance in middle level companies and the Fortune 500.

Technorati Tags:
Open Source
LAMP
Linux
Insurance
Indemnification

Firefox Adaption Stalls

The early adaptors have all moved to Firefox apparently. It looks as though 8% is Firefox's natural open source market share. I wonder if the new Mozilla corporation will help drive adaption by giving corporations someone to talk to. That's a pretty common request among CIOs. Trying to gain market share against a product that ships with every single machine in the world is fairly hard. I use it and I find it a pretty good product. Of course now that the IE team is re-constituted and working away, MS will ship a product that's just good enough.
Technorati Tags:
Open Source
Firefox
IE

License Issue & Success of an Open Source project

One of the things recently discussed at OSCon was the proliferation of open source licenses. As more companies begin to open source some of their applications, their corporate attorneys often feel the need to re-write and redo licenses that have effectively been done.

"Referring to 63 approved OSI licenses and another 100-200 "floating around," Levin echoed others from the FSF and elsewhere in calling for a reduction in licenses. "We want to reduce any possible objection, concern, or friction point with using open source licenses," he said. "There are truly an unnecessary group of licenses which have been created because of lawyers' needs to justify their existence or because companies have a narcissistic need for differentiation. The slight variations are more often than not an overreaction by zealous lawyers."

I knew the moment that OSI started accepting licenses to approve that this problem was going to happen. Everyone wants their own licenses, even if it's just their own spin on the BSD license. We licensed under the Sleepycat for Xao and it seemed to work fine.

The problem that the proliferation of licenses creates confusion over the usage of the particular program especially in a situation where you want to build a new set of services on top of an existing set of open source programs. The confusion of parentage of such a chimera makes it impossible to decide which license to use and for developer to understand what rights they retain to the code. That's why it's pretty clear that the open source projects that succeed have clear relatively easy to follow licenses.

When I say success, I mean successful at attracting outside developers to the project . By using one of the traditional open source licenses that is well understood by the developer community, allowing them to understand exactly which rights they are giving up and which they are retaining. While your corporate counsel may want to write their own, I can assure you that someone else has covered all the issues you are facing.

One way to determine your license is to take a look at the business purpose for open sourcing your software. If your intent is to develop a community around your software, chose a well known license. (Sleepycat, BSD, GPL, Mozilla)

If your purpose is to have an "open source" product and most of the developers are going to work internally on your project, feel free to write your own. Just don't expect a whole lot of outside developers to contribute. Without a clear delination of rights, developers are much less likely to work on a project. Why waste the time?

Technorati Tags:
Open Source
Licenses
GPL

37 Signals - An example of the future of software

Salon recently had a great article about small start up in Chicago called 37 Signals. The name is derived from the Seti project of the number of signals received that could be from intelligent life.

This is a small company with exactly five employees, all programmers. When the dot com work began to dry up they started looking around for another revenue source. They found one in the web based project management tools they had built to manage projects internally.

They took their project management software and began offering it as web service that anyone could use. Their software is intentionally limited in feature set to minimize the learning curve. As anyone who has used, MS Project knows, the learning curve on modern project management software is HUGE. MS Project is the market leader in this market but 37 Signals has a great shot at achieving significant market share. There are several reasons for this.

• The old WordPerfect study. It's pretty simple. Word Perfect found 90% of the users use roughly 10% of the features. That means that for most people, Textpad is more than sufficient for their needs. Without the huge investment of learning the program, most users can be more productive more quickly. Spend more time working and less time working with management tools. Here's their philosophy,
  
  "We believe software is too complex. Too many features, too many buttons, too much to learn. We build products that do less, work smarter, feel better, let you do things your way, and are easier to use."
  
  You know what, they are right too.
  
  
• It works simply with a browser. 37 Signals is a big advocate of Ruby On Rails and with AJAX are able to provide a solid user experience. As it's browser based it's platform independent so it works pretty much the same for everyone.
  
• MS Project is built on the MS stack. In other words to use the full features of Microsoft Project you need Microsoft Office Project Server. In short, you really need to be a Microsoft shop. 37 Signals can work on any modern browser. These means no license management and no head ache. Project is still far to desktop-centric to be thinking this way. Furthermore a radical change like this would require MS to knife the baby and think outside the box. MS is too busy thinking how can we lock them in. This lockin requires that companies work around Microsoft instead of the other way around.
  

Projects and companies like this won't appear on the radar of Microsoft. Since they don't ship software, they don't really appear on the Project's product manager's radar. When they do appear, MS will undoubtedly put out a product spec sheet touting the number of features that Microsoft Project has. This is missing the point entirely. MS Project has too many features to be used effectively now. The learning curve is far too steep and it's far to MS centric to effectively compete.

Companies like 37 Signals are going to continue to flourish. It's a great time to be an entrepreneur. That's the subject of my next post.

Technorati Tags:
Project Management
MS Project
37 Signals

Why HP is doomed

I rarely forecast doom for a company. However if my recent experience with HP is any example, the company is doomed. I was looking for 2 laptops to be used in my web mail station project (anyone wanting information on that project should look at Thalasar Ventures I will post updates there). As these are going in a web mail station, they are certainly going to be beat to death. So I considered Dell (the old standby). They were offering a great deal on the 1200s. But I got suckered by the great ads HP is now running. When I added in the price of wireless and support, HP turned out on top at least in price. HP has always stood out in my mind as a high quality provider. So away I went to HP TV. After placing my order, I wondered why I didn't recieve an email confirmation of the order. So I quickly called HP to find out. After speaking with a customer service representative, it became apparent that when I input my email address for confirmation and login, I typed .con instead of .com. The customer service rep of course said it was my fault for making a typo. I then thought back to my team's own software development work in open source ecommerce in 1995/1996. Email address verification (that the email address added followed the form of a valid email address) was added in our SECOND alpha release in 1996. Later we added functionality which checked that the email address actually routed and was deliverable. HP doesn't have the first basic functionality nine years later. They don't bother to check to see if an email address is valid with the order!


The funny thing is this email login is how you are identified as a customer at HP. So when I requested they change it (ie correct it so I can actually communicate with them, I was told this was impossible. Why is email address verification such an impossibility for HP? Could Broadvision (there ecommerce software provider recently taken private) be so inflexible? Is their It infrastructure so brittle?

It doesn't bode well for a company. I had a similar problem at Dell. They were able to quickly consolidate accounts under a single login. If HP's IT infrastructure is so brittle how can they expect to compete?

What struck me as even stranger is that the HP rep didn't think it strange that their ecommerce application doesn't validate email addresses and thus account signons. I guess Carly really did kill the culture of innovation at HP.

Art of The Demo.

One of the projects I had introduced to the guys at Highlands University was nearing completion. Anthony the project lead called me into their office to go over the project and make sure we hit it with the work order. So with work order in hand we started. Unfourtunately the programmer had been working on the site that day so it kept breaking. I recoginized the error was a simple one and told them I wasn't in rush for the project and I could come back tomorrow. I also realized that me sitting there put enough pressure on the programmer so he was unlikely to find the error. Just better to come back when he had time to find the missing bracket (which indeed was the error). So the next day I returned and with work order in hand we go through the site. I thought about the demonstration I saw, which was pretty straightforward, and how many times I had to give a similar demonstration for clients when we completed a project. So I though perhaps I could distill some rough guidelines for a demonstration. Now most of my demonstrations were done for a web site but with a little imagination you can expand them to include product demonstrations as well. Here's Brian's Rough rules for demonstration.

1. Control the demonstration. This means that you shouldn't allow the client to side track the demonstration with questions. This means simply saying,"That's a great question. I would like to handle questions when we get to the end." Make sure though that you write down the clients' question or note it. I suggest writing it down as your mind will be focused on the demonstration. Keeping a question notepad is one way to do it. It is also useful for writing down short notes when the application doesn't quite work as expected. Also don't let the customers randomly monkey around with either the equipment or the site. If you want the customer to try a feature, show the customer the feature you want to demonstrate, show them how to do it and then let them do jsut that feature. It's a product ask for it back so that you "may continue the demonstration".

2. Know your click path. For this latest demonstration we used the work order to drive the feature demonstration. This can sometimes cause problems as certain features are related to each other. It's often more natural to demonstrate certain capabilities when they are clustered together. Find out what will naturally go together when you practice the demonstration. If you are not the developer, then have a developer in the room when you do your first practice session. Some of this advice will actually be helpful as they point out how features may be clustered together.

3. Declare the system "Gold." This is a hard one for developers to resist. Quite often they think they can stuff a feature or finish in time for the demonstration. If developers are working on features before the demonstration you can expect that demonstration to go poorly. If all the promised features are not in this demonstration, let the customer know early so as to minimize the expectations.At some point declare that all work must stop so that you can prepare for the demonstration.

4. Set the expectations. This is an important part of any demonstration. As a demonstration can happen at any point in the development process especially in the XP, you should set the expectation on what the customer is going to see. If demonstrating a specific module, state it at the beginning of the demonstration, "This demonstration will only be covering the customer profile and profile management features." Customers are always going to want to see more so remember point #1.

5. Practice the demosntration. A demonstration is a form of public speaking and you would never think of giving a speech without practicing it once. By practicing the demonstration in front a single person (preferably a developer familar with it) you will certainly feel more comfortable with the system.

6. Developers often do not make the best demonstrators. Why? Because they are extremely familar with the internals of the system they are demonstrating. So they may make leaps or even be tempted to make changes during the demonstration. Remember point #3. No more features.

7. The missing feature. Sometimes you just don't have everything you need for this demonstration. If you forget to mention this during the expectation setting phase of the demonstration, you might be able to get away with dreaded,"In the final version of the system, feature X will happen this way. I am sorry we weren't able to get ready for this demonstration." Of course that feature might not be in the work order, but you can bet the customer will certainly want it. At the final demonstration, the customer will certainly the feature as you mentioned it rather than how the contract reads.

That's all for now. I will update this from time to time. It will be nice to re-visit it now and again.