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
Tuesday, August 16, 2005
Saturday, August 13, 2005
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.
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
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
Monday, August 08, 2005
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.
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.
Monday, August 01, 2005
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.
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.
Tuesday, July 26, 2005
How not to introduce open source
A recent article on Slashdot covered the topic of how to discuss open source software within the context of the a business. As most of these discussion often do, it focused on the "openness" or availability of the source code as the primary introduction point. I think at this point in the development of open source software, focusing a discussion on the availability of the source code is a waste of time. For small businesses an esoteric discussion over which open source license (GPL vs FreeBSD) is a confusing waste of time. Discuss how this meets the business needs, not the availability of the source code.
Friday, July 22, 2005
MS FUD Misses Mark Again.
Recently Martin Taylor the General Manager of platform strategy at Microsoft, was given the oppurtunity to show complete lack understanding of both the power of the LAMP platform and the power of Linux. This is yet another attempt to take some shine off the Linux apple. I usually love reading these interviews with MS as it shows how much they are missing in regard to LAMP. What's very interesting about these recent pieces here and here is what they indicate about the mind-set of Microsoft and ultimately how they just don't get it.
First off let's dissect the FUD coming from this MS talking head.
"The Linux phenomenon created this emotional hype or spike where, in some ways, people became less concerned about some of these practical issues around cost of ownership, reliability, security and so on,"
Incredible. One of the most insecure operating systems on the planet in active use is Microsoft Windows. Given the huge associated costs with Windows (viruses, spyware, and brittle development) how does anyone with a straight face claim to be the more reliable platform. The simple fact of the matter running Windows in a lab where it cannot be attacked doesn't measure the entire cost of ownership of Windows. Viruses and spyware alone make Windows not worth it.
"They're also realizing they can't migrate and evolve (open-source technology) as much as they had thought. For example, U.S. company Flyi.com handles about 90 percent of travel reservations through their online portal, which they run on Linux and Apache.
The systems were running fine until the company had a huge spike in traffic, and there were all kinds of downtime issues. So they did the upgrades, added a few servers, some hardware, some memory and new technologies around the Web site to do more customer relationship database tracking. It was all very complex, and some of the seams of the Linux architecture were beginning to show. "
Poor design decisions can happen on any platform. Not properly architected a large scale web site and the seams will show in any architecture. I did a little digging on his noted example company Flyi.com Independence Air is now a small low cost airline. The Google Page Rank of their home page is a 7 which while respectatable, is not earth shattering. Their customer story from MS is located here. In that study it's apparent that Independence Air was sold a bill of goods in development of their new system based on Linux. Their first step was to buy a BEA Application server for $75,000. They then hired 5 consultants at 150/hour for six months to customize what should have been a relatively simply project. In this particular case the real weakness of the project wasn't Linux but the Bea Application Server which caused costs to spiral out of control. That combined with grossly incompetent consultants really created the problem. Starting off with a $75,000 closed source application server is not the way to begin a project. I find it interesting that in the customer testimonial, the CIO blamed the consultants instead of his own poor decision making in the process deploying the system.
One quote I find interesting,
"Most IT professionals don't want to be in the business of maintaining system-level software,"
That's true. However businesses that are being built on the LAMP stack use their control of the system at the system level as an economic advantage. Take a look at Google. System level control of the operating system enables them to scale search in a way that has never been done before. This gives them a platform from which to launch new web products that can quickly scale up without the time-consuming
Here's the true telling quote.
"From a competitive standpoint, take Linux, for example. There's really nothing innovative today that Linux does that we can't do. There's no new feature or new design that can be done only on Linux, and not on Microsoft."
The problem is that statement can be turned around. "There's nothing really innovative today that Microsoft does that Linux cannot do." Therein lies the rub for Microsoft. Since the LAMP stack commoditizes large chunks of the software stack, it enables a small set of developers launch projects with relatively little work on the basic stack elements.
First off let's dissect the FUD coming from this MS talking head.
"The Linux phenomenon created this emotional hype or spike where, in some ways, people became less concerned about some of these practical issues around cost of ownership, reliability, security and so on,"
Incredible. One of the most insecure operating systems on the planet in active use is Microsoft Windows. Given the huge associated costs with Windows (viruses, spyware, and brittle development) how does anyone with a straight face claim to be the more reliable platform. The simple fact of the matter running Windows in a lab where it cannot be attacked doesn't measure the entire cost of ownership of Windows. Viruses and spyware alone make Windows not worth it.
"They're also realizing they can't migrate and evolve (open-source technology) as much as they had thought. For example, U.S. company Flyi.com handles about 90 percent of travel reservations through their online portal, which they run on Linux and Apache.
The systems were running fine until the company had a huge spike in traffic, and there were all kinds of downtime issues. So they did the upgrades, added a few servers, some hardware, some memory and new technologies around the Web site to do more customer relationship database tracking. It was all very complex, and some of the seams of the Linux architecture were beginning to show. "
Poor design decisions can happen on any platform. Not properly architected a large scale web site and the seams will show in any architecture. I did a little digging on his noted example company Flyi.com Independence Air is now a small low cost airline. The Google Page Rank of their home page is a 7 which while respectatable, is not earth shattering. Their customer story from MS is located here. In that study it's apparent that Independence Air was sold a bill of goods in development of their new system based on Linux. Their first step was to buy a BEA Application server for $75,000. They then hired 5 consultants at 150/hour for six months to customize what should have been a relatively simply project. In this particular case the real weakness of the project wasn't Linux but the Bea Application Server which caused costs to spiral out of control. That combined with grossly incompetent consultants really created the problem. Starting off with a $75,000 closed source application server is not the way to begin a project. I find it interesting that in the customer testimonial, the CIO blamed the consultants instead of his own poor decision making in the process deploying the system.
One quote I find interesting,
"Most IT professionals don't want to be in the business of maintaining system-level software,"
That's true. However businesses that are being built on the LAMP stack use their control of the system at the system level as an economic advantage. Take a look at Google. System level control of the operating system enables them to scale search in a way that has never been done before. This gives them a platform from which to launch new web products that can quickly scale up without the time-consuming
Here's the true telling quote.
"From a competitive standpoint, take Linux, for example. There's really nothing innovative today that Linux does that we can't do. There's no new feature or new design that can be done only on Linux, and not on Microsoft."
The problem is that statement can be turned around. "There's nothing really innovative today that Microsoft does that Linux cannot do." Therein lies the rub for Microsoft. Since the LAMP stack commoditizes large chunks of the software stack, it enables a small set of developers launch projects with relatively little work on the basic stack elements.
Subscribe to:
Posts (Atom)