In the wake of Sun's acquisition by Oracle, the future of MySQL has attracted the most voluminous (and often, the most heated) debate, but it is far from the only open source project to feel the effects. Linux and open source community members have publicly taken Oracle to task this week for its decision to cut the jobs of developers at Sun's Accessibility Program Office (APO), which contributes heavily to GNOME's accessibility efforts, as well as to accessibility work in Firefox, OpenOffice, and other applications.
Accessibility in open source incorporates assistive technology tools for users with disabilities, including screen readers, magnifiers, speech interfaces, on-screen keyboards and other input mechanisms, but it includes toolkit and application features in the rest of the software stack as well. For example, GNOME's Accessibility Toolkit (ATK) API enables assistive technology applications to read a program's existing GTK+ widget labels. Custom components require additional work than all-stock-GTK+, of course, and any application must take steps to be accessible through associating textual descriptions with all user interface elements, including buttons, canvases, and status indicators.
Cuts and response
Reports were circulating in the first week of February that two APO jobs were being cut, one of which belonged to Will Walker, leader of GNOME's Accessibility Project and the project maintainer for Orca, the open source screen reader. The reaction to Walker's layoff was swift, with members of the Orca and GNOME projects expressing their support and calling for a public display of that support — and concern over what the move said about Oracle's commitment to accessibility.
Several accessibility experts and developers voiced concern through mailing lists and blogs. Orca user Mike Gorse blogged his fear that Orca development would slow down and suffer. Discussion on the Orca list ranged from the pessimistic to the unconcerned, with some confident that the work would continue and others advocating the immediate search for alternate project funding.
Joanmarie Diggs, assistive tech specialist with the Carroll Center for the Blind, published an open letter to Oracle, challenging it to "embrace the opportunity to continue this important work." Fernando Herrera wrote to the GNOME Foundation board urging it to "take this issue very seriously" and approach Oracle representatives for a resolution.
For his own part, Walker assured the Orca and accessibility communities that he would continue to devote as much of his time as he could to the projects as a volunteer, but said that he would have to seek employment regardless of whether or not he found another position that allowed him to contribute to Orca and GNOME full-time. Specifically, Walker said he remains committed to seeing through the upcoming 2.30 release of GNOME. Beyond that is where the future becomes less certain.
APO, accessibility, and GNOME
Over the years, Sun's APO contributed to considerably more than Orca alone. Walker described Sun's support of open source accessibility as the "best in the industry" and said he was lucky to have been part of it. Walker joined APO in 2005, after several years working on accessibility at Sun Labs. Initially his duties focused on Orca, but over time expanded to include accessibility overall.
APO served several purposes, Walker said, including that of a "centralized organization to help guide, consult, etc., all things related to accessibility" in addition to software engineering itself. Much of that work consists of testing, filing bug reports, performing maintenance, and addressing deprecation in GNOME applications and key desktop components like Firefox and OpenOffice. It also includes educating the developer community at large on accessible design, development, and testing as parts of everyday practice.
Since the 3.0 planning process began, one of Walker's most important duties as a GNOME Accessibility lead has been preparing for platform changes. GNOME 3.0 will do away with the CORBA object model, which in turn will require GNOME's implementation of the Assistive Technology Service Provider Interface (AT-SPI) to migrate to a completely new, D-Bus-based backend. In addition, several assistive technologies will undergo major updates, such as the deprecation of gnome-speech in favor of SpeechDispatcher, and moving screen magnification into GNOME Shell.
Over the past two years, however, Walker said that the work has felt "like swimming upstream," thanks to the changes in GNOME, Firefox, and other desktop components, coupled with reductions in the number of programmers available to work on GNOME accessibility. Not only have there been other job reductions at Sun to hit APO, but full-time developers have been cut from other contributors, such as IBM. Mark Doffman cataloged the losses on his blog, estimating that $200,000-worth of annual accessibility developer support has disappeared since 2007.
Nevertheless, Walker said that he has no "sour grapes" about his current situation, and is looking forward to seeing GNOME Accessibility succeed. How best to bring that about remains the topic for discussion among GNOME and other open source developers.
Doffman advocated actively seeking out corporate support for more accessibility development, citing Jonathan Corbet's estimate at linux.conf.au that 75 percent of Linux kernel code is contributed by paid, full-time developers. GNOME's Dave Neary contended instead that the GNOME Foundation should look to government and non-profit grants as a source of income to support accessibility development.
For his part, Walker said that funding from Mozilla, Canonical, Google, Novell, and AEGIS have all provided relief in recent years, but that the contributed funding model risks turning into a "coin operated" development mentality: when the coins stop, the development stops. Instead, he emphasized the need to grow the developer community itself and to spend more energy educating mainstream developers about incorporating accessible design in their work.
With all the publicity Oracle is getting in relation to their effect on GNOME Accessibility, I think we need to remind people of something else. As I understand it, Oracle's product teams design and develop for accessibility. In other words, Oracle does appear to have succeeded in making accessibility a core responsibility of each product team. If my understanding is accurate, that is *huge* and something other organizations can learn from.
Oracle does, indeed, make accessibility a high priority item, highlighting it with policy statements, and providing training and support. As Walker said, success for accessibility efforts in open source software is not limited to the development of stand-alone assistive technologies like Orca, but in building integrated accessible design into every tool and application.
In the near term, the GNOME 3.0 roadmap includes a long list of open
tasks, many related to the AT-SPI migration. KDE developer Jeremy Whiting
provided a status
update of the situation from KDE's point of view. GNOME and KDE have
collaborated on the latest AT-SPI work, including the D-Bus backend. Qt
provides an accessibility framework, but is lacking a Qt-to-AT-SPI bridge.
While the good news is that both major desktops agree on a common framework
for accessibility and assistive technology, both have considerable amount
of work cut
out for them.
Oracle is not closing the Sun APO entirely, nor is GNOME's Accessibility Project shutting its doors. But the impact a single full-time developer can have on an important infrastructure effort like accessibility indicates how under-staffed the effort is — as well as how many open source projects benefited from Sun's investment, despite the grief it sometimes received. The public support shown for Walker demonstrates that the community wants open source accessibility work to receive the attention it deserves, it just needs to solve the funding problem.
Comments (3 posted)
Development projects are often required to make hard decisions about where
to apply their effort; developer and tester time is a scarce resource, so
choices must be made. It is not uncommon that those choices will be
unpopular with some, perhaps quite vocal, segment of the user community,
but users need to recognize that prioritization has to occur. Free
software projects, even those backed by foundations or corporations, are
obviously not immune to the need for focus. A recent discussion about
Mozilla dropping support for Mac OS X 10.4 shows that some users still
don't quite understand the issue—especially when it is their platform
that will be affected.
It all started with a
post by Mozilla's Josh Aas about making a
final decision on whether to support Mac OS X 10.4 ("Tiger") in the version
of the Gecko rendering engine that will be the basis of the next Firefox
release (3.7 or higher). He listed statistics of the number of Mac users
that still use 10.4, which was released in 2005, and noted that there were
significant hurdles to continuing to support that release in the codebase.
Furthermore, he pointed out that there will be a roughly yearlong
The approximately 25% of our Mac OS X users still on 10.4 would
continue to be supported by Firefox 3.6 until that product reaches end
of service, which won't be until several months after the next major
version of Firefox is delivered (built on Gecko 1.9.3) later this
year. Past data shows that we do not lose appreciable market share
when we stop supporting a Mac OS X version. We are often one of the
last vendors to continue supporting older Mac OS X releases, and I
suspect that by the time this becomes an issue Apple may themselves
have stopped issuing security updates for Mac OS X 10.4.
But that didn't sit well with some Mac users. Phillip Jones argued against dropping support because it
would require hardware and/or software upgrades—at a substantial
monetary cost—for those who still use 10.4. He also claimed to be
speaking for lots of others:
And I am not the only one. I just happen to be the only one to voice an
opinion. Most just take what they are given and stew in the
Others chimed in to agree with Jones, but anecdotal stories about
individuals who are unable to upgrade doesn't really help in the decision.
Asa Dotzler points out the kind of
information that would be useful:
Since this decision won't be made because a few users visiting this forum
are still bound to 10.4, this kind of advocacy doesn't help much. If you
can add more precise usage data to this discussion than what Josh offered
in the initial post, please do. If you know of other kinds of data that
represents large numbers of Mac or Firefox users that hasn't already been
mentioned, please add that.
Dotzler continues by noting that the decision is not being made lightly,
nor is it being made in a vacuum, but some kind of prioritization needs to
I (and I'm sure others here) recognize that tens or even hundreds of
thousands of users will be left behind in a year or so if we stop support
for 10.4. We understand that. If we tried to support 100% of operating
systems out there, the project would collapse.
That means we have to pick our target versions carefully. Do you have some
suggestion about what that cut-off should be that goes further than "not
the platform I'm on" ?
Many of those who are against the change are making a "not in my
backyard" (NIMBY) argument, as Dotzler points out. Others believe that
because Mozilla gets millions of dollars in revenue, it should plow
some of that money into supporting 10.4. It is not a terribly reasonable
argument, as organizations should be able to make their own decisions about
staffing and such. It is also a bit ironic that folks claim that Mozilla should
support them in ways that Apple will not.
The real problem stems from Apple's decision to only support 10.5 ("Leopard") on some
PowerPC Macs, and to only support 10.6 ("Snow Leopard") on Intel Macs. In
charges for each upgrade, which potentially leaves those who are
financially strapped behind.
It is not particularly fair to blame Mozilla for something that has its
roots in Apple's upgrade strategy.
Those calling for Mozilla to go the extra mile for 10.4 are really asking
for a "disproportionate investment", according to Mozilla's Boris Zbarsky. In
addition, they haven't made a good case for why that should be:
"No one has cited a good
reason why 10.4 users matter more than 10.5 or 10.6 users or Windows or
Linux users." There are technical reasons why support for 10.4 is hard,
as Aas outlined at the start of the thread, so there needs to be a
compelling reason to do it.
Allocating resources is a difficult problem sometimes, but one gets the
sense that Mozilla developers are pretty convinced that 10.4 is not a good
use of their efforts. Mozilla VP of Engineering Mike Shaver also
points out that Apple seems to have left
What amount of resource should we divert from other areas,
such that we can support a small-and-shrinking number of users on a
trailing edge version of a deeply-minority platform from which we get
decreasingly poor support from the OS vendor as it ages? (When we
report even *security-related* bugs in older system libraries to
Apple, we often get a pretty cold response. This may not be a problem
that the WebKit or Safari teams face, but I can't really know for
It would be easy to write this off as a problem for folks that have chosen
a proprietary operating system, but this same problem is regularly faced by
those who run free systems. Projects frequently make decisions on their focus: distributions choose architectures to support, applications
choose which features to implement or what desktop to support, and so on.
Users need to find a way to make reasoned arguments about what they would
like to see happen, while understanding that the project itself gets to
make its own decisions. On the flipside, projects need to provide a means
for users to give their input, hopefully in a constructive manner.
Advocacy—along with venting—in bug reports was another problem
discussed in the thread. "Piling on" to bug reports and feature requests is a common reaction
for users who are frustrated with the choices a project is making, as we
saw last August for KDE.
More recently, the addition of
CNNIC to the Mozilla certificate store also had many impassioned users
commenting on the bug, but without providing the kinds of information
needed by the project to assist its decision making process.
Some kind of balance needs to be found, where users feel like their voice
is being heard, without overwhelming the developers and project leaders who
are trying to do their jobs. For free software projects, though, there is
a potential solution that is not available for those using proprietary
systems: the code is available if someone wants to put together a project
to go a different direction. While some Apple users will never be able to
run more recent versions of Mac OS on their hardware, they most certainly
could put together a project to continue supporting Firefox on those older
versions. It would be a lot of work, but that's a much better situation
than for Mac OS where it would simply be impossible.
Comments (19 posted)
Occasionally, your editor will be struck by a series of topics all
associated with a common theme. The recent fuss about Android's presence
(or the lack thereof) in the mainline kernel ties in well with a couple of
other items of notice: the Nexus One phone and the role of free software on
the Android platform in general.
Thanks to some generosity on the part of Google's open source office, your editor is now
possession of a shiny new Nexus One handset. For some, this might not
seem to be hugely exciting news; the Nexus One is another Android phone,
and Android has been reviewed here before. That said, this device is
noteworthy, to that point that its predecessor (an Android Dev
Phone 1) has found itself headed toward early retirement.
As hardware goes, the Nexus is a beautiful device. It's less bulky
than the ADP1, but it's far more capable. The screen is gorgeous
and more responsive to touch than the ADP1 screen. The device has a real
headphone jack, making it easy to connect to arbitrary audio systems. (On
the other hand, the use of yet another mini-USB connector format for the
charger is not
appreciated). The camera works well and audio quality is good. Perhaps
nicest, though, is the 1GHz processor, which makes this device the fastest
responsive phone your editor has ever used.
The Android software has progressed somewhat beyond what is currently
available for the ADP1. There is a 2.6.29 kernel (sort of - see below) and
lots of eye candy. The device now has turn-by-turn navigation built into
it - a great feature; it's just too bad that the voice that comes with it is so
annoying. Your editor would suggest that anybody wanting a Nexus One, but
lacking the resources to purchase one, could simply search alongside busy
roads for handsets thrown out the window when their owners realized they
simply could not listen to that voice any longer. "Goggles" will perform
searches using the camera, which could prove useful for those "WTF is
that?" questions. With the recently-pushed update, Google has finally
incorporated multitouch into the device, even for those of us living in the
The point of an open Android phone, though, is that one need not live with
what the vendor has provided. The Cyanogen builds are the definitive
alternative firmware for Android phones. As of this writing, builds for
the Nexus are in a rather early state; in fact, only a beta
image is available. There is also the obligatory enhanced
recovery image out there. For the less adventurous, there is also an add-on
image from Cyanogen which adds various command line utilities and an
improved kernel to the existing firmware. Your editor hopes to be able to
play with all of these in the near future, stay tuned.
Greg Kroah-Hartman's recent discussion
of the removal of the Android code from the staging tree contained
little in the way of surprises, but it seemed to surprise enough people
anyway to get a wide distribution. The problem here is simple: Google did
its Android development work behind closed doors, then threw it out into
the world as a fait accompli that was not subject to outside improvements.
This code, unsurprisingly, was not seen as fit for immediate inclusion into
the mainline kernel, even when non-Google people made the effort. It's a
rare patch that doesn't need some sort of change; patches adding strange
new features - some of which duplicate existing functionality - have an
especially hard time.
Shipping new kernel features to users before being sure that those features
will be accepted upstream can be a fundamental mistake, especially where
new APIs are involved. Kernel developers tend to be cautious about API
additions, since they must be supported forever; any API shortcomings need
to be fixed before they can be merged. But if that API has been shipped to
customers, the company responsible is faced with the choice of imposing an
API change on those customers or maintaining the code as a fork.
Google seems to have taken the fork approach; indeed, recent comments from
Google employees suggest that the company sees no problem with long-term
forks. It is a little strange to hear that a few months after another
Google employee gave a talk
on how the company wants to work much more closely with with the kernel
community. The kernel has been one of the unifying factors that has helped
Linux to avoid the kind of fragmentation which plagued proprietary Unix and
which we have seen in the BSD community as well. Google is doing a lot of
things right; it has created a Linux-based phone platform which can
compete with the best. It would be a shame, though, if Google were to do
all this at the cost of bringing unwanted fragmentation to Linux.
The Android "Market" gives access to a wide array of applications. Many of
those cost money; others are free. There's even a button to select only
free applications, for those who are not looking to pull out their credit
cards at the moment. But "free," in the Android Market sense, is purely
"free beer." Some of the "free" applications are indeed free software, but
there is really no way for the user to know that or to look specifically for free/open
Twenty years ago, many of us were busily installing free applications on
top of proprietary kernels and low-level libraries. The arrival of a
viable free kernel made it possible to create 100% free systems, and large
numbers of people have never looked back. Now, with Android, we have a
free kernel which is heavily layered with proprietary applications on top.
These applications cannot be changed or fixed, and they can lead to
unfortunate situations like the cease-and-desist
notice served against the
Cyanogen build last year. They can also be loaded with antifeatures; your
editor was recently put into the position of having to explain the
"Unlimited girls on your G1!" ad helpfully displayed by WeatherBug to his
There are good free applications out there. The ConnectBot SSH client can
be hard to do without. Astrid looks
like a useful task manager; Tomdroid can be used in that mode
as well. Android-wifi-tether
is a hugely useful utility which turns a phone into a wireless access point
connected through the cellular network. (Note that use of this tool may
well put one at odds with one's cellular carrier; it also requires an
enhanced kernel on some platforms). Your editor is not prepared to be
quite so enthusiastic about the K9 mail client, but it is
improving, slowly. Ringdroid is a good way to
make your own special annoying ring tones. And so on.
Clearly, free applications exist for Android. But finding them takes work,
which is silly; this is a perfect job for a computer. An ideal solution would be
for Google to add a "freely-licensed" option to its (proprietary) market
application. Failing that, it should be possible (for somebody with a bit
more Android application-level programming experience than your editor) to
put together an alternative market application which would focus on the
growing body of free software for the Android system. It is an area worthy
of encouragement; free software doesn't become less important just because
it's running on a machine that fits into a shirt pocket.
Comments (53 posted)
Page editor: Jonathan Corbet
Next page: Security>>