[Osia-discuss] Re: [Linux-aus] ATO - Software Compatibility

Fri Nov 18 13:16:05 UTC 2005

On Thu, Nov 17, 2005 at 11:03:43PM +1030, David Lloyd wrote:

> > When asked...
> > "Do you believe that the Australian Taxation Office's Windows-Only
> > policy is a roadblock to the adoption of open source in Australia?" 
> > 72% of respondents to OSIA's industry survey said Yes.
> 
> Yeah, and any competent statistician would be able throw that statistic
> out the window. That's beside the point.

??? 

Are you suggesting that 72% of respondents *didn't* say Yes?

> What does your company do? Clearly it's not development or you wouldn't
> make such bizarre statements as "I doubt it would cost the ATO much to
> provide a linux ECI client".
> 
> How about:
> 
>  * testing time
>  * regression testing time
>  * project management
>  * extra support (considering there's six trillion linuxes vs 3 Windows
>    and 1-2 OS X)

I think that, in general, if Linux users trusted the ATO to give us a fair
go and make an honest attempt at writing a Linux compatible client, we'd
be satisfied with support for one distro only (Red Hat probably), or even
no support at all.

"We've done our best, here it is, now you're on your own" would be
satisfactory to many people if we thought that ATO really had done their
best and not just cobbled together a broken piece of junk so they can 
claim they tried.

> Not to mention that others have pointed out that it is possible to write
> Java code which is specific to a particular platform or platforms.

With sufficient time, ingenuity and expense, it is possible to create a 
grey-lead pencil that will only write if held at precisely thirty degrees 
from the horizontal.

I suggest the question is not "Is it possible to write platform-specific
Java code?" but "How hard is it to write platform-independent Java code
compared to platform-dependent code?", and according to my Java
developers, the answer to that question is "Not especially hard".

That's not to say that we will get anywhere by publically telling the ATO 
their developers (or more likely, sub-contractors) are a bunch of luser 
Windows weenies who can't write decent code and aren't using best 
practice. Even if it is true.

But we are free to think it among ourselves. Especially if it is true 
*wink*

> I have a product written in RealBasic which in theory should be portable
> to Windows (it's an OS X product). Yeah, it displays but it certainly
> doesn't do ANYTHING it's meant to do...

But it does do *something* it is meant to do: it is meant to display, and 
it does that.

But seriously, is there relevance to that factoid? We all know that a 
sufficiently bad developer can write platform-dependent code even with a 
platform-independent language, and some languages that claim to be 
platform agnostic are actually not.

The question isn't whether or not it is feasible to expect your RB app to
work under Windows -- without knowing what the app does, that is
impossible to answer -- but whether it is feasible to expect the ATO's EDI
Client to work cross-platform. Nothing I've seen suggests to me that it
isn't feasible.

> So let's drop the "It's easy part" and start to give them a reason to
> help us. Putting it bluntly it would be EASIER FOR THE ATO TO NOT
> COLLECT TAXES AT ALL (think of the money they'd save not having to
> process tax returns); they've said it's not easy so let's just accept
> the fact it's not.

But in fact they do have a Linux version, which they trialled, and they 
were innundated with folks wanting to trial it. That demonstrates both 
demand and supply.

> Noone who programs cross platform ANYTHING says it is easy, so why are
> we presuming this ECI (garbage) is?

That depends on what you mean by "easy", and what your software does. I've 
written dozens of Python scripts that will run on any platform which has 
Python. That's not the same thing, I understand that, but you've got to 
learn not to make sweeping generalisations around here :-)

> Concentrate on what the ATO thinks is the main concern: THEY DON'T HAVE
> A KNOWN MARKET FOR IT. Whether or not it is "easy" to port or not is
> beside the point - that's not addressing their concerns.

That's a good point. There are a number of ways of doing that.

Firstly, the ATO has inertia on their side. Even though they have a 
(partially/mostly) working Linux client, they won't want to do anything 
with it unless they know there is demand. Lots of demand.

We need to politely tell them we want to use it, and then we want to 
actually use it.

Secondly, we want to make them understand that the average Linux user has
a far higher level of technical expertise than they are used to. They will
not be getting terribly many calls asking "Where is the any key?". That's
both good and bad, because it means fewer support calls but the ones that
come in won't be fixed by the usual "restart, reboot, reinstall". But in
our favour, Linux users are more likely to provide good quality
information to the ATO, making bugs easier to track down.

Thirdly, there is another option. It probably isn't one bureaucrats will 
like, but you never know... we, by which I mean some group of volunteers, 
could potentially volunteer to support the Linux EDI client for the ATO. 
Of course they are subcontracting out the client already, but only the 
Windows and Mac versions. We could take on the burden of technical support 
for a nominal fee during a trial period, because _we_want_a_Linux_client_ 
and that's the only way to get it.

That's the rub: is there anyone here who wants a Linux EDI client badly 
enough to support it themselves?

Question: will the Windows client run under WINE?

Ultimately, we want the ATO to stop treating Linux users as third-class 
citizens. That's a chicken-and-egg problem: they won't take us seriously 
until we're significantly in their radar, and we won't be in their radar 
until they take us seriously.

-- 
Steven D'Aprano 
Operations Manager 
Cybersource Pty Ltd, ABN 13 053 904 082 
Level 4, 10-16 Queen St, Melbourne VIC 3000 
Tel: +61 3 9621 2377   Fax: +61 3 9621 2477 
Web: http://www.cybersource.com.au 