by Dave McAllister

Created

July 12, 2013

Companies these days are increasingly reliant on open source software. Whether it is external open source, or the planned release of internal technology under an open-source license, companies need to understand the rewards and risks involved. However, developers seldom like to follow intricate detailed checklist for quantifying risk within open source usage, or determining the needs for open source release. Therefore, a company needs to establish some basic structures or processes that help guide the decision-making process to a satisfactory conclusion, and as light a weight manner as possible.

Over the past six years, Adobe has developed and refined a process that strives to align within the company’s interest as well as meet the needs of our internal developer communities. Obviously, such a process walks quite a tight rope between the business of generating profits and the benefits of open source involvement. While our activities are both outbound and inbound, the decisions made in order to release technology under an open-source license and to an open source community are far more intriguing.

It is clear that most companies operate under some basic fundamental principles. Most companies are in the business of creating profit. Most companies consider the code developed by their engineers to be owned by the company. As companies grow larger and expand product offerings, multiple groups may be impacted by the release of such proprietary software as open source. And while it often appears that releasing code as open-source software is on a case-to-case basis, such decisions are best reached within the framework of an overall corporate strategy.

So let’s start with some basic rules for considering the release of technology as open source.

  1. Does anyone care that the technology is being released as open source?
  2. Do you have fundamental business and technology reasons for the open source release?
  3. Who owns the project? Does the project remain active within the company?
  4. Who pays for the project? (Open source isn’t free.)
  5. What shape is the code in?
  6. What makes this technology unique? Do competing open-source projects exist?
  7. What about the legal issues?

Most of these items are actually common sense, and not unique to a specific company. However, we often find that these common sense items are not considered or not taken seriously enough. Open source proposals often arise from product strategic needs, such as the ability to expand and create platforms for others to innovate upon. Additionally, the open source community often innovates, improves, and corrects the base release itself. Such activities can provide financial incentives for the release of technology into open source, however it is important to note that building a community and maintaining continuity is an ongoing effort and that integration itself can be costly.

Over the past years Adobe has created and improved its processes for release of technology or working with existing open source projects. While our process may not meet all needs, we believe that the basis of our decision criteria, approval aspects, legal, and community are useful for us in considering the impact of such technology releases as open source.

COMMENTS

  • By clifford - 5:41 AM on July 18, 2013  

    [Edited comment] The submitted comment was towards Adobe proprietary products, thus redacted. The comment has been forwarded to the appropriate individuals and groups.