July 12, 2013

Friday Philosophies

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.

9:53 AM Permalink
March 15, 2013

Open Source and the OpenStand Principles




Last week, March 9, I had the privilege of representing Adobe at the Open Futures reception and meet up at SXSW, hosted by IEEE, W3C, Cisco and Adobe. The event was fun, full of excitement and indicative of the importance standards play in our ever-changing interconnected world. The event was in support of OpenStand, a movement dedicated to promoting a set of principles that enable standards to keep pace with technology and provide access to all.




The OpenStand principles are five in number. They reflect common sense dedicated to the advancement of technology based on merit. In short, the principles are:

  1. Cooperation among standards organizations
  2. Adherence to due process, broad consensus, transparency, balance and openness in development
  3. Commitment to technical merit, interoperability, competition, innovation and benefit to humanity
  4. Availability of standards to all
  5. Voluntary adoption

These principles, the Modern Paradigm for Standards have empowered the rapid development of the Internet and the World Wide Web.

In 1993, when Adobe released the Portable Document Format, the decision was made that the specification would be free for all to use.  In 2008, Adobe worked to ensure that the newly published ISO 32000-1 standard for PDF would remain free for all to use.

The principles of OpenStand are embedded into Adobe culture and into the mindset of our decisions concerning standards and specifications.  Adobe has and will continue to contribute to the creation of innovative activities and standards, as evidenced in this blog from the Corporate Standards group.

So how does this apply to open source? Obviously open source software both exists and innovates on standards. Many standards, as they innovate, use open source implementations to power the definition of the emerging specification. Witness such work as WebKit, OSGi and work within CSS. Emerging efforts tying open source to standards development are showing up in an ever increasing number of standards development organizations such as ECMA. Particularly but not limited to web standards, Adobe is actively involved in innovation to standards as well as open source projects in support of emerging technology

It is in the best interest of open source developers, be they individuals or corporations, that the principles of OpenStand be accepted and promoted. Open source developers lose when access to standards is limited and/or costly. Open source implementations win when access to the specification is freely and readily available, to allow creation of the best possible implementation to adhere to standards adopted worldwide. Open source implementations in turn drive innovation and create new markets, emerging technologies, on a worldwide level.

Not only open source developers but also foundations based on open source should recognize and support these principles. It is important that Linux distributions be able to offer compliant communications standards. It is important that browsers such as WebKit, Chrome or Opera support the appropriate standards. It is in the best interest of foundations such as Apache Software Foundation, Linux Foundation and Eclipse Foundation support the transparency, voluntary adoption and availability of standards to all.

Likewise, it is in your best interest to go look over the Modern Paradigm for Standards and decide if you can support these five principles promoting market driven standards that are global and open, to drive innovation for the benefit of all.

Cat looking up at Blog (Nero, to be precise)

8:03 AM Permalink
February 20, 2013

It’s almost Open Source Think Tank 2013 time

The Open Source Think Tank has consistently delivered a chance to work with some of the brightest minds to answer tough issues and drive new solutions, to discover new ways of innovating and catch up on changes in the industry.  This is my one “can’t miss” event each year.

As usual, the event is targeted at senior executives (and bright people irregardless) to discuss the currents and directions for open source in the industry.  Over time, the OSTT has evolved into its format of panels, discussions, group think sessions, all targeted at discovering and inventing ways that open source principles and practices can solve complex problems.

Unusual for open source, the target solutions and discussions are not purely a developer model. And this may be the continuing strength of OSTT; the fact that we discuss issues that fall outside of code.

This year, the agenda indicates that we will delve into OpenStack, the open source software for clouds, and a discussion of how Netflix uses open source to compete differently.

Last year we covered GENIVI and OSEHRA, two projects that have significant impact on how we see open source changing the world. We’ll get reviews and updates of these projects. We’ll also get a legal update, which itself is always significant.

Of course, OSTT is a chance to meet and chat with some of the names in the space. For me it’s a chance to catch up and find out what exciting things are happening all over technology, from the folks making it happen.

So as I prepare for OSTT 2013, feel free to drop me a comment on what questions you think are important for open source in  general.

(Disclaimer: Adobe is a sponsor of OSTT 2013)


10:53 AM Permalink
February 1, 2013

Dem Bones, dem bones, dem Dragonbones

In gamification, one of my favorite mechanics is unexpected surprise and delight. For instance, on my drive to the train ever day, I pass a six foot tall tyrannosaur rex. It was a surprise (and a smile) when it first appeared.  Of course, passing it every day would soon become normal, and soon invisible.

However, every now and again Rex appears in costume, relevant to the season and time.  I’ve seen him as an Easter Bunny, dressed for Halloween, chomping Rudolph during the holidays. The changes make us all watch for him to appear, to see what new things have appeared. (Right now he’s dressed as a San Francisco 49’er, in time for the Super  Bowl.) So, imagine my surprise and delight to discover a new open source technology release, Dragonbones.

Dragonbones Badge

DragonBones is a 2D skeleton animation system. It’s designed for common 2D display engines so you can easily use it if you are building a 2D project. It’s very useful to build natural skeleton animation. And it’s open source, released under the MIT license.

This system currently includes 4 projects:

There are some pretty cool skeleton animation demos out for you to check out as well.

Dragonbones is already tied into Starling, and into the Citrus engine.  And potentially others (let me know in the comments).

Anyway, go check out Dragonbones…


10:57 AM Permalink
October 2, 2012

Impact Imminent: Open Source and Standards

Many years ago I wrote a posting on the similarities between standards development and open source.  It seems like now would be a good time to revisit that topic, given all the activities that are blurring the barriers.

The premise still remains.  Standards are designed to stabilize a technology or interface, package or connection. Open source is driven by continual development. Standards tend to update and publish on a schedule measured in years, while open source updates and publishes in sometimes days. Standards drive the status quo. Open source  (often) drives innovation.

However, the engagement between open source and standards are creeping ever closer together. We now see significant standards developments defined by and driven by corresponding open source work. Think HTML5, CSS, even (now emerging) ECMAscript (Javascript by any other name).  We have seen significant trends to allowing the acceptable advances in open source software to define the standard.next. In short, the cycle of innovation adoption within standards is becoming significantly shorter as a reflection of the popularity of ideas expressed within open source products.

This really shouldn’t surprise anyone. Open source is the operative paradigm for development these days, whether it is within a company firewall or not. Open source underlies even the most innovative of closed software products.  Estimates from analysts state that 90% of software is a hybrid of open source and closed source code.  Open source practices help define innovative techniques, or to paraphrase “Linus’ Law” from Eric Raymond, “Given enough eyeballs, all ideas are approachable.”

Even certain of the conceptual business models of open source align with standards development. In software, revenue is often driven by scarcity. In open source, revenue is driven by ubiquity.  The more potential places to sell adjacent tools, services, and support, the more potential revenue capture.  (Yes, that’s not the only model for open source revenue.) Even in proprietary products with open source underpinnings, the more widespread the underlying package, the more potential gain from that products innovation and support in the community. Standards attempt to capture this common denominator.

Of course there are risks in this approach. Interminable “conversations” can stall progress to stabilization.  Speed of innovation can threaten the success of a defined standard. Intellectual Property concerns, in particular patents, can derail efforts in crossing the barrier between open source contributions and standards development.  Yet those risks are manageable, though the process of managing them often upsets the mindset of open source developers.  Contributor License Agreements and ownership assignments are just two of such concepts.

Adobe believes in the power of open source to allow innovation in standards. Projects like WebKit and Cordova help us demonstrate the appeal of new concepts and technologies in creating new platforms for all of us.

12:26 PM Permalink