Re: [Fsfe-uk] QnetiQ study

[Paul]

Hi,

> Such a small study set has had an impact upon the 
> conclusions that can be drawn,
> and therefore our conclusions should be seen as indicative only.

In other words, we've not really looked at the wealth of software out
there, but decided to playing "pong" would be a good idea...

> 2. The 'closed-shop' nature of the OSS community represented a barrier 
> to the independent uptake
> of OSS solutions. User perception was the main factor here, with little 
> quantifiable evidence to
> support it. However, the result was that implementation assistance was 
> widely used, typically in
> the form of contractors and consultants.

What? This makes no sense. How can OSS be "closed shop"? The whole idea
of OSS is that it is that - OSS. As to the rest of this number, it's
pure rubbish. The key part which best summarises the entire document is
"with little quantifiable evidence to support it". This refers more to
those who wrote the doc than to anything else!

> 3. There is no single consistent implementation control and management 
> methodology being
> operated by the case studies included in this report. Each operated 
> their own methodology,
> typically based around the experience of those taking management control 
> of the
> implementation.

Not sure what they're on about here. Take 4 distros - SuSE, RedHat,
Slackware and Mandrake. Each distro has XFree86 4.3, Gnome2 and a kernel
around 2.4.20. They have the same libs and mostly the same core apps. 
The kernel is implemented the same on all machines and usually, so is
the directory structures. As to each operating they own methodology
(assuming they're talking about people here), that is a good thing.
Windows does what it needs to (sometimes, on days ending in a 3, on odd
weeks and if the moon is in alignment with both Jupiter and Mondas), but
gives the user no choice. With Linux the manager can tailor each update
to each machine, so while core apps get updated, if only one person is
using OOo and another KWord, then the updates can be altered to reflect
this.

To me, this makes for far better management and less bulk.

> 4. None of the case study organisations knew of a recognised 
> implementation methodology that
> they could use.

I have a feeling that they've gone to UK higher education of Microsoft
for this!

> 6. Lessons can be learnt from the good and bad experiences of the case 
> studies, and these have been
> drawn together to create the list of proposed methodology 
> characteristics shown.

Rubbish. Utter Rubbish. Lessons are learned from a comprehensive study,
not a small subset, especially on a critical roll out. You must also
learn to ignore everything from SCO ;-p

> 8. Further case studies should be undertaken to generate 
> implementation-type specific control and
> management methodologies.

9. Further studies should be conducted by people competetant to do it
and who actually know what they're on about.

The document has the words "Microsoft" smothered all over it.

TTFN

Paul

-- 
One OS to fool them all
One browser to find them
One email client to bring them all
And through security holes, blind them...