Jeff Jaffe’s Blog

Part of every company’s values is to contribute positively to the communities we serve. In that regard, computer firms work together on some initiatives, such as improving access to computers by people with disabilities.

We were recently privileged to expand our technical collaboration with Microsoft and improve accessibility for Linux.

Current status

Currently, our SUSE Linux Enterprise (as well as most other popular Linux distributions) ships accessibility support based on the Accessibility Toolkit (ATK), developed in conjunction with Sun and others. Although this adequately serves its purpose, we nonetheless felt it was worthwhile to expand the accessibility developer’s toolkit in this area:

• It is part of our general philosophy of interoperability. We want to make sure that techniques, algorithms, programming interfaces, etc. from the Linux world and Windows world work well together.

• There are particular applications that come from Windows that are being moved to Linux. Examples include the Mono and Moonlight projects that we are working on within Novell. It makes sense for those projects to add accessibility in a compatible/interoperable way.

• Part of a general open source philosophy is to introduce many technologies into the mix as we look for communities of programmers to compare and contrast – and then use the comparative learning to come up with newer and better approaches.

• Access for the disabled is a social value that we support.

Our accessibility project with Microsoft

Microsoft has their own specification for accessibility called User Interface Automation (UIA). Today, it is focused on the Windows platform, but Microsoft, to their credit, would like this to be available on Linux as well. They proposed making it available – and in a step that Novell found to be very exciting – proposed not to assert patents needed for implementing this specification against open source (or proprietary) implementations – regardless of platform. With that important step this became very interesting to Novell.

The particular project that we are focusing on is an interoperability adaptor. First it makes the UIA API available for Linux applications to use. Second, we will be adding accessibility support for Winforms and Moonlight. Our implementations will be released under an open source license. Moreover, there are other accessibility frameworks that are available in the industry; notably the IAccessible2 standard supported by IBM and others. The freedom from patent assertion allows our work to complement IBM’s and, we hope, allow movement towards a harmonized set of accessibility APIs cross platform, easing the implementation of accessibility.

On August 12th my blog entry focused on preventing the fragmentation of the Linux ecosystem and thereby making Linux a more friendly platform for applications. I did not finish the discussion – leaving open various topics (like “how” to achieve this) for a later blog. Since then, this space has been consumed with the incredible pace of other Novell innovations.

It’s time to return to applications. Last week there were a variety of media reports about the declining growth rate of Linux. There were also analyses that challenged the validity of these reports [see here and here]. My purpose here is not to get in the middle of that debate. But one thing should be clear, based on the mere existence of the debate. The Linux community needs to be unified against common adversaries. We must attract applications. We must prevent fragmentation.

August 12th reprise

The main point on August 12th was to enlarge the ISV ecosystem.

Our larger competition is the Windows platform. Linux requires a situation (like with Windows) that ISVs can write once and be certain of running on any Linux. We need to unify the Linux ecosystem. We need to work more on standardization. We need to build upon the Linux Standards Base, but we need to take it further. It must be done in a vendor-neutral way.

Pragmatic issues

This was presented as a concept, but did not deal with many of the pragmatic issues. Herein, I wanted to discuss some of those issues.

• Focus. Linux as an operating system runs a very large dynamic range: desktop, server, carrier grade, consumer, commercial distribution, community distribution, etc. Any attempt at grand unification that immediately unites all of these stakeholders will struggle to get completion in a reasonable time. It would be prudent to begin with an important segment for the market – such as server standardization for commercial distributions.

• Staging. The Linux Standards Base provides a good start. However, there are too many areas – virtualization, security, file systems, management – where more specification is needed. My recommendation is that we get a technical team together to look at all key technology areas (for server), but then develop a staged plan. In this staged plan, we would constantly cover a broader set of technologies. But we also identify the stage (month and year) in which we get to each and every technology. In that way, we are assured that in a reasonably short amount of time we cover everything. Prioritization is based on importance of the technology element and maturity.

• Dealing with enhancement. There is constant innovation. Even after we have standardized an API, a new need will arise; new hardware; a new paradigm for computing. We need to expect, embrace, and support this. A standardized API does not prevent this. However, it creates a disciplined process to add enhancements.

• Management. No single vendor can control such an effort. A vendor neutral, open process must be used. It must rely on key open source principles such as sharing of code and selecting the best solution (rather than a politically oriented solution).

• Certification. Standards efforts do not provide ISVs with a single ecosystem. There are numerous standard interfaces (cf. POSIX) which do not imply that applications can run everywhere. In order to get to “write once and run everywhere”, we need certification. An ISV would certify to a standard definition of a Linux API (complete with a rich test suite) to ensure that they run on “standard Linux”. Linux distributions would ensure that their distribution supports that standard API so that once an ISV certifies to “standard Linux”, they know that they run on the vendor’s Linux.

• Sacrifice. There has been fragmentation to date within Linux distributions. To the extent that it has encouraged innovation, this is a (somewhat) good thing. However, all Linux distributions must recognize that, after a period of diversity and experimentation, we must select a “best” solution to every problem and standardize. This might cause pain and sacrifice: a Linux distributor might need to (gradually) abandon their approach to some technology in favor of a standard. In the end, this will be to the benefit of the entire Linux ecosystem.

• Investment. Many Linux distributors have made maintenance and support of Linux into a profitable business. There is temptation to solidify the investment by creating differentiation: some feature lacked by other distributions. As we standardize, we need to repress these desires for the common good. More investment money should go into testing, quality, and security.

Time frame

It will take some time for the Linux community to refocus itself to achieve standardization. However, some of the benefits will be instantaneous. Our mere commitment to simplify the APIs for ISVs and customers will immediately gain support from ISVs. While they want “write once run everywhere” immediately, many will settle for a commitment and a sensible roadmap towards that goal.