« I Never Met a Data I Didn’t Like | Main | Life, the Universe, and Testing »

December 14, 2005

Comments

elliptical reviews

No offense, but i suggest admin adding a google+ button for easy share!

Volker

I was working for Rational Software, the last three years with IBM. From that history - working to deliver a packaged solution for the standard business process called "Software Development", I'd like to show the vendor's point of view.
(Is anyone picking on the term 'standard'? You're right.)

I think that your reflection on open source is also interwoven with what you also said in your blarticle about the "Increasing Tail". Winning market share depends on developers, developers, developers ... how to get more and more people involved into making your product better. So let's pick a developer tool as example: Rational Rose (Rational Object oriented Software Engineering).

Here's the short history of Rose:
The first version was a FORTRAN client running on a Mac with a R1000 server (Rational actually started as an ADA hardware company selling big machines).
Then it was ported to windows switching one or two times, to and from text-based storage and OODB (anyone remember ObjectStore?). All that happened between releases 2.x and 3.x. (And Rational also decided to stick to sell software only)
After finalizing the fundamental architecture, with release 4.0 in 1997, it came back to text-based storage, and introduced an API for the first time.
[Accidentally, that was the time when I personally joined the team. Grady Booch and Terry Quatrani can tell you more about the history of that tool - this is where I have lot of my knowledge from, not only about rose]

What's interesting is that with the introduction of an API (a VB script based interpreter), there were about 100 additional Addins, many sold via the Rational partner program within one single year (which was Rational's implementation of creating the Long Tail).

So, Rose had become what I called a market. In more common terms: it changed from product into platform and opposed the vendor with the problems you perfectly described above.

From this perspective, the history of Rose (and of many other successful products that evolved into platforms) looks like this:
1. Create a product and start selling it successfully
2. Add many options to the product (because of user demand)
3. If there are too many options to be managed by the user (and the product development), introduce an API
4. Get someone else to use your product/API as platform (IBM calls it ecosystem which IMHO fits quite well) and help the (external) developers to *earn money* developing for your platform
5. Move 'internal' components/building blocks/features into API-based pieces
(After step 5, earn zillions of money)

Rose got it to state 4, but never reached 5.
Based on my personal experiences, there were several constraints that had to do with the target market (remember, Rational was selling software to people who do software)
Amongst many, these were the two predominant ones:
(a) The problem of the priest who needs to be more religious than 'normal people':
If someone preaches to developers how to get better than the code given to these developers needs to be at least as good as the code of the best ones at the customer side. They were usually the opinion leaders that need to be convinced to use the tool. (Who wants to sell a car to Michael Schuhmacher?) Rational needed that ground-base to sell at all.
(b) Thus the only option to give the maximum flexibility to the customers would have been to give them the whole development environment used at home. Not an option that many vendors like - despite maybe a three-star cook who wants to have his own TV show (and he sure will clean up his kitchen before and that needs some time & money...)

In your other blarticle you quoted Steve Balmer with "Developers, Developers, Developers!"
It is important to get the developers 'on your boat'. But this might not be true anymore with Web 2.0 and I doubt that Enterprise 2.0 will get increasing market share with focusing on developers only.
A customer of mine once said: "I don't want software developers. I want bank developers!" So, I'm adding another state 6 to my list above:

6. Make the whole mess of customization/development easy enough so *everyone* involved can change his part easily

To be honest and to come back to your theme about Open Source, this is not the standard evolution anymore. New products - and surprisingly many in the open source market - start by combining states 1, 2 and 3 in the first release. This is good.

What I see with today’s blog systems is the self-driven perpetuum mobile of Long Tail creation. More and more people use them. Surprisingly, many users start to adopt them, even if it means to dig into PHP code. I think there are many users-as-part-time-developers and the number’s growing. Everyone is a changer. But on the business side it might not be the best idea in the first moment. More and more changers... Oh my! The control of all these new extensions would maximize the risks you describe above (to say it nicely).

A solution would be to get the whole delivering process of a new baseline under a better control. If this works, a vendor of packaged apps or an Open Source project would be merely just another provider - but should still strive to be the most experienced and most productive one.

Throw in another topic you mentioned: the MVC pattern (the overall known and everywhere customized, all-round architecture of Object Orientation). It has an inherent order of priority. The most important is data (Model), the second important logic (Control) and the least important is UI (View).
This is based on the following thought: What would happen if two of these three simply disappear? Which one of them do you absolutely need to go on with your business?
What if only one of them is disabled or crashed?
I came to this idea when asking a colleague to lend me his laptop. He refused, no surprise here. On my question why he said: "I don't want you to see my private data on the machine". He said data. Not Applications, nor Windows.

So, a simple trick might be to 'transpose' (anyone have a better term?) the relevant things-to-change into data and keep them out of Control and out of View. What happened with youtube, for example? A complex thing like a digitalized video - only a few years ago something manageable only with either expensive tools and/or development - is now something I just share. It changed from the usage of complex logic/tools to a simple piece of ... yeah: video.

So, the trick is to find these 'like-a-video-things' in enterprises and put them into the model part of the system(s).

In the end, someone might buy a computer, connect to the internet and tell the computer "I wanna run a bank. Get me started."
The computer would ask him some simple questions, like "what is your job?" and then give him the functionality he needs (not what he wants :-) to start. If he needs more, he just creates new things (as a user) or new logic (as a developer). By using Web/Enterprise 2.0, I think that the average distinction between user and developer will soften over time.

Kind regards,
Volker

Disclaimer: I actually don't know much about packaged apps, Enterprise 2.0 and only little about Web 2.0. My customers always knew more and mostly better. If I misused any of these terms, please blame me, not their priests. And don't try to explain them to me, 'cause I like to be innocent. Just blame me and point me to good learning URIs - be aware, I will shoot back /w questions.

The comments to this entry are closed.