I pulled out an old issue of brand eins which remained still unread in the pile of magazines. If you don’t now this magazine yet and you have some interest in off-beat economics and you can read german - get it.

An article with interview with Don Tapscott on his Wikinomics I found quite interesting. The point -in short - is that openess will make you advance quicker and be more successful. I don’t buy everything he says, but he is right in many aspects.

Take the simple example of open source and closed source. Where do you think hides the worst coding and design? It cannot be generalized of course, but closed source has better to get away bad coding. There are exceptions in any domain, Axis for example (at least the 1.4) is a kludge and some closed source stuff I worked on had been beautifully engineered. Anything has to stand the test of time, thus in an active open source problems will be addressed - if not god-like committers reject these changes.

And here I lost interest in continuing until I found Why giving away your code is not dangerous.

As always it is complicated. My first boss once said: “If it were easy we wouldn’t be here” - and this is what keeps me going ever since.

The complication comes from the fear that you give away trade secrets by publishing your code. But is this really so? Let’s simply assume for a while that you choose a licence that is restrictive enough to prevent competitors reusing your algorithms (and that you can enforce this in practice!).

How complicated is your code to understand? It is well documented and has valuable comments all over - otherwise it is just a pile of rubbish only insiders understand. But still is this all your organization does? Hard to believe that besides a few people running the machines you need such a staff! Code is like a Jetplane. You might buy one, but this doesn’t make you a pilot, not speaking of an airline carrier.

Let’s stay in this metaphor: Suppose you are an airline carrier and someone offers you an airplane.  Cheap, good looking, even a Powerpoint presentation with a video showing it in flight. Would you get into buying it and seating your customers in it? If this model turns out to be made of cardboard and telephone wire and goes downs with 500 passengers your business will as well.

Luckily - I have no doubt that there are carriers that would make such a deal - airlines are heavily regulated and each passenger plane has to pass very extensive tests and the whole supply chain and lifecycle is monitored with equal dilligence (at least in some countries). In software this doesn’t exist. If at all there is a user-acceptence test, perhaps an intergration verification - in worst case defended by some CMMi approved forms. That’s it. “Stolen” software might bring flight 714 to Sydney - but not flight 222 to Toulouse.

In the end - this is ironic: The honest buyer and the thief are facing the same problem. How can we trust the software we trust. We all(?) trust the FAA to approve airplanes - but who we trust when deciding about a large piece of enterprise software? The question is already wrong, it should be “How can we trust?”

When designing an airplane even the design process is minutely reviewed by external experts, many processes foresee that as well, but in the end is is rarely a independent third party to perform the review (the few case I have seen that had been:a) A lawsuit had been already in preparation - guess why b) The reviewer had been as well been my mother, as they got paid for the review not for reviewing c) Mixture of a+b, the verdict coincidended with the party paying the reviewer - this explains why it is harder to agree on the reviewer than on the price in the negotiations)

Ah, I didn’t mention: I am talking about something boring like enterprise software: Several million lines of code in Java, C++, SQL, JavaScript, PL/SQL, etc.

I have seen developers struggling for days to compile the project code - with no success (some people think documentation is useless…) because this code was never meant to be compiled on a standard environment. Such experience make me feel sure that this code is safe from theft:-) (Serious: I know from a project where the workstationsof the developers got installed by a ghost-image - nobody had any idea how to make a proper setup. This process stopped as new computers arrived, but this failed to work with the old NT 4.0 drivers. Logical solution: The developers received the old computers from the HR staff and those got brand new machines…)

Here the gap opens: You have proprietary knowledge which seems to be rather obscure, nobody outside can verify the correctness and you seriously think you are selling “correct” software. Of course.

Have you spend a thought on how much time you spend on teaching these secret rites to newcomers? When I look at the code I am working on I see more names of former employees in the files than there now (A company I worked for wanted to hide this fact - “for IP reasons” - they replaced the names by the numeric employee ID. To locate the person you could look up the person in the intranet, which told you as well since when the account had be deactivated - shoot yourself into the feet). Where did they went? What happened with the knowledge the acquired? Does HR have a secret brainwasher on the 27th floor? Or are you leaking knowledge like the Exxon Valdez?

What if your knowledge would be open? First you would be ashamed to make such a crap public, marketing would never release a whitepaper that is incorrect and full of typos and grammar errors (OK, they sometimes do), but if you have the guts to do so anyway you might be rewarded as someone will point you on this, perhaps even give you a fix for your problem.

Of course your competitors will as well learn how you do things, but this isn’t bad neither. In the end it will help you that you get copied as this will make them easier to target by your salesforce (in the end you will still know better how it is meant to be done).

How that? Enterprise software is incredibly complex and one part of complexity comes from the engineering solving the problems posed by the business analysts. There lies the true complexity of the application as it used by the customer - the rest are by-products not found in any spec of the customer. Can we open that as well? - Tapscott says yes, because this is the Whitepaper of your application. There knowledge is very valuable, but still alone not usable to form a competition.

Enterprise software always need customization and parametrization - not just some config files. This is real work which has to be done in interaction with the customer. Think of an RDBMS. You don’t buy Oracle and your data-management problems disappear. There are hundreds (thousands) of things to be done, of course you can try yourself or find a guy around the corner to do it for you, but you might feel easier if these guys a certified Oracle partners. It is like buying an airline-ticket instead of hi-jacking a plane (I am not sure what is easier, hi-jacking a plane in the US or installing a production-grade Oracle environment:-)

So it seems it is hard to loose by opening you business - not only the source, but how do you really profit from it? From open source code we know the benefits are “free” qualified peer-reviews,  submitted bug-fixes … wait, yes your bug-db should be open as well. I think in enterprise software you won’t benefit that much from this  as the audience is to small and too “enterprisey”, but that might change as well.

One: Openess creates trust. You can try to establish trust by contract, but this is a juridical ersatz that makes only the legal department happy (it justifies their existence). If anyone can see how many bugs are open and how they are qualified over a longer period (presales in ES take sometimes very long) prospective customers gain a proper impression of you capabiltity to react on problems. Of course the data has to be clean from any customer references - business confidentiality is not for disposition. Don’t cheat. You can fool some people all of the time and all people some of the time, but not all people all of the time.

Two: Open techniques open markets. Look at SAP, there are dozen if not hundreds of integrators that help SAP’s customers to bring the system to production. SAP does this business as well, but for them it is an excellent sales channel. Imagine now some outsiders find your software worth spending their time with. They might start up a consultancy and look for customers. If they in turn buy your product … think further: Do sales belong to your core business?

Three: Last open - first out of business. IT history knows by know several companies that vanished or at least their business vanished as they got overpassed by open source implementations of their products. There are people that predict even the end of Microsoft (that will for sure come, but perhaps not for the same reason these people belive to know). If you are not IBM, you can’t assume a tight grip on your customer that last for decades. The customer who makes a qualified choice will choose based upon trust and choice. Enterprise software sticks around a while the more integrators, the more common the code and the practices, they better the protection for the investment. If you don’t believe this, you should read the last chapter.

Bonus Round: Win a book (my choice) by finding the references and citations! Thank you for reading such a long article.

When sit to tight:

• When your are a turtle and feel the lawn-mower coming (turtles don’t hear that damn well), pull in your head and feet…
• At Hit&Run industries we don’t serve any customer twice.
• I just made this company public, announcing now an open model might frighten the analysts. I won’t ever do that before my wife an me have sold our shares
• Fake&Junk Applications has never ever delivered a working system, it is important for us to serve our customers best that they stay clueless (at least some of the time)

Otherwise: Read the article from brand eins,  if you can’t read German, the Google translation from it to english is fairly readable (Tip: search the article in Google, select HTML-version and use this URI to feed the translator)