Skip to main content

2009 Candidate:
Boris Bokowski

Senior Software Developer, IBM

Nominee for Committer Member representative

Platform UI technical lead, member of the Eclipse Architecture Council, e4 committer.

email:  Boris_Bokowski at ca.ibm.com

Vision

If elected as a committer representative on the Eclipse Board of Directors, I would like to help ensure the health and long-term success of Eclipse.

In particular, the following topics would be on my agenda:

Make the life of committers easier.
We committers are doing much more than just writing code. Many of us enjoy the writing code part more than doing all the other necessary activities, for example, triaging b ugs, managing lists of tasks in Bugzilla, filing contribution questionnaires and working through the IP process, ensuring proper internationalization, maintaining the IP log. Some of these have become easier recently, thanks to the previous committer representatives, and the Eclipse Foundation staff.
I believe that there are many more opportunities for streamlining and simplification. At the board level, I would push for improvements, and for spending foundation money on this if necessary. Things that come to mind are usability improvements for Bugzilla, better performance for CVS/Subversion, Bugzilla and the wiki.
In addition to this, I would argue that money would be well spent on work that benefits all projects but never gets done because there is not enough benefit for each individual project on its own: Compiling and maintaining a "new project jumpstart documentation" package, for example. Or coming up with a set of exemplary project pages as something the projects could copy and adapt.

Increase and improve communication within the community.
I believe we could do much more as a community by improving how we communicate. Those of us who hang out on IRC know how much they benefit from being able to ask a question and quickly get an answer, but also how useful it is to know people working on other projects. In addition to trying to get more people on IRC :-), I have other ideas how we could improve communication and cross-project interaction.
For example, I like the demo camps because you get to know others in the community. How about sponsoring committer and contributor camps once a year, focusing on how we get the work done, instead of on the products and projects that are the result of that work?
Another way to foster communication would be to make dependency relationships transparent. The Foundation already provides data on CVS commits. It should be relatively easy to extend this to show, at the granularity of individual plug-ins, a list of committers who are currently maintaining each plug-in, and the Eclipse-wide dependency relationships between those plug-ins. From a perspective of the Platform, we would know who to contact about planned changes to, say, the Common Navigator, and in the other direction, it would be easy to find out who maintains, say, the draw2d component.
I would also like to see more contacts between Eclipse and other open source communities such as Apache, Mozilla, Linux, and so on. A lot of the issues that we have around how to attract contributors, how to get companies to invest in open source, how to handle issues of APIs and deprecation, and so on, must be issues in these other communities as well, and we should be able to learn from each other.

Prepare ourselves for change.
It is mind-boggling to see the rate of change in several areas that affect Eclipse directly. I don't know what the best answers are, but I know that we have a number of open questions and am interested in discussing them at the board level, for example:

  • The world-wide economic problems are affecting all Eclipse members, including the committer members through their employers and customers. This is both a threat, in that it is going to be harder for companies to fund development in the Eclipse context, and an opportunity, in that adoption of and collaboration through open source solutions could increase.
  • The technology context is becoming more and more fragmented. For example, Java is no longer the "cool language" of choice for developers, and web UIs start to become more important than desktop UIs. At Eclipse, we mainly develop using Java, and provide mostly desktop UIs. All stakeholders will have to help change this (in the long term) to avoid ending up in a technological dead end.
  • The number of Eclipse member companies, Eclipse projects, and Eclipse committers has increased dramatically. I suspect that our current structure (e.g. development process, PMCs, councils) will have to change to enable more scaling but I don't see this discussed.

About the Candidate

Boris is the technical lead of the Eclipse Platform UI component and works for IBM in Ottawa, Canada. He is a member of the Eclipse Architecture Council, and an active committer on the e4 project. He is proud to have helped increase diversity at the Eclipse Platform (a little) by attracting several non-IBM contributors and helping them become committers. Before joining IBM in 2005, he wrote a commercial RCP app using EMF and GEF, co-founded and co-managed a Web 2.0 company in Germany, worked on the original Eclipse 1.0 at OTI in Ottawa, and earned a PhD in computer science at Freie Universitat Berlin, Germany. He is married and a geek dad of three kids. You can find him on IRC as "borisb6i".

Affiliation

IBM Software, Ottawa, Canada

Back to the top