2009 Candidate:
Markus Alexander Kuppe

Eclipse is doing well. We all see and feel our accomplishments every day. Therefore, one has to be careful when making any changes or adjustments to our development process and community. And it is important to that any changes meet with the general acceptance of our community. Still, I see a couple of places where adjustments are needed to ensure tomorrow's success.

Technical aspects

• CVS just works and the foundation staff, through their great work, make sure that the operations continue to work. However, modern distributed version control systems (DVCS) offer features which simplify our development efforts especially in distributed teams like we have at Eclipse. Thus we need to pick up the deferred discussion about DVCS at Eclipse as an alternative to CVS and SVN. IP cleanliness is a concern that is as easily addressed in a DVCS as with a traditional VCS.

• Work on a common build server which was started in 2008. Now it's time to advertise adoption and encourage acceptance througout the project landscape. This isn't just important for Galileo + N, but also for smaller projects that feel the pain in this regard.

• eXtreme programming and SCRUM are well proven tools in modern day development, though we rarely see them used in our development process. Thus we need to find better ways of exploiting these tools in our distributed and inter-company development process.

• Code patches are the fundamental contribution to Eclipse. The way we currently treat a patch is too often simply dumping it at Bugzilla. The "iplog+" flag lowers the workload on the IP team and project leads, but contributors and committers still manually handle patches. Here we need a tool that automatically and continuously verifies patches against mainline, spins off builds and executes tests and sends feedback on the bug report.

• Eclipse development takes place in all timezones. While the foundation usually immediately reacts to requests during their hours of operations, a 24/7 service level agreement is desirable. Thus we need better distributed resources. Though they don't have to be paid for by the foundation. It's another chance for community contributions.

• The combined outcome of implementing the above will enhance our development process. Quality will benefit and it will provide a greater agility allowing us to move from annual release trains (big bang releases) to more flexible release dates.

Commercial aspects

• Membership numbers are continuously climbing. Still, open-source development, in general, and Eclipse adoption fail for some companies. We need precise statistics, draw lessons learned to form and share counter measures to make Eclipse successful for everybody.

• Make non-member committers eligible to vote on foundation elections or make each non-member committer a member automatically just by signing the committer agreement. We don't need an extra hurdle for membership.

Community aspects

• About Community contributions and diversity: Currently, our community mainly lives off its member companies and their paid committers. Some of our projects are even driven by single companies without external contributions. While we acknowledge the advantages commercial backing offers, we need to strive for community diversity. A key concept is rigorously lowering the entrance barriers to Eclipse participation. This starts with a proper "contributor landing page" [1] and ends with tool support mentioned previously (see technical aspects).

  However, calling for increased diversity doesn't buy us a thriving community and ecosystem. We have to continue and intensify our efforts to allow non-code contributions. Design contests and the Babel project are just the beginning. First class documentation, quality assurance (QA), user experience or IT maintenance projects have to be set up. Here we can only learn from other open-source communities that have been running such projects for a long time. One more reason why we need to open up to those projects and their communities.

  But diversity doesn't stop at the paid vs. unpaid committership. Data on the percentage of women in open-source are at a scary low of 2% [2]. We have to act on this disparity and increase female participation in Eclipse. Not just for our own good of increased team productivity, but for the software industry itself that suffers from it.

• The role of young academics: So far the only efforts in regards to advance young talent lies in the SOC project. The project receives its sole funding by participating in the Google Summer of Code. This shouldn't be it. The foundation has to step up to its responsibility of ensuring the continuing liveliness of Eclipse by providing "fresh blood". It needs to help improve on how we bind students after Summer of Code. Having them attend EclipseCon creates a strong bond between students and Eclipse. But this is only possible with reasonable conference rates, affordable accommodation in close proximity to the conference and a traveling EclipseCon. Eventually member companies will benefit from this through better employment opportunities.

[1] e.g. similar to the Fedora project landing page
[2] http://www.infonomics.nl/FLOSS/report/Final4.htm

Markus Alexander Kuppe used to get paid to work on Eclipse/OSGi based products as a Software Engineer for Versant GmbH. It was further his responsibility to develop an open-source strategy for Versant. Now he is back in university to focus on the academic aspects of component based software engineering.

He is an open source enthusiast at heart and has worked on various open source projects already. He first came in contact with Eclipse in 2002 working on the G2Gui project. Ever since, he has been involved with Eclipse in one way or another. He usually can be reached on #eclipse irc.freenode.net (lemmy) or XMPP (markus kuppe org).