Adobe learns lessons of open-source Flex

No pain, no gain

Adobe Systems is learning the challenges and complexities of taking its software open source.

Just a year and a half after Adobe released its Flex Software Development Kit (SDK) under the Mozilla Public License (MPL) to encourage developer buy in, it's the company - not the community - that continues to shoulder the burden of building and fixing Flex.

The majority of Flex committers are Adobe employees with most contributions from outsiders tackling bugs rather than going into new feature ideas.

Adobe, meanwhile, is treading a fine line between tipping off competitors to its Flex plans through the open-source work while coaxing the community to buy into the Flex roadmap.

When it announced it was open sourcing Flex in April 2007, Adobe called the move a way of collaborating with the developer community to "further fuel its momentum and innovation." Flex is one of many Adobe's code to go open-source, following - among others - Tamarin and BlazeDS. The main prize, Flash Player, remains closed.

Yet, speaking at the company's recent MAX conference and to The Reg, representatives gave an honest assessment of the hard work that's gone into opening Flex, and the challenges that remain.

Matt Chotin, Flex senior product manager, said one hurdle is getting people in the community to back up ideas and suggestions for Flex with actual code submissions.

"There are plenty who say casually they want something but don't want to get an account," Chotin said. An account in the Flex community would be provided by Adobe and give individuals code assess rights and privileges.

So far, all the Flex committers are Adobe employees although Chotin said he hoped this would change soon. To become a committer, people must follow up ideas with code and must earn their way in by working on the project with multiple submissions over time. That's a standard course for many open-source projects.

"We have a very active Flex community...but getting people to the point where they aren't just sending an idea without anything backing it up is difficult - any idea is OK as long as there's code with it," Chotin said.

"We are still trying to figure how to get the community and companies to say: 'This is an important change to make and I want to make this contribution,'" Chotin added.

Meanwhile, there's also a lack of vendor ecosystem around Flex. Admittedly, it's relatively early days for open-source Flex. But Chotin seemed to think that a vendor-based community would be better at submitting feature ideas and specifications on a formal basis. Once other companies have a stake in the roadmap, then they'd be more willing to stump up resources such as staff and code to see the changes through to completion.

This has happened in other communities. In the IBM-initiated and backed Eclipse, for example, vendors in specific markets and product areas have lead projects they feel close to or suit their strategy.

"I expect to see more contributions happening that way," Chotin said. "We need to build that up...as the ecosystems grows we'll have more formal contributions around it."

But Chotin appeared to admit that Adobe has its hands full dealing with the contributions that it is currently receiving. These are mostly fixes. He called it "time consuming" to accept all the patches Adobe is getting.

Underlying the need for broad support is the complex challenge of getting the community to buy in to the Flex road map Adobe would prefer to see and that Adobe can build on, without turning people off by being seen as heavy handed. Adobe, meanwhile, must also tread a thin line between giving enough information and tipping off rivals over its plans for Flex.

"We try to talk about the concepts we think are important and put them in the context of Flex on its own without bringing up some of the other things we are doing at Adobe to take advantage of that," Chotin said. "It's a challenge for us to talk about ideas we want to put into the Flex framework without exposing the commercial ideas we are thinking off."

The competition is real: JetBrains' IntelliJ IDEA, for example, now has its own Flex tool. The IntelliJ integrated development environment has proved a consistently popular suite of tools for many developers.

Chotin conceded one thing Adobe could have done better before taking Flex open source was to research how other open-source projects work. This could have informed how the Flex project had been set up and helped improve the way things are being done.

Also, while Chotin said Adobe's "pretty happy" with the choice of MPL there could have been more research on the subject of licenses. "It's not just hell to understand the license, it's hell to pick a license too," he said noting "everyone's a critic" when it comes to which open-source license is best.

So was it worth going open source? The majority of the costs Adobe has - and continues to incur - from taking Flex open source come in time - the number of people hours involved in working through submitted fixes, for example. Chotin claimed he could not put an actual dollar amount on the work.

He remained confident, though, that open-source was the right course of action as it would help seed uptake of other Adobe technologies, such as Cocomo for adding social networking capabilities to rich internet applications (RIAs) that use Flex, in addition to Flex itself.

"The more Flex is adopted, the more Adobe should benefit," he said. "If Flex grows more because of our open-source efforts we have a bigger pool of developers using Cocomo. But it doesn't necessarily translate into instant dollars." ®