The Eclipse Board of Directors just completed our Q4 face-to-face in San Francisco. This was a 2-day meeting jammed with topics. I've focused this tome mostly on the committer-related issues. Watch for the official board minutes, and my apologies for the length. Board topics:
- Project Plans and the Roadmap
- Industry Working Groups and the Eclipse Mobile Working Group
- Miscellaneous procedural items, including updates on ESE 08 and EclipseCon 09
- The Galileo release and the newly-revived Architecture Council
- Budget and executive compensation review
- EPIC proposal for improvements
- Annual Strategic Developer reports
- Discussion on Strategic Developer contributions to the common good
The Board approved the following amendment to the Eclipse Development Process:
For any Project to pass a Continuation Review, Graduation Review or Release Review it must have a current project plan, in the format specified by the EMO, available to the community.
We feel very strongly that the XML project plan format and linkage to Bugzilla plan items have been a positive step in improving plans across the project landscape, and this resolution further emphasizes the importance of transparent planning. I'd also like to note that of all of the Galileo requirements, the XML project plan is the only one specifically mandated by the Board. The other requirements are either part of the Development Process or were added collectively by the Planning Council. These plans roll-up into the Roadmap, which was also approved at this meeting.
We also discussed Industry Working Groups, a new Foundation initiative designed to increase membership, industry awareness and usage of Eclipse, and engineering staffing on Eclipse projects. With my DSDP hat on, I'm excited that the first one created is the Eclipse Mobile Working Group.
Mik and I led a lively discussion on the age-old Adopter Community vs. User Community question, in this case whether Galileo is supposed to be a coordinated build or a coordinated product. After much discussion, the Board reiterated the position that Galileo is a community-supported release of technology, which is subsequently productized by commercial adopters. Free users of Galileo get support from the community, but for enterprise-level support users need to buy a commercial product based on the Galileo technologies. In order to make this clearer on the eclipse.org site, the Galileo site will have 1) a statement that the EPP packages are community-supported, 2) a link to commercial distros, and 3) an obvious way to file bugs against an EPP package in Bugzilla.
This discussion was followed up by a status update on the Architecture Council. Attention eclipse community: the AC has been revived and is very now active. If you haven't paid attention in a while, now is the time to re-engage. As part of the AC report, we also discussed some committer and project needs from the Foundation: Engineering Staffing, LGPL, Git, and JIRA. I discuss each below.
Regarding staffing, we discussed some of the nice-to-have items from Galileo: BIDI, accessibility, usability, and cross-project QA. The conclusion was a reminder of the roles of the Foundation and the Membership when it comes to project staffing. As indicated in the bylaws, the Foundation facilitates the ecosystem while maintaining vendor neutrality. So when applying engineering staffing, the Foundation supports infrastructure rather than writing code for specific projects. This means that if there are specific project features that the community feels are important, staffing needs to come from the community and the commercial ecosystem, not from the Foundation.
LGPL was raised as an issue because some projects need to link to LGPL code to realize their full feature set. LGPL (and GPL) code is currently not allowed on the Foundation's servers, so multiple downloads are required for some projects. The Board's IP Advisory Committee is currently examining the LGPL policy.
Git and JIRA are two tools that have been recently
discussed by the committers and project leads. Git is a Distributed Version Control System, intended to be a replacement for tools like CVS and SVN. JIRA is an issue tracking system similar to Bugzilla. The Foundation doesn't currently have the staff to deploy another VCS, so the Git discussion has been tabled for now. The Board does want to stay current and relevant technically in order to continue to attract projects and technologies, and we will likely need to revisit Git in the future. Regarding JIRA, the Board felt that adopting a second issue tracking system is out of scope at this time. The IP due diligence process and automated tooling are very closely tied both legally and technically to Bugzilla, and we felt that adopting a second system would be disproportionately costly relative to the benefits.
We spent some time reviewing and approving next year's budget. It's appropriately conservative and includes built-in contingencies for the challenging economy. Some next steps for Eclipse Plug-in Central (EPIC) were also approved (stay tuned). We reviewed the annual Strategic Developer reports, and you can see the per-company project and committer statistics for yourself.
Finally, we had a long discussion pertaining to how the Strategic members can further advance the platform (in the general sense) by putting some staffing on "common good" items. This was somewhat of a continuation of the staffing discussion above. I'd like to say that we reach some definitive conclusions, but we still have more work to do. Again, stay tuned. As part of this discussion, we talked about investment in the Eclipse Platform, both 3.x and E4. Not surprisingly, there was a mix of commercial needs represented in the room, some of whom have a long-term need for continued 3.x maintenance and enhancement and some of whom need the E4 platform.
Happy Holidays from your friendly neighborhood committer reps!
