[oats-sig] Comments on the OATS project -- from the perspective of a FOSS developer

I've read what I could find of information on the OATSoft website 
including the poster and pilot project report document (or parts of it). 
As you know I've also participated on the list here a bit now, and I'm 
starting to feel I understand the project reasonably well.

So, before I continue, I just want to applaud the initiative taken by 
the founders and other participants! I think that the AT field could 
benefit greatly from more emphasis on collaboration and open source. In 
this (long) posting I'll comment on the the project design from the 
perspective of an open source developer.

First, I'd like to take a step back and ask what is the fundamental goal 
of the project? As far as I can see the goal can be formulated as:

"To provide better computer access for the disabled user community 
through the use of Free and Open Source Software."

(In fact only the first part of that is the goal and the second part is 
the chosen method.)

The phrase "better computer access" can in my view be expanded as: 
creating solutions that are effective, reliable, simple, affordable and 
sustainable (what we make now should be relevant in 10 years time, 
though in an evolved form).

As an Open Source enthusiast I'm happy that this project has chosen open 
source as the vehicle by which to achieve that. But at the same time I 
acknowledge the fact that for most disabled computer users (and other 
computer users) the open-sourceness of their tools is not the key 
factor. I think we should keep in mind that the quality of the result is 
more important than the license used for those who end up using it. (I 
personally am a strong believer in open and shared development though, 
and I'm convinced it produces better software for the user in the long 
term and is a better use of resources).

Given the above as the core goal (good provision) and core strategy 
(open source) we can look at the implementation strategies in more 
detail. As far as I can see the OATS project has chosen two parallel 
paths here: 1. to provide better information to the user community on 
the available Open Source assistive technologies and 2. to help foster 
the development and improvement of these tools. I think we can add a 3rd 
point resulting from the other two, which is: 3. to improve the flow of 
information and understanding between the user and development 
communities. I think the last one is very important and should be a key 
focus of the OATS project.

This is still very general. I haven't mentioned the Repository or the 
Forge implementations yet. Before these can be discussed I think we need 
to consider the target groups for points 1 & 2 above.

The beneficiaries of the collated information on FOSS AT solution will 
primarily be end users, AT professionals and possibly FOSS developers 
wanting an overview of the field. The users of the development portal 
would be existing open source developers creating AT tools and 
traditional AT developers looking at the open source approach. Users and 
AT professionals may also use the Forge to file feature requests and bugs.

With that in mind I'd like to make some suggestions for slight changes 
in focus for both the Repository and the Forge.

Repository:
----------------

Providing Information:

A major aspect of the Repository is application review. Assistive 
technology applications are listed by category and some background 
information is provided.

First I think it is important to clearly define which applications will 
be covered by this listing. Is it only purpose-made assistive 
technologies, or will general-use applications also be included? And if 
so, where will the line be drawn? Ubuntu currently has 18.000 
applications in it's repositories, and growing. It's obviously not 
feasible to cover all of those. It probably is useful to include some 
very common general-use applications like Firefox and OpenOffice, but in 
that case they should have a separate category and have a rough set of 
inclusion guidelines, like 'essential desktop applications'.

Next, I think it's important to set certain guidelines for the purpose 
of the information. Some general background information is useful but 
that is different from a critical review from an AT perspective.

Taking this page as an example: http://www.oatsoft.org/Software/firefox 
The page has a general blurb which is fine, but 'The award-winning Web 
browser is better than ever. ...' is perhaps not the most appropriate 
for this site. On the lower section of the page the pasted content from 
the firefox website continues, but that's better because it's preceded 
with a heading explaining where it's from. Missing from the Firefox page 
is that Mozilla has some serious weaknesses with accessibility on Linux, 
which will not really be addressed until Firefox 3.0.

I suggest making sure the top blurb is quite neutral, and have that be 
followed by links to reviews on the OATS site done from an AT 
perspective. The further general information can follow, but in my view 
the reviews are the most important. If there are no reviews there should 
be a notice indicating that:

  "There is currently no OATS review for this item. Click here to submit 
one."

That text makes it clear that critical AT reviews are a key component 
and that the other information is fairly general.

Packaging:

Next, there is a question of whether the repository is intended to be an 
actual source of AT utility downloads or just be a collection of links. 
In the former case it is important to appreciate the difference in how 
software is packaged on different platforms. On Windows you typically 
download an .exe file which is a self-contained installer. In this case 
there is a good case for seeking a unified way of installing the 
utilities, by making similar installers for all of them, with NSIS say. 
This can be done by members of the project or by helping the original 
authors ('upstream' in OSS lingo) to use this method.

On Linux the situation is different: A package is made specifically for 
for one distribution and one release. The downside is that you get lots 
of different packages which will only work properly in a specific 
situation. The upside is that the unified and simple install method we 
are seeking already exists on Linux. You can download a .deb for Ubuntu 
or an .rpm from Fedora, click on it and it will install itself in the 
right place without fuss. It's esp. easy if the package has been made 
available by the distribution itself because then you don't have to hunt 
for the right file or manually download anything. Just browse or search 
'Add Applications' and click to install.

The point is that on Windows it's a good idea to make the packages 
within OATSoft while on Linux it's better to encourage the distros to 
make them available. In both cases I would recommend letting the 
Repository be a set of links to the latest versions instead of hosting 
actual files, otherwise you duplicate work, risk being out of date, need 
more hosting space, etc.

On using Plone:

The choice of CMS software is always a difficult one. There are many 
opinions and each system has it's advantages. We were using Plone for 
the main Ubuntu website for a while but decided to switch it over to 
Moin. We wanted something more flexible, and also found it to be more 
stable.

I will refrain from making a firm recommendation on this point, but I 
think you should consider a wiki-based solution which will make it 
easier for more people to contribute.

The Forge:
---------------

The core idea of making facilities available to support the creation and 
improvement of OATS is a good one. Getting it right can be difficult 
though because FOSS developers are very particular about their tools :)

I can see two primary use cases for such a facility: a) developers who 
already develop FOSS and are about to start working on some AT utility 
or b) developers of AT tools who are new to open source or are about to 
open source one of their projects.

(Yes, there is a small group of developers already creating OATS but our 
target must be the 'other' ones if our aim is to expand this activity).

For group (a) this is probably a hard sell because you are asking them 
to adopt additional tools to what they are already using, such as 
SourceForge or Launchpad. They would prefer to use as few such tools as 
possible so they can have everything in one place and would also be 
resistant to using tools that had less functionality or worse usability 
than their current tool-set. In reality FOSS developers work on several 
projects at a time and so they may be involved part time in an AT 
project for a while and then move on to other things, or their own 
applications may have some AT issues that they need to address. It would 
be asking a lot to expect them to use a different set of tools (ie. 
different development site) for this small part of their work.

For group (b) the arrangement may seem a better match in the short term 
because it would create a community of people working on AT that new 
developers could fairly easily fit into. However in the longer term I 
think you may do them disservice. What we really want is to mix AT and 
'other' developers in the same environment and hopefully attract more 
FOSS people to work on AT through this interaction. Also when you work 
on AT tools they often need to interact with the desktop and major 
applications, so you really should be working in the same environment 
where those things are being worked on.

I don't think it makes sense for the OATS project to reinvent a software 
tracking system at this point. At Canonical we have a team of 10-15 
developers who have been working continuously for over two years on 
writing Launchpad from scratch. It's getting fairly mature now, but the 
work continues. I'm sure a similar effort has gone into SourceForge. 
It's no small task.

However there are several important functions that a 
development-oriented website could serve:

1. An OATS development overview - A comprehensive list of the different 
OATS applications under development would be useful, complete with links 
to existing source code repositories, bug trackers, feature request 
facilities, specifications, etc. This area would include software that 
may not be listed in the Repository section because it's not mature 
enough or because it's infrastructure that the user shouldn't need to 
know about.

2. Developer documentation - A comprehensive list of links to relevant 
documentation used for reference (such as the AT-SPI docs). An 
introduction to assistive technology for those who are new to that field 
and an introduction to the open source process and relevant tools for 
those AT devs new to FOSS.

3. Facilitate detailed communication between users and developers - End 
users might arrive at the Forge site via a link in the Repository and 
want to comment or contribute in some way. There should be an 
introduction to how bugs are filed and features are requested, with 
relevant links for individual applications.

OK, that's it for now. I think an important role for the OATS project is 
to help mix the waters of the AT and open source world and encourage 
things to emerge from that process. There is a willingness to work on 
this in both communities, we just need more communication and collaboration.

Henrik Nilsen Omma
Ubuntu Accessibility Coordinator