Anatomy of an open-source decision: The Adobe Flex example

I just took the time to read through this interview with Phil Costa, director of Product Management for Flex at Adobe. (Many thanks to Dave McAllister for his link.) You may remember that Adobe announced in April its intention to open-source Flex.

Now, the company is talking about why. It's very interesting to see that the decision to open-source a product is somewhat universal in the considerations that go into it. It brings back memories of early 2003 when we (at Novell) were giddy about releasing the company's UDDI server as open source...

I particularly found Phil's thoughts on the LGPL (i.e., why Adobe opted not to go with LGPL and instead used MPL) fascinating.

At its core, Adobe's decision to open-source flex stemmed from a desire to make the project bigger than the company. That is, independent of the company. Something you could embrace without embracing the company, too. This is precisely the same reasoning that went into Alfresco's decision to GPL our enterprise content management system, so Phil's comments resonate with me.

In response to How Software Is Built's question as to why Adobe decided to open-source Flex, Phil replied:

There are a few different elements to (our decision). First, there's the nature of the product itself. The core part of the product is try hard to internally test, and get all the bugs out, because it's a development framework. By its nature, it gets used in a million different ways. It's very hard to actually set up tests for all those ways and to chase down all the bugs.

So having an open-source model will actually help us by having more people looking at the code and suggest changes based on their particular use-case. In one respect, we view it as a way of magnifying the QA resources we have, and also magnifying some of the bug-fixing resources...

The second element refers more to the evolution of the product. We've always tried to be very customer-centric in terms of designing the product...We decided that having a group of people who can directly influence that--or at least feel more deeply invested in it--was a good way to continue to evolve the product. With a developer product, the people who develop the product are also the users of the product, and there's a very efficient feedback loop.

The third piece is more PR and marketing focused. Because people have to make a substantial investment in Flex--in terms of spending a lot of time developing an application and then making their application dependent on the Flex framework--they're looking for...open-source or de facto standards.

It's become increasingly apparent, as the market has grown up, that to be successful as a platform you need to be an open-source project, so that people view the product as being bigger than one individual company, or in some cases one individual product team. In a lot of ways, that was another requirement that more and more customers were raising; they love Flex but they wanted it to be bigger than just Adobe.

There you have it. If you feel that your company contains all the brainpower necessary to contemplate every possible customer (mis)use of the product, then you're probably fine building it in isolation. But if you think the product should be shaped in the image of those who actually use the product, open source is a great direction to take it.