[LINK] Softwre Licenses

[Rankine, Alastair]

> 1) We would be able to come closer to performance guarantees 
> IF software
> developers ^h^h^h^h^h^h^h code-writers a little more willing 
> to use standard
> components for standard functions. "No, I MUST write the IP 
> stack in native
> microprocessor instructions, I save TWO PERCENT of 
> resources!" Does Holden
> make its own 12mm bolts?

Agree with your other points, have a cautious note to add about this one.

In my experience, third party components/libraries are a significant risk to
software development projects. I have seen them bring apart projects which
are otherwise well engineered. I think the key phrase is "standard
functions". I'm just not sure there are such standards.

For example, consider a procedure call interface to a software component:

	void ShowAlertToUser(char * text);

There are a certain set of semantics which are reasonably obvious, such as:
A window will pop up on the users screen with the desired text. It will
inherit a "standard" alert appearance according to the operating system. It
will block execution until the user hits OK. And so on.

There are lots of other semantics which are not obvious. What happens if you
call it re-enterantly? Does it block and display only one alert at a time?
If it can be called from different threads, where does it place the alert on
the screen? Will the multiple alert instances hide each other on the screen?
Will it steal focus from the user such that non-touch typists may end up
dismissing it accidentally by pressing return (a pet hate of mine)? Will it
throw an out of memory exception? Will it leak memory/resources? Will it
kick off a clean-up thread that steals CPU cycles after the call returns?

I would contend that the complete semantics of this procedure call can NOT
be adequately documented without looking at the code that implements that
procedure. Even when you have the source code, some of the more subtle
interactions are non-obvious, and also not necessarily bugs in the software.
(Mind you source code is infinitely preferable to no source code - are you
listening, Microsoft?)

Now is the time for a COM junkie to pipe up and recall all the successful
systems they've built by using off-the-shelf components. I say this is all
well and good, but we still have a lot further to go. Writing software
components is hard - providing an environment where they can coexist is even
harder.

Buy-or-build decisions preceed the software industry, but the fundamental
issues are the probably the same. In outsourcing terms, what is your
application's "core business"?

(pardon the rant :)