Interviewers: Scott Swigart, Sean Campbell, and Richard Bowler
Interviewee: Phil Costa

Phil Costa

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Phil Costa who is the Director of Product Management for Flex and ColdFusion at Adobe, with responsibility for product definition and strategy of the Flex product line. Prior to joining the Flex team, he was product manager at both Macromedia and Allaire and led XML and Internet middleware research at Giga Information Group. Phil has a Master’s degree in English from Boston University and an undergraduate degree from Swarthmore College.

In this interview, Phil talks about Adobe’s decision to open-source the Flex SDK. In specific, Phil talked about:

• Background on the Adobe Flex SDK
• Why open-source the Flex SDK
• Risks in open-sourcing the Flex SDK
• Why the MPL license was chosen
• Advantages in open-sourcing the Flex SDK
• The risks of people forking the build

Scott Swigart: We were commissioned by Microsoft to do an investigation into the differences between how closed source and open source software are built, and how those changes in software development methodologies manifest themselves in the final products.

[Adobe] Flex was particularly fascinating to us, because it started out as a closed source product, and now the Flex SDK is being open sourced. We wanted to get some insight about that. That obviously made sense for Adobe to do, but it isn’t necessarily obvious to us what goes into a decision like that. Why does open-sourcing Flex make sense?

Phil Costa: It might help to give you a little bit of background on Flex. We announced about three weeks ago now that we were going to be open sourcing the Flex SDK. That actually hasn’t happened yet, but it has been a process we’ve been going through for the past two, two-and-a-half years. It has really accelerated in the last year.

The Flex product line started as a server-based product that we sold to a very small number of high-end customers, and we’ve been gradually opening it up, both from a license standpoint, in terms of making it free or parts of it free, and then also opening up from a source code standpoint.

We started publishing all the source code about ten months ago, and we’ve been gradually more and more open about the roadmap we’re taking with the product. Actually making the license open source was a logical next step which we’ve always envisioned taking.

Scott: What are the advantages of going with more of an open source model — what are the advantages of taking something that hasn’t been open source and open sourcing it?

Phil: There are a few different elements to it. 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. So, that’s a very tactical thing, but that is a proven advantage of an open source project.

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, working with early adopters, niche users, and new users, to determine what things we should be adding to the product, to make sure that it fits their needs, both on the learning-curve side as well as the power-user side.

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 an open source project or a set of standards. In the rich-ended application space, there aren’t really any standards, per se. They’re mostly 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.

Scott: What are some of the risks that you saw, if any, in open sourcing Flex? It was an evolutionary process, it’s a track that you’ve been on, but were there risks or concerns that were identified where people thought that this might not be a good idea?

Phil: I think some of them are unique to a product that is going from being a closed source product to an open source product, and some are more cultural.

On one hand, we looked closely at taking all of the current business relationships we have with people around Flex, not only from a revenue standpoint but also from a contract standpoint, and made sure that as we move to a different model around the Flex framework that we could either maintain the revenue streams, grow the revenue streams, or were willing to give them up to get other benefits from moving to an open source model.

Then, on an individual basis, we had to make sure that none of our customers were going to be left in the lurch because of the particular license we chose or the fact that we were going to open source at all. Because Flex is used not only by developers within a company for building an application for their web site, but also in a lot of commercial software products.

For example, SAP uses Flex, as do a lot of smaller ISVs like Dorado and other companies who have their own very specific processes and policies around the use of open source software that they can incorporate into their products. We needed to make sure that there were options available for them that would not cause all kinds of problems. That’s why we chose a dual license model, so that we could address our goals of becoming an open platform while also enabling companies that needed a traditional, closed-source license to also use Flex.

Richard Bowler: I’m guessing that’s why you guys picked the MPL license, because they could combine a proprietary module with the open source modules, and not be forced to open-source their product?

Phil: Exactly. We wanted one that was strong in the sense that it was viral around the core part of the product, but not so strong that no one would use it in a commercial product, because we wanted people to use Flex in commercial products.

We looked a little at LGPL. But our own history as a commercial vendor shows that even though the spirit of LGPL is that it can be combined with other things and it doesn’t affect them, in practice a large percentage of ISVs just won’t touch it.

Whereas things like MPL, ETL, EPL, those licenses were explicitly designed to be more commercial friendly while still carrying the basic spirit of open source.

Richard: I presume that in the past, other commercial products that are using Flex have paid for that privilege, and now anybody that wants to use it in a commercial product is going to be able to. Is that true?

Phil: That’s true. Originally, no one could use it without paying for it. But about ten months ago — last June — we made the core part of the product free, but it was still closed-source. We made the SDK, which was free and it included the source code, and there were specific cases in which you could modify and redistribute the source code, but it was all done under a traditional commercial license.

By making the move to open source, we’re making even more parts of the product free because not only can you use it for free but you can modify and redistribute the SDK for free. Of course, there are still lots of companies that will pay us to obtain support and escalations or for the additional Flex products we sell. If they’re making a big investment in Flex development, they want to make sure someone is on the other end of the phone to help them out if they run into issues.

Richard: It seems that part of the motivation for open sourcing and making it free, was it just to get wider market acceptance?

Phil: That was definitely part of it. There were lots of interesting open source projects that wanted to use Flex that didn’t feel like they could because of their practical or ideological limitations.

The other part was that, as the developer community has gotten bigger and more active, people are looking for ways to contribute back and to participate in Flex. And there wasn’t really a good way to do that, because it wasn’t being run as an open source project.

Richard: It’s an interesting paradigm, because Flex is a developer tool, so your users are the kinds of guys that are extending their own presence on the web by using your product. They are going to have very strong ideas about how your product should grow and what it should become. I imagine you’ve got a lot of feedback from your users already about how they want Flex to grow.

Is this also a way to remove some of the blockades to collaboration so that the user community can be a little more in control of how the product changes over time?

Phil: Absolutely. The way you use Flex is you write ActionScript, which is a JavaScript derivative, and MXML, which is an XML layout language for the UI. The Flex framework itself is entirely written in ActionScript, so people who get deeply involved in Flex are very deeply involved with the tools that actually created Flex. They’re the perfect people to provide feedback and to add things to it to support their needs.

What we’re trying to do is set up a process where they can do that, but it’s still run in a way that preserves the overall philosophy of the product design, and the goals of the product. The compatibility and stability of the framework is maintained over time.

Richard: I imagine that the gatekeeper for this project is ultimately going to be someone other than Adobe.

Phil: The initial plan is that all the committers will be the Flex framework product team. But over time, we plan to add external people who demonstrate skill, judgment, and commitment to the overall mission of the product. It is a big, complicated product, and we’re going to take the evolution of the project one step at a time.

Scott: One of the challenges that open source products face is that somebody decides they want a change in the product, but the people who control the source decide that they’re not going to incorporate that change, so somebody just forks their own build. And now you’ve got two of these out there, three of these out there, and so on. Is that something that’s a concern at all with this project?

Phil: It was one of the explicit concerns we talked about, and it’s still possible, certainly. I don’t expect that you will get a lot of strong forks. You might get weak forks where they take a particular area of the product and create an alternative implementation of a particular component or a particular subsystem.

Scott: It seems like your risk might be lower too, just because this is so tied into Flash and other things that are closed source proprietary Adobe. There’s only so far you can really go with your own fork.

Phil: It’s true that it’s a little bit different for those reasons. In the end, they can’t change the Flash Player API, but Flex does offer a lot of levels above the Flash Player that are design choices that we made.

I think more of what made us comfortable in the end with the question of forking was on the one hand, generally, the practice has been that people do not make major forks lightly. Having a community that can maintain and develop new projects, and taking a lot of resources and trying to split them just means that both projects have fewer resources.

And on the other hand, if you look at it optimistically, if you manage the project well and you have clear reasons why some things are being accepted and some things are not, then things that are not accepted in many cases can be moved over into a sub-project area or a related project area where they have a chance to evolve, even if they’re not becoming a replacement part of the project. In general, people submit to the group project’s will.

Richard: Are you worried about people writing extensions to it and keeping those extensions closed source and trying to pump up the value of code by just adding a neat widget?

Phil: That’s actually one of the things we encourage people to do. To give you an example, today we sell the core part of the framework, which includes the application model, a bunch of core classes, and then a library of components, and that’s the part we give away for free. On top of that, we have a pretty advanced charting and graphing package that we actually sell.

We’ve been working with a bunch of vendors, and there are already some of them out there who have built other component libraries and are selling them. So we encourage people to innovate around the core. The core we’ve made free, but we expect that more specialized visualization tools and so forth would be commercial products.

That was one of the other reasons we chose MPL — because of the nature of the framework, it gets blended in with your application. We wanted to be able to both have open source versions of that that are more community driven, but commercial versions that range all the way from individual components to full blown applications.

Scott: We appreciate you taking the time to chat.

Phil: Thank you.

Bookmark this: