June Eclipse Board Meeting Overview

For those who didn't know, there was an Eclipse board meeting last week. Ed has already given his quick synopsis of the meeting, but I figure I would try to give committers a general overview of what happened that's in their interest.

Intellectual Property (IP)

IP was a hot topic at the board meeting for the committer representatives. Ideally, all committers would love to see the IP process be as fast as possible and less confusing. To help with some of the issues around IP and committers, a new "IP Working Group" was established to get input on what can be improved. A couple topics for the working group are:

• How to improve IPZilla to make it easier for committers to use?
• Can the Parallel IP Process be used by all projects, instead of just incubation ones?
• Can we reduce the redundancy of legal files across Eclipse and its projects?

Another really important topic that came across was the issue of dependencies in Eclipse. The board recently published a document that discusses different types of 3rd-party dependencies ('works with' and 'pre-reqs') guidelines and how projects need to comply. In summary, the board is trying to prevent projects to depend on components that have a license that is incompatible with the EPL and provide no other way to get similar functionality. An example that illustrates this well is the EMFT Teneo project. Teneo allows for EMF models to be persisted in databases via its framework. Teneo allows for pluggable persistence providers like Hibernate and JPOX/JDO. If Teneo just provided the Hibernate provider with no way for other providers to be plugged in, that would violate the guidelines.

Proprietary Tools

The board also passed a resolution for how projects should deal with using proprietary tools. Committers should keep this in mind as the use of proprietary tools may unintentionally set a high barrier to entry for new committers on projects.

Committer Diversity

The topic of project diversity was brought up and how projects can attract new committers (if need be). This is a personal issue for me as I'm more concerned how Eclipse can attract more independent committers. In the end, this is something really up to projects themselves. Ideally, all projects should have an infrastructure (ie., good documentation on how to get started) that allows for committers and contributors to participate. Eclipse is doing some good things to bring in new contributors and committers to the fold. I'm really proud of the Eclipse Summer of Code work and I hope more projects continue to participate in this program. Also, there is work in progress to start a "Bug Day" for Eclipse which I plan to announce once it's ready.

Foxes

Oh by the way, Ed spotted a fox again.



Conclusion

On the whole, I can say that the committer representatives were very happy with the direction that the board meetings went. The board was very responsive to committer issues that were brought up, so that means if you have an issue, please post something and we'll do our best to respond. If you don't speak, your voice won't be heard :)