D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

[LUG] Open source going proprietary



On Friday 24 September 2004 10:29 pm, Adrian Midgley wrote:
On Thursday 23 September 2004 20:53, Neil Williams wrote:
This is why there is Open Source code in Microsoft Windows that has been
modified but the source code is not available - nor is there any need
for Microsoft to do so.

But by doing that, MS cut themselves off from any easy use of
_improvements_ by anyone else who is publishing and contributing back work
to the main fork.

That may be important if the code in question was alpha or beta. Once mature 
and stable, future developments are more about keeping in step with external 
pressures (which are public) and maintaining integration with other systems. 
The closed source systems only need to maintain integration with their own 
code so are free to ignore public standards that apply to the main fork.

Typically, the interface modifications to link with the closed source are 
EXACTLY the kind of code that the open source developer is looking to add to 
the codebase. Instead of being required to help, the proprietary developers 
force the reinvention of the wheel.

Most of my work is on library code. I write the engine, the logic and the 
framework. Someone else writes the user interface. The library continues to 
work with future developments - maybe with a few minor extensions - the major 
changes between platforms are all in the interfaces with other parts of the 
system, including the user.

These libraries are easily transferred between platforms - that's the whole 
point of a library, to be utterly generic yet robust. The libraries are 
usually comprehensively documented too, the developer knows that others want 
to use the code in ways that may not have been anticipated - to reduce the 
number of inane queries, as much detail as possible is made available to 
everyone.

Which to be sure is less sub-optimal engineering than various of their
behaviours, but still increases their costs for no added benefit.

Not true for mature library code. They would have had to write a smaller 
version of the library for themselves anyway - it's far easier to strip out 
the extra code to support other platforms than to create it!

In doing so, therefore, unless they can show a clear $ benefit to their
strategy as distinct from the alternative of improving, and publishing
improvements for reincorporation to teh main line,

They don't need to care about the main fork. Their interface is usually 
incompatible with the main fork (if it isn't, they will change it so that it 
becomes incompatible, e.g. filesystems and Samba). If the code is already 
mature, improvements are usually external to the library itself.

Using multi-platform, generic library code has immense value for proprietary 
developers - they know that the code has been specifically designed to be as 
neutral as possible. It means that the library will continue to function even 
when they transfer it to different flavours of their proprietary 
distributions.

To invert the usual medical analogy:
would you use a branded medicine that only worked in a sub-set?
or would you prefer a generic that worked in all situations?

Writing code for one target platform builds an inherent bias into the program 
that can be impossible to remove later, via a network of assumptions.

Writing code for an unknown or variable platform builds an inherently flexible 
and robust codebase that cannot be achieved in other ways.

the officers of that 
corporation demonstrably fail in their duties to their shareholders - which
are substantially the only peculiar duties they have that have any teeth.

True, but not effectual in this scenario.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

Attachment: pgp00042.pgp
Description: PGP signature


Lynx friendly