Open source at Adobe

It's pretty apparent that much of today's tech world is powered by open source software. From Apache to Eclipse and Adobe Flex to Zope, you'll find open source in every aspect of development.

I'm director of standards and open source for Adobe's Platform and Developer business unit. I've been at Adobe for more than a year, but my open source and free software roots go way back. I wrote my first free source program at NASA on nonparametric statistical analysis. In the 1990s, I led efforts for open source at SGI for the GNU compilers, including the delivery of GNU compilers as supported products. I drove Linux adoption for SGI, including the release of core products such as XFS and OpenGL as open source. I've been involved in many open source–based companies, either driving creation of them (such as Cassatt Corporation, Egenera, and Sistina) or leading efforts to integrate open source into them (such as with NEC and now Adobe).

Over the last year, Adobe has become more directly involved in open source activities. While we've always worked with open source, we've taken things up a notch to deliver enterprise software as open source, and we've moved some of our premiere technologies, such as PDF, to open standards.

What is open source?

No official definition for open source exists. The term was created in Palo Alto, California, in 1998. In short, it is the ability to use, study, and modify the source code as you wish, without additional licensing costs. But it can also be considered a licensing term, a manifesto for computer users, or even a distribution model for software.

I think of open source as a conversation in source code, including the ability to change the conversation in unforeseen ways. Of course, that implies that proprietary code is a monologue.

Open source rules

Open source rules are simple enough:

• Allow free redistribution
• Allow source code access
• Permit derived works
• Protect the integrity of the author's source code

These are clear, common-sense rules. (They are also debatable, but that gets us into licensing hell.) The official version of these rules from the Open Source Initiative (OSI) is a bit longer and is focused more on a certification status. OSI rules concentrate more on the licensing of actual software or code. They don't express how a company should approach open source.

So what are the common sense rules for using open source from a corporate view? They are even easier.

Rule 1: Give credit where credit is due

If you use someone else's program, work, or code fragments, give him or her credit. This actually should go beyond open source; it's a good rule for life. For example, when I was at Cassatt Corporation, we built a complex automation control system that makes use of other programs, and thus we created a thanks page. (Don't ask why it's in the legal section.) If you notice, it's lengthy and yet clearly recognizes that using open source for development and delivery reduces the development complexity of Cassatt's data center automation tools.

Rule 2: Return value equivalent to what you receive

Note that this doesn't say, "Open source your products." This means that if you get something from open source, give something back. You can give back by recognizing the work of others, releasing code from other projects, hosting projects for others, or opening other significant code.

Who uses open source?

If you are a developer, odds are you use open source. From a survey of decision makers, open source is used by 71% of developers in the world, and 54% of all organizations use some open source in production systems. In fact, half of all companies claim that open source is increasing in use.

Do you use open source? Do you use Linux, OpenOffice, or Samba? How about Apache, Google, Amazon, PayPal, Yahoo, or Firefox? How about Flex, XMP, or Spry?

How Adobe supports open source

Adobe supports open source activities in multiple ways. We work directly with contributions to existing projects, such as WebKit and Eclipse. We work indirectly by supporting Adobe products on open source operating distributions, such as supporting Adobe Reader and Adobe Flash software on Linux distributions. We do pure research on development and make those implementations open source, such as the work with the Adobe Source Libraries. And we are releasing substantial code and products as open source.

These models reflect two types of involvement: hybrid and direct.

Hybrids are products or projects that make use of open source technology as a build element or a stack element. In short, a hybrid uses open source projects to provide benefits to a different product. A hybrid doesn't just mean getting code; it means adding value in other ways, such as:

• Collaborative models, which enable us to work with others on ambitious projects
• Lower-cost development models, which provide the opportunity for more creative input
• Faster and open development cycles, with substantial improvements in code quality

At the 2007 Open Source Think Tank, the discussion groups felt that all companies are hybrid to some extent. Adobe is a hybrid company. A short list of components we use or work with include WebKit, Eclipse, GNU compilers, and Linux.

Direct contribution is always the place that gets the most press. (As I stated many years ago, Linux itself will only be important when nobody cares that it's Linux. This is now true). For companies to begin to open code and open source products, they must also understand the drive behind open source. Not everyone immediately understands open source, and the process of education takes time. Fortunately, Adobe is always receptive to new ideas and new directions.

As it makes sense, Adobe will consider opening certain technologies and products to open source. But keep in mind, not all products make sense to open. We need to consider the impact it has on topics such as intellectual property rights (for example, patents, copyrights, and trademarks), revenue, cost, and process. We also need to decide whether such a move will enable our competition to take over a market by corrupting a project.

Over the last year, Adobe has released a lot of software as open source. Most commonly mentioned is the Flex SDK, our programming language for rich Internet applications. Following and accompanying Flex are several related projects: the Flex-Ajax bridge, the Flex-Ajax video bridge, and BlazeDS, a remoting and HTTP-messaging library for applications. Adobe has also released extensible metadata platform (XMP) as open source. In fact, the open source roots of the company can be tracked back several years with the Adobe Source Libraries and the Spry frameworks. Just recently, we followed up our November 2006 release of Tamarin (a virtual machine for ECMAScript) with a code contribution optimized for size and performance. This drop—part of the code repository for the Tamarin project—will enable the Tamarin virtual machine to run in mobile environments.

Today, numerous companies use quality code they received from an open source effort. Adobe will continue to invest in the open source communities and release new and exciting products as open source. After all, open source clearly leads to innovation and development of creative applications—and, at Adobe, we believe we have technologies and tools that can accelerate that innovation.

Note: This article appeared originally in the Edge newsletter.