[clug] Your Best arguments please

[Damien Elmes]

"Carl Jackson" <carl at videohost.com.au> writes:

> Hi All,
>
>     I'm currently corresponding with an ACT MLA about OSS legislation
> and the MLA has challenged me with the article at the link below . I
> would appreciate the input of the list Brains Trust on the best
> counter-arguments. Any and all opinions welcome. Give it your best -
> there is a vote hanging in the balance here...

I don't attest to being smart or eloquent enough to speak for the
open source / free software movement, but a few parts of the article
provoked me to offer up my 2c, anyway.

The article begins with an introduction to what OSS is supposedly
about. The author jumbles together the concepts of platform
neutrality and open source software - as if the concept of open
standards and open source were one. I'll leave this alone for now.

Emotive speech and misdirection is present throughout the article -
such as "cautiously integrated", downplaying the large commitments
some major players have made to the open source world, and how much
they stand to benefit. The picture is painted of a few "rogue" big
players. A rebuttle to this is the amount of money IBM has vested in
linux, and how many companies now rely on OSS to be viable.

The author then moves on to the actual "case". This is presented in
three parts:

 * The "innovation only happens for profit" argument. Rather than
   attempting to argue with this, the point I'd emphasise is that
   mandatory OSS laws do not remove income streams - they just change
   the model. Instead of relying on one entity which you pay each
   time you decide you want to upgrade, in the hope that the new
   additions meet the features you need, you can contract out
   programmers to implement the features that your organisation
   requires.

   These changes can be kept internal to your organisation provided
   you do not wish to distribute the software - which is the case for
   most organisations - which alleviates the typical management
   concern that they're paying for the competition. The plus side of
   contributing the changes back to the community, of course, is that
   the community can then ensure that these changes are integrated
   into future releases - so the burden of maintenance is lowered.

   The author makes out like you're at the mercy of the OSS product's
   authors, and fails to mention that you're free to modify to the
   code as you wish, or contract someone to do so.

 * The "hidden costs" argument. The author doesn't even bother to
   justify this one, simply claiming the OSS route can "often be as or
   more expensive". It's a bit hard to argue with such a sweeping
   statement, but we can take issue with the line below - "Most
   proprietary software companies will include the costs of future
   maintenance and support in their packages.".

   This, as a rule, is not true, as most companies charge for updates
   to their software. In an enterprise situation with big money being
   spent on licensing costs, you have a lot more flexibility with
   updates, and a better chance of influencing development of the
   product to do what you want, since the company which produces it
   does not want to lose your business. Much of the money spent by
   government on proprietory licensing costs does not carry this
   influence, however, since it is distributed among lots of different
   departments without a cohesive voice. Small and medium sized
   companies also have no such bargaining power, and are left paying
   for updates which may or may not address their needs.

 * The "legislate and you'll kill all business" argument. There is
   some merit to this, and in order to avoid being pigeon-holed by
   authors like this that seek to protect their interests (or at least
   their schema), it may be necessary to avoid pushing for an OSS only
   solution, in place of a merits based approach. It is of course
   hyperbole, and businesses with alternative structures could spring
   up to meet different demands in government software. But this may
   be hard for an MLA to envisage in the short term, and so it might
   be best to take it "one step at a time".

   This also comes back to the "open standards" vs "open software" -
   it is perhaps a better place to make the point that companies can
   continue to operate as they have before (however non-preferable that
   may be), but so long as they operate on open standards, it is not
   possible to become locked into one solution. Here you can turn the
   argument of a merits based approach on its head, since without open
   standards, your choice of a proprietary solution can limit you from
   choosing a different solution with better merits in the future, if
   it's infeasible to migrate from where you are now.

Cheers,
-- 
Damien Elmes