LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for February 11, 2010Oracle layoffs and GNOME accessibilityIn 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 responseReports 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 GNOMEOver 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. The futureDoffman 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.
Development project prioritiesDevelopment 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 transition period:
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
background.
Others chimed in to agree with Jones, but anecdotal stories about individuals who are unable to upgrade doesn't really help in the decision. Mozilla's 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 take place:
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 addition, Apple 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 10.4 behind:
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
sure.)
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.
Three short stories, all about AndroidOccasionally, 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.
New toyThanks to some generosity on the part of Google's open source office, your editor is now in 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 and most 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 USA. 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.
Kernel participationGreg 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.
Free applicationsThe 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 source programs. 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 spouse. 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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||