Spoon Project Mission

Spoon Project is the codename for a project started by the Adobe community to capture the collective experience of those individuals implementing solutions on the Flex framework and to apply that knowledge in a constructive manner through defect patching, feature contribution and addressing aspects of the framework that limit extensibility.

Justification

Adobe has created a successful UI framework for building applications and provided that framework to the community under an open-source license. Intended or not, developers have adopted the technology under the spirit of an open project with the expectation of community involvement and the desire to patch and evolve the framework.

The increasing number of developers has led to an increase in the number of suggestions, encountered issues and available patches. The necessarily limited engineering time Adobe provides to a free and open-source framework caps the number and type of interactions that the community desires below the needed level. As such, there is a rising level of developer frustration which we believe is a direct result of the inability for the community to contribute in positive ways.

Ultimately, there is a significant and untapped resource in the thousands of potential architects, developers and testers within the community who are willing to donate time. We can choose to allow this extra time to manifest in the form of complaints, venting and frustration or we can enable these individuals to take responsibility, become more invested in the product, become champions of the technology, and expend effort in ways that ultimately benefit Adobe, the community and themselves.

Goals

The goals of this project are:

• Create an environment that supports Adobe engineers and the developer community working together to improve the released versions of the open source SDK;
• Increase the efficiency of the Adobe-Community working relationship;
• Decrease the ‘turn-around’ time for submissions and patches;
• Increase the acceptance rate of submission and patches;
• Increase the effective exchange of information, suggestions and issues between the community and Adobe;
• increase the contribution of the community to future versions (un-released) of the SDK;

Benefits

The targeted benefits of Spoon are:

• Provide leadership and management of Open Source Flex SDK community initiatives with the purpose of improving the published code base;
• Increase the quality of the Flex SDK by increasing the number of successful (accepted) patch submissions;
• Increase the input and contribution of the community in expanding the capability of the Flex SDK;
• Foster an open line of communication for the community and official Adobe channels without tying up development cycles;
• Give the community an outlet for important non-core development integrated with the Flex framework;
• Ensure the growing community base’s development works with Adobe’s official tooling;

Expectations

In the spirit of establishing a clear understanding of expectations of both the Community and Adobe, we propose the following set of set of expectations.

Community’s Expectations of this Project

Ideally, over time, this new organization would take responsibility for all interactions with the community stemming from a defect or patch. We would be responsible for reproduction, triage, patching, testing and inclusion into the code base through an extensive network of volunteer developers.

Accessible after the significant amount of review by our teams, Adobe would simply be able to draw the new code, including tests, from our code base for inclusion in their testing and release cycles. Where an issue would have an effect outside of the narrowest fix, we would communicate with Adobe explaining the intended fix and seeking cooperation on forward progress of the issue.

Over time, we hope to demonstrate enough value to Adobe that the process of fixing and maintaining the existing code becomes a matter of top-level communication and integration alone.

Communities Expectations of Adobe’s Role

As a community we see and understand that there are certain elements Adobe will necessarily need to maintain and push. For example, changes to be made to the Flash Player, the signing of official runtime shared libraries, and business opportunities around new verticals will always be Adobe’s realm.

Ideally, we hope that Adobe’s role in Flex becomes one wherein they manage these more exclusive pieces and begin to monetize the Flex framework by extending and developing for enterprise and other markets while continuing to build and evolve tooling.

In the short-term, we will need Adobe to work with our module owners to maintain vision and with our architects to discuss facilitating changes. In the longer-term, we hope that the communication will mainly be about product vision, direction and Adobe explaining planned changes that may impact both projects.

Ultimately, we would consider this project a success if Adobe never dealt with a newly found defect directly.

Strategy

In order to maintain an appropriate level of responsiveness with the community, this project will eventually need to have full-time resources whose primary responsibility it is to interact with and coordinate the volunteer resources. Given this need, and the potentially requirement to enter into contracts with other vendors and organizations, this project will be organized as a Foundation. This approach has clearly been the vetted model used by Mozilla, Eclipse and others.

As the organization will exist as a not-for-profit corporation dedicated to the community, funding will need to initially be solicited through donation from companies vested in the success of this project and Flex in general.

Initial inquiries have revealed a number of companies tentatively interested in this investment as an offset for the costs of their own framework maintenance efforts.

Initial Steps

Establishing an effective and successful project of this scale requires thoughtful planning and management to put in place the proper foundation in preparation for the execution of a pragmatic and flexible plan. The overall strategy involves these stages:

1. Put in place a mutually agreed charter that clearly identifies objectives, outcomes, organization, roles and responsibilities;
2. Establish the community, organizational and technical foundational elements that will enable success (Organizational Milestone);
3. Establish a baseline of ‘testable’ codebase and generated set of test cases (Technical Milestone);
4. Test the foundation with a ‘First Patch’ to validate and improve (Process Milestone); and
5. Expand the program in a controlled manner, while addressing organizational, process and technology improvements in a responsive manner.

Common Operating Principles

To ensure the successful implementation of this strategy, we propose the following operating principles, common to both Adobe and the community, that guide behaviors and interactions:

• Continuous Communications. The intent of this organization is to be in communication with Adobe at all times and to ensure that any and all architectural changes be made in cooperation with Adobe. The emphasis will be communication at a rate determined by Adobe, however, we do not believe that the community will benefit from breaking Flex nor Flex’s tooling.
• Released Codebase. To aid communication and reduce the potential for conflict, the organization will work only on released Adobe code. By way of example, Flex 4.5 is presently a released version and Flex 5.x is under development. This organization would only concern itself with the Flex 4.5 code base until the final release of Flex 5.
• Common Base but Acceptable Differences. While our goal will be the inclusion of the changes we make into Adobe’s production branch, we understand that not all commits to our project will initially, or perhaps even eventually, be accepted. In much the way that Fedora and RedHat operate, we believe this is not only acceptable but useful to the community.
• Evolve with Community Adoption. The project will strive to evolve in-sync with the community and adoption of the open source SDK. By example, we do not envision that initial release versions of this SDK will be accompanied by Adobe signed RSLs. Rather, our goal is to demonstrate significant value over the course of month and years and approach RSL signing issues if and when the Spoon version of the SDK has significant and lasting community adoption.

Foundational Elements

To facilitate this project we will need to simultaneously address the follow foundational elements to enable success: Education, Testing, Infrastructure and Community Management.

Education

To increase the chances of successful submissions we need the interested members of the community to understand the Flex framework at a very deep level. To that end, we will need to organize and facilitate educational events on topics ranging from framework architectural concepts to writing proper test cases. These events will likely be the evolution of the earlier Bug Quash attempts and will exist ideally as both locally organized in-person events by trusted members of the community and online sessions which can be recorded to create a library of viable content. The initial areas of focus should include:

1. Framework Architecture
2. Component Architecture
3. Patch Submission Process
4. Creation of Test Cases
5. General Mentoring on Object Design and Implementation

Enable SDK Testability

The current patch submission process is problematic for several reasons, however, one fundamental reason is testability of the SDK.

Current State

Presently the test suite available to Adobe Engineering is not available to the community at large meaning that potential contributors have no objective way to ensure that patches do not break unintended code. Further, the tests take many hours to run, making frequent execution of the tests during the coding process impractical. Finally, the tests are at a higher level than normal developer tests, meaning that they involve multiple units of code per each test execution, limiting their ability to quickly narrow down the cause of an issue to a single unit of code.

Challenges

While we believe this is of the highest priority, it will not be an easy task. The current framework architecture precludes unit testing of any type of UIComponent, the basis for most visual elements. Therefore as a prelude to this item, we must engage with Adobe to discuss and identify the narrowest number of architectural changes that would allow for this much needed testing. The intent of any of these changes is only to facilitate testing and would not affect workflow, tooling or a user’s experience using Flex. These are purely ‘behind the scenes’ style changes.

We would need to rely upon Adobe to run any proposed changes through the existing test suites to ensure compatibility with existing releases. Once these changes pass all existing tests, then we can move toward the creation of unit tests.

Complementary Test Automation

It is recognized that the nature of Adobe’s testing of the SDK is Product Quality oriented and proprietary. The approach proposed is that Open Source Flex SDK testing will be developer/unit test oriented and complementary to the Adobe testing. The objective would be to achieve a high-degree of confidence in submissions before they reach Adobe. It will be mandatory that submissions include automated tests following the directed standard or they will be rejected.

Once we have architecture in place to facilitate testing, the next step would be to create a full regression suite of unit tests. This task alone could take a significant multi-year effort. To speed up the initial approach, we propose auto-generating tests to codify existing behavior. These unit tests could then be executed by patch submitters against their own code routinely serving as a first line of defense against submitting a patch with unintended consequences. Combined with the routine execution of the existing QA style tests, we could have the beginning of a comprehensive testing suite.

Auto-generated unit tests will not be intuitive nor accomplish our ultimate goals, however, they will allow us to completely test a patch submission and instantly notice any unintended consequences. As areas of the framework code are touched going forward, we should attempt to slowly supplant the automated tests with human-written developer tests.

The benefit of this approach is that it would establish an ‘up-front’ known method of testing the framework, allowing us to require each patch be accompanied by a test. This alone would continually increase the efficacy of the testing effort as our tests continue to grow and provide a rich set of additional documentation of the intended inner workings of the framework.

Infrastructure

The most prominent tools in the open source community differ from the most prominent tools in adobe’s infrastructure. To that end, we propose creating any infrastructure needed based upon the standard tools of the open source world that will interoperate with Adobe’s submission process. We feel it is extremely important to keep these tools separate from the Adobe controlled stack for a variety of reasons.

First, the Adobe controlled stack will always need to first consider the security and management needs of Adobe. To that end, the infrastructure of this project must serve a contradictory purpose with security and management serving the community.

Effective community control and development of the Open Source Flex SDK involves establishing appropriate and separate responsibilities and tasks for managing the community process. Should we build on an infrastructure that Adobe must maintain, we will defeat our own purpose by costing Adobe time for all management tasks.

Finally, as new tools evolve in the open-source community we will be more able to adapt and integrate these tools with complete control over infrastructure aspects such as:

1. Source Control
2. Issue Tracking and Coordination
3. Information Dissemination
4. Automated Build

We will intentionally defer the selection of these technologies until the appropriate time when owners of individual areas can contribute. The technology is not the most important choice to be had at this time.

Organization and Management

Governance – Mozilla Model

Following the Mozilla model, the objective will be to establish a foundation that will initially be structured as a virtual organization where both authority and responsibility are given as both volunteer and, eventually, employed members show their abilities through contribution.

Board of Directors

The foundation will be governed by an elected board of Directors who will set overall foundation direction and policy.

Officers

The foundation will have a set of officers who are responsible for managing the day to day affairs of the organization and enacting the vision of the board.

Roles and Responsibilities

The remainder of the organization is governed as a meritocracy with individuals filling the following roles based on merit and continuing contribution to the foundation. For an understanding how each of these roles interaction within the submission process, please see the Contribution Management section later in this document.

Contributor	A contributor is an individual that volunteers time to produce a viable patch for any given issue. This patch will be submitted along with an accompanying unit test. The contributor will work with other members of the team through the patch submission process to ensure the patch is viable from several key perspectives including architecture, functionality and adherence to the vision of the framework.
Peer Reviewer	A peer reviewer is an individual who has submitted one or more viable patches, is familiar with the process and framework and volunteers time to review code submissions of others. Any newly submitted patch must first be peer reviewed and found acceptable before continuing in the chain.
Module Owner	A module owner is responsible for resolving conflicts among members and approving peer reviewed patches for inclusion into the code base. In our case, module owners will work with Adobe to propose changes and to communicate resolved issues that Adobe may want to consider for inclusion in their branch.See codebase management later in this document for more information on modules.
Super Reviewer	A super reviewer is an individual who has successfully functioned in the role of Peer Reviewer and has gained the trust of the organization. A super reviewer will work closely with module owners, review all approved code for its effect on systems outside of the module and for conformance to standards before approving its inclusion in the project.
Benevolent Dictator	The benevolent dictator’s sole responsibility is the resolution of technical disputes. For example, should a patch affect two or more module owners and an appropriate implementation strategy cannot be agreed upon, the benevolent dictator would resolve said dispute and set the direction forward. Further, should a contributor submit a patch that they feel strongly should be included but is continually rejected by a module owner as not working within the vision of the framework, the contributor can appeal to the dictator for a second opinion. In this way we ensure that a single individuals vision of an area of the framework does not, in itself, govern the entire direction.

Codebase Management

Managing codebases as large as the Flex SDK will require a model of distributed/delegated management. The approach that will be taken is aligned with the organization of the codebase’s major modules.

In the initial phases of the project one individual may act as the module owner for several patchable modules. Module Owners are responsible for maintaining the long term vision of a module. A module owner is responsible for resolving conflicts among members and approving peer reviewed patches for inclusion into the code base. In our case, module owners will work with Adobe to align the vision of a given module, to propose changes and to communicate resolved issues that Adobe may want to consider for inclusion in their branch.

Eventually, the goal is to have one module owner for each area on this list:

• Compiler
• Data Visualization Components
• Networking
• Core Comp Architecture
• Accessibility
• I18N
• Formatters
• ASDoc
• Collections
• Data Binding
• Deep Linking / History Manager
• Effects
• Validators
• Flex Modules
• Containers / Layouts
• Data Entry Components
• Styles
• Themes
• States / Transitions
• List Comps
• Video Comps

Contribution Management

Contribution management involves various processes around the development, submission, review, testing and final submission to Adobe. Contributions will vary but can include:

• Patches/Fixes
• Improvements
• New code and modules

Contribution Process

The management of contributions will involve a three-phase patch review process:

• Contribution Review. After contribution is received it will be reviewed by a Peer Reviewer. If the contribution is not acceptable in the current form, the Peer Reviewer will open a dialog with the Contributor to guide the process and obtain a viable contribution. This provides an education opportunity to ensure that adherence to the patch submission process increases over time.
• Module Owner Review. If a contribution is deemed acceptable by the Peer Reviewer, the patch will be reviewed by the appropriate Module Owner to ensure it is in line with the vision for the module and will not cause repercussions that are only understood with a top-level view. Should the Module Owner consider the patch viable, he or she will request review by a Super Reviewer.
• Final Review. The Super Reviewer will do an in-depth review of the code, paying particular attention to side effects and quality of test cases. The reviewers may reject the patch for any technical reason, however, should it be approved, the patch will then be accepted into the Spoon baseline.
• Spoon Codebase Change Request. Reviewed and approved contributions will be submitted to the codebase manager for inclusion in the public codebase and communications of release notes.

Adobe Submission Management

Once an item is part of the Spoon SDK it can be provided to Adobe. A board, or possibly even an individual or group within Adobe will need to oversee the integration of this code within Adobe’s source code repositories for QA testing, acceptance/rejection, and where applicable incorporation in the released codebase.

In lieu of a decision from Adobe on this process, we will refer to this entity as the Submission Control Board.

Timeline

At the conclusion of the first meeting, the team has proposed the following first milestones for the project.

End of Q1 2011 – Implement proposed architectural changes to facilitate developer testing. – COMPLETE
The goal is to have a functionally equivalent version of the Flex SDK, which Adobe can verify passes all existing Mustella tests. The only changes made to this version will be to facilitate unit testing.

April, 2011 – Be prepared to discuss the project openly with Adobe’s support – COMPLETE
At this point, we want to introduce the concept and the project to individuals in the community. It is our goal to begin building the army needed for this task through educational events while quantifying and qualifying the small fixes and changes potential contributors already have in local branches. We will not begin accepting any patches until after the end of Q2.

End of Q2 2011 – Full set of generated unit tests
The goal is to have a completely generated set of tests which codify existing behavior of the framework. Using these tests, we will then immediately be able to see the impact of every patch and every submission across the system.