As I hope you’ve seen on Alistair’s blogpost, the team at Adobe Consulting are delighted to have the Cairngorm project promoted to a first-class citizen at opensource.adobe.com. In this blog post, I’d like to provide a bit more detail of our motivations and intentions as we start thinking about Cairngorm 3.0, and invite your thoughts as to how you would like to see us govern the project. Adobe Consulting has never been more committed to the Cairngorm project, and continues to deliver innovative solutions upon Cairngorm to customers the world over — the fact that we’ve been open-source since 2004 means that much of the frenzy and pace happened some years ago, and for those who have joined the Flex community long since that time, Cairngorm may have appeared to be in stasis rather than stability. First and foremost, I hope that what follows alleviates any of these concerns.
Alistair’s announcement covers the detail of us moving to opensource.adobe.com, but in summary, this now means that we have:
- The source code available in a subversion repository, with the ability to submit patches.
- A JIRA bugbase through which you can log bugs and submit community-driven feature requests
- Developer forums through which you can engage with Adobe Consulting and the broader Cairngorm community, whether your questions are around using the framework or contributing and participating in the frameworks future direction
In one of the seminal books on open-source, "The Cathedral and the Bazaar" by Eric S Raymond, he talks about the need for the "Keeper of the Project Vision", someone that ensures that the project remain true to some core ideals. Adobe Consutling will continue to play that governance role, but will do so with more formal counsel and participation of a group of enterprise customers, partners and community leaders who are themselves immersed in delivering projects on a daily basis upon Cairngorm.
If you think you could participate here, I’d be very keen to hear from you, hear what you’re doing with Cairngorm, and share your thoughts on how we best collaborate. Many of you have already reached out in this regard, and we’re exciting about working more closely with the community and partners.
One of the things we’ll look to lock down as we go forward from here, is a simple charter by which we measure suggestions; this has been very implicit and shared understanding amongst the Adobe Consulting team, but we need to document and agree this with the community as we go forward. But in essence, it’s as important to decide what Cairngorm is, as well as what it isn’t, both now and in the future.
By way of example; we only ever intended and will continue to intend that Cairngorm serve application developers working with Flex, and as a natural consequence, AIR. We have no desire to convolute the framework, to introduce abstraction, or to discourage the use of idioms or techniques specific to Flex, in order that we might create applications that could be ported to other presentation-tier technologies. We are in the business of delivering innovative solutions upon Flex and AIR, and Cairngorm supports that as best we possibly can.
We wish for Cairngorm to encourage best-practice leverage of underlying Flex features, and we are keen to ensure that we never add something to Cairngorm that is better suited to the underlying Flex SDK. With both projects open-source, we can make these choices. This extends also to FlexBuilder – we are desparately keen to improve tooling for RIA development, and in several cases we have "started" upon initiatives to better support Cairngorm in this regard. However, we also collaborate deeply with the engineering team, to ensure we are not duplicating future effort. We will continue to do so.
Something else we’ve cared deeply about – and something that has quite frankly imposed restrictions on some of the things we’d like to do – has been backwards compatibility. Whether you appreciate this or not, there is a huge community of customers building projects upon Cairngorm, and we feel duty-bound to support that committment and investment by ensuring that whereever possible, new releases to the framework can be easily embraced without breaking existing code-bases. As we look to support Flex 4, I’m sure we’ll continue to wrestle with some of the challenges this principle can surface — and as we start thinking about Cairngorm 3.0, we’ll look to partcipate with community in wrestling with many of these discussions.
It’s not our intention to make Cairngorm any heavier or more complex than it needs to be, or to introduce feature that is available in other products. We have no desire to be an open-source alternative to commercial products.
Looking forward, I personally want to ensure that there’s extensibility to Cairngorm, in order that 3rd party extensions or additions can be released without forking of the Cairngorm core code-base. As extensions gain in popularity or become "de facto", we can then consider rolling them into the main branch. The team at Universal Mind have released extensions, which unfortunately have to fork the code-base. Eric Feminalla has extensions in the community for developing with AIR, and the Adobe Consulting team wish to make LiveCycle ES easier and more available to developers with Flex/AIR who wish to embrace LiveCycle, but I believe that rather than bloating Cairngorm for those not leveraging LiveCycle, a cairngorm-livecycle.swc that extends Cairngorm for LiveCycle ES projects would be more appropriate. A few years ago at MAX, I showed some very early work of using Cairngorm for FlashLite….the mobile ecosystem grows and grows, and I would imagine that future direction of Cairngorm would continue to ensure that architecture and approach be consistent across screens and devices.
What about other RIA Frameworks ?
So often, I see desire for discussion of "Cairngorm versus…." and to be clear, I don’t think this is overly valuable conversation to engage in. The health of our ecosystem is diversity, and the evolution and proliferation of other frameworks to support similar development, is something we can only encourage. Blog posts that "<framework> is evil", "<framework feature> is bad", "<framework> sucks" certainly catch a great deal of fleeting attention, but I don’t believe that investing our limited time and energy in these debates is the most effective way of advancing the state of our art. In any ecosystem, the cross-pollenation and cross-fertilisation of ideas increases the overall fitness of the ecosystem – so I encourage innovation to occur on all levels, and for discussion and debate to focus inwardly rather than outwardly.
Or in other words, to quote a mantra used often within our own team – "don’t bring me your problems; bring me your ideas for solutions. Through those, I will grasp the underlying problem".
And so what of Cairngorm 3.0 ?
We’re not announcing Cairngorm 3.0 – but we’re very much thinking about it. The Adobe Consulting team is coming together internally for a "Cairngorm summit" (do the etymologists amongst you see what we did there ?) in the next few weeks, where we’ll assemble some of the deepest thinkers around Cairngorm within Adobe and collaborate around the different approaches, ideas and innovations we’ve been seeing in our own projects. As we collate that knowledge, we’ll be opening this up to share with the community, as we start to think about what Cairngorm 3.0 will look like for the innovative solutions we will all be delivering in the future.
Finally – and unrelated to Cairngorm – opensource.adobe.com offers a forum through which Adobe Consulting can spin-out other open-source initiatives around the repeating and recurring approaches we take to making customers successful upon Adobe technology.
I look forward to continuing to collaborate and share with the community, our partners and our customers through opensource.adobe.com, and in the meantime, very much look forward to your thoughts on Cairngorm going forward.