Objectspaces hostility and the separation of marketing and technology

Alex Thissen reported yesterday (and we all know what day it was yesterday ) about a rumour that Objectspaces would be removed from .NET 2.0 and would be released as a separated package.

It's a rumour, posted at a date when you can't trust any website, but let's say that it is true. I said as a reaction on Alex' blog:

Dropping it would be the right thing to do. Objectspaces is not something that should be part of the framework. The reason for that is that it is completely closed: any RDBMS vendor will be pissed as hell because they can't create support for their database in Objectspaces, i.e.: illegal tactics from MS to promote SqlServer through Objectspaces. Remember: it is completely impossible to write a query engine for objectspaces which supports Oracle plus it is impossible to produce a mapping schema which supports oracle, as the mapping schema can't store sequences nor can it cope with catalog less database designs.

Apparently this was not what some people wanted to hear: I am biased, I spread FUD, I am bashing Objectspaces all over the web and newsgroups and apparently I'm advertising at the same time my own product.The hostility with which this was expressed surprised me. It is the same kind of hostility you find in .advocacy newsgroups when you're telling the crowd your (competing) product is way better. (anyone who has participated in a shared thread in the C# - java.advocacy newsgroups knows what I'm talking about )

Why the hostility? Well, some people confuse marketing with technology and vice versa. These two things are two separate aspects of a product. Objectspaces, or any other part of .NET 1.1 or framework, is just a piece of technology you can use or not use. It has a set of specifications and if they meet your requirements, it's great, if not, you have to look further for something which does. Nothing special, happens every day.

A company selling products wants to sell as much products as possible for as long as possible. This has nothing to do with the quality of the product or what it does. Though, it helps if the product is of a higher quality than 'crap' and that the specifications of the product appeal to a lot of people, however everyone reading Dilbert on a daily basis with thoughts like "Oh yeah so true!" knows that these two product aspects aren't necessary to get a successful product. Some marketeers or sales strategists claim they can sell air for money if they have to. To get a product sold, you need a good marketing strategy and a good sales strategy. There are a lot of different strategies to choose from. One in particular is interesting for this story: using the availability and success of your product A to sell your product B.

In this strategy, A is Objectspaces, B is Yukon. Again, this is all about selling products using a technique to get them sold and has nothing to do with what Objectspaces is, what it does, what it can or can't do from a technical point of view or what Yukon can do or has to offer. In fact, these strategies are not designed by technical people (most of the time). Why would a designer of Objectspaces care if it is open for 3rd party RDBMS vendors? No software designer wants to hear his/her software is not well designed because it hasn't foreseen any future additions while it would have been so simple to design a system to support these.

Objectspaces, in its current state, will support SqlServer only. Microsoft has said it will add support for other databases later. When, is unknown (but most likely in the successor of .NET 2.0, as it would require a framework patch, i.e. another version). If Objectspaces is part of .NET in this state, it will be sad from a technological point of view (a lot of people use .NET with other databases, so they have to skip Objectspaces and probably have to shell out money for a 3rd party tool, and it is unnecessary to cripple the tool as a generic design is not hard in this case), but it is brilliant from a marketing/sales point of view: Objectspaces will be available on every system on which .NET 2.0 is installed. With a good marketing strategy which uses both hype and PR, a lot of developers will look out for Objectspaces because it is presented as a product that will save them a lot of trouble and time and thus money. Because it is available in .NET 2.0 and thus in Visual Studio.NET, or whatever editor used, it can be used by everybody using .NET 2.0 and because .NET 2.0 is free, Objectspaces is free too.

Due to the fact it will be available to a very large audience, and because Microsoft will document it in the .NET 2.0 documentation, will set up examples, presentations, webcasts etc. etc., a lot of people will try it, probably like it and will ask their team leaders to adopt it in the next project. Again, the story is not about the quality of Objectspaces or Yukon, just about marketing techniques and sales techniques. It's obvious what will happen: due to the strong linkage with SqlServer and Yukon, if you want to use Objectspaces, Yukon or SqlServer is the choice for your back-end database system. Any other database type will not work with Objectspaces in its current state.

Of course, not all developers will switch to SqlServer or Yukon because of this, like not all developers will use Objectspaces, however it will be a decision influencing point in a lot of projects. Add to that, because of its availability everywhere, Objectspaces will be known by a lot of developers, which has its advantages too: a lot of people use it, so a lot of people know the solution to a problem and if you as a developer switch jobs, your new employer will probably use Objectspaces as well which can be huge plus.

So to summarize: make Objectspaces popular, use Objectspaces to make one particular product (and Objectspaces, being an O/R mapper, requires a persistent storage (database) like every other O/R mapper does ), in this case SqlServer / Yukon, the only choice, and you have a great way of selling more licenses of that product, thus SqlServer / Yukon licenses.

As you can see, this is clearly a marketing/sales strategy to sell more products of type B, through A. Although this strategy affects the technical realization of Objectspaces, it's not related to the technical aspects of Objectspaces, as Objectspaces is not going to be better if it just supports one database: a more generic design is for OO fetisjists more appealing as well as for developers using Objectspaces, as they can use it with more types of databases in that case (if an Objectspaces query engine is available). See it as the DataSet. The DataSet can be used with any .NET provider available, as long as the provider obeys a set of interfaces. It would be considered not that great if DataSet objects would be usable solely with .NET's own providers and 3rd party providers wouldn't be able to use DataSet objects.

Objectspaces is an example of how marketing/sales strategies influence technical designs. Any software engineer would have designed Objectspaces as a generic engine which could use query engines which implement a given interface. That way it would be generic and every database vendor, like Oracle and IBM, could develop their own query engine for Objectspaces. This is not the case. Not because the designers don't know what they're doing, I'm the first to say they do know what they're doing, but because it would be horrible as a marketing/sales strategy, as you'd miss the opportunity to promote SqlServer / Yukon through Objectspaces.

This is the confusion some people have. By saying something about the marketing strategy embedded in the design of Objectspaces, you're not saying anything about the technical side of things or the quality of the tool. I think for clarity in discussions about products which are, sadly enough, subject to a marketing campaign, it's best to keep these two worlds separated.

Am I biased because of this? No, I don't think I am. I'm geek enough to find aspects of competing technologies great and well done. Am I bashing Objectspaces? No, I don't think so either. I'm bashing the strategy of using the design of a software product to sell more products. I do that because I like well designed software and I find crippling a design because of a sales strategy or marketing strategy not good for my profession in general. Furthermore, bashing a competitors product (in this case Objectspaces) is not helping the basher, at least in my point of view. The reason for that is that I firmly believe in telling others what the advantages are of what you have to sell. Bashing the competition makes your competition look bad, according to your bashing, but it doesn't make your product instantly great, as you don't say a thing about your own product.

Back to the rumour at hand. If it's true, would that be great for Objectspaces (and thus for you, as a developer)? You bet. Because it will then not have the necessity to serve as a marketing tool, but can be designed as it should have been: as generic as possible, so 3rd party vendors can add their own logic to the Objectspaces engine. You see: as an O/R mapper, Objectspaces abstracts away everything from the database used. So the more databases supported in Objectspaces, the better it is for developers using Objectspaces, and the more open Objectspaces' architecture is, the more 3rd party vendors are able to write classes which make it possible to use Objectspaces with their database. For the developer nothing changes technically, as he/she will work with the interface and API Objectspaces offers.

We now have to wait till there is proof that the rumour is true (or not), and if it's true, that Microsoft will change the Objectspaces structure so 3rd party vendors will be able to write their own query engines for Objectspaces. Personally I think Microsoft should take the bold step and proof the rumour to be true, just for the profession of Software Engineering, and at the same time Microsoft should allow the designers of Objectspaces to design a generic architecture, instead of an architecture which is crippled to serve marketing/sales figures. There is still plenty of time to successfully produce such a system.