Part of what I put here I've already put into my upcoming PhD thesis in some form or another, but it's about time to write up on it a bit out here, also to polish my still raw thoughts a bit. Feel very free to mail me comments.
The main idea is: we finally want to see some serious information exchange see the light of day in the building and construction industry! A lot of smart people are putting a lot of effort into that. What are those efforts, or better, what kind of efforts are those? Are they applications or platforms?
Note: I changed a little bit of spelling on 2004-17-04 and re-did the last four paragraphs. I'm going to be pointing to three not-too-big articles of Joel Spolsky, you might want to browse the other articles, as there are some gems in there.
Ok. Platforms versus applications. A natural thing to do when you're in the ICT (research) business is to create applications. Some program that does something well, like viewing IFC files, editing specifications or supporting a customer in the initial phase of a building project. The customer for your program is effectively an end-user, someone wielding the mighty mouse and keyboard.
Alternatively, you can create something more infrastructure-like: a platform, for which you wish other people to build the actual applications. The customers for your platform are not the end-users, but the developers of the applications. This distinction is central to Joel's article.
Figure out which "camp" you're in and base decisions on that fact. Platformer? Take care of good, available documentation. A good, clear spec. Good examples. Example code. Example data. A running infrastructure. The 2000-2002 eConstruct project created the bcxml format for dealing with both taxonomies and data based upon a taxonomy (for use in a catalog for instance). It was reasonably well-documented. I've seen at least two instances of other, unrelated research projects that used the format as it was a handy, pre-made format. Not exactly earth-shaking, but it's not really bad for a small research project.
So. If you're in the platform creation business, you are probably going to suffer from what is commonly known as the chicken and egg problem. Nobody is going to buy your platform until there's good software that runs on it, and nobody is going to write software until you have a big installed base. Ooops. It's sort of like a Gordian Knot, although a Gordian Death Spiral might be more descriptive.
Gordian death spiral, I like that one... When reading about laudable platform efforts the sentence to look for is everybody should...*. Yeah. For the good of mankind, of course everybody should start working with XYZ. Everybody should re-write their software to include an XYZ layer. And if everybody did that, the world would be perfect. So "everybody should" is the sentence to watch. It signifies a serious gordian death spiral risk.
Another quote from the article: Companies that fail to recognize the Chicken and Egg problem can be thought of as boil the ocean companies: their business plan requires 93,000,000 humans to cooperate with their crazy business scheme before it actually works.
The solution from the article is to provide backward-compatibility. Practically taking an old chicken and putting your shiny new man-chicken, well, eh, on top of her...
An alternative is to go for some serious 80/20 magic. I'll put that into writing someday. For now: assume you have something really new. Create a simple, cheap platform. The investment (time and/or money) shouldn't be too big. But that small investment should bring already noticeable benefits. For yourself and for others. Something like the world wide web. Just putting a couple of research papers online to share with your colleages. Handy for you, handy for them. Within a year 10000 people are using it and the network effect is spinning (positively) out of control. Something like that is what I mean, but probably less successful :-)
The most readily applicable of the three articles is the micro-economical substitutes and complements. If you've got more than one specification system in a country, those specification systems are each other's substitutes. You can exchange one for the other. If one of them gets cheaper, the usage will go up and the others' usage will go down. Just plain economics.
Specification software, when sold seperately from the specification system's database, is the complement of a specification system. Like cars and gasoline are each other's complements. If the price of specification software goes down, the price of the combination goes down, so the demand for the specification system goes up. Just like a dropping gasoline price will mean more cars.
From the article: Smart companies try to commoditize their products' complements. A commodity is a readily available good from multiple suppliers. Which means that the market price will mostly be quite low. You can hardly earn a cent making computer hardware, as it's so commoditised. Selling the nicely monopolised Windows software allows Microsoft to have a 80% profit margin, as it has (almost no) competitors and as the complement (PCs) are commoditised.
Back to platforms and applications: for each side of the equation it is a good idea to commoditise the other side. For applications, a commonly and freely available platform is a Good Thing. For platform creators, commoditising the applications running on your platform is a good idea.
So on both sides there's a trend to commoditising. Open standards (by which I mean freely implementable standards!) are a way to commoditise the platform. Open source implementations are the way to commoditise the applications.
Ehrm, where's the money in all of this? Probably not really in the platforms. It's almost a fact that open source software climbs upwards from the bottom up. Nobody's going to make a new operating system. You've got the commercial Windows and the partly-open partly-commercial Mac osX and the free Unices like linux. So making a new one means competing against two existing commercial solutions (hard enough) and one $0,00 solution: URGHHH. Most (all) of the base-level web stuff is available for free. Web servers, email servers, etc. No way you're going to sell a new commercial solution. Apache (free) has 60+% of the web server market. Now open source starts creeping into the office application layer. And up and up it goes.
So the money is mostly in the (higher-level) applications. And the more specialised applications at that. A new wordperfect or word variant? Forget it. An innovative, user friendly support tool for the initial phase of a building process? Yes. Specialised stuff. Not the run-of-the-mill stuff.
But earning money on platforms will probably be very hard. Watch out when trying to do that. You're probably going to have to keep things closed as hell. And that's not going to play well with the Internet. Unless you've got a lot of useful data (amazon, google) that you can make accessible over the Internet without losing control. You can access google's database programmatically, but only a few times per day when you've got a free account. If you want to do some serious business using google's database: you gotta pay! Likewise amazon. You can connect to their databases and shop systems and set up your own shop. Only, in the end, you sell through amazon's shopsystem. You get a share, they get a share. They own the platform and they make money out of it. They treat it as a platform and therefore allow others to build on it and earn money with it. They make it easy for you to do that. There's even a book on how to do it.
From Tim O'Reilly A broad-based platform strategy beats an application strategy every time, at least as long as I've been around the computer industry. So creating a platform that's used widely and that's well-integrated with your own money-making applications... That's a very neat thing to pull off. The best thing, of course, is earning money with the platform itself.
On the other hand, doing that is hard. Having a freely available platform levels the playing field for everyone. There is some business sense in doing that levelling yourself, as it ensures you an early start and a fair playing field. It might be better than competition amongst a number of not-quite-platforms.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):