The Eclipse Management Organization (EMO) does a lot of reviews. We do a review when a new project is created. We do a review when a project wants to do a release. We do a move, continuation, termination reviews and more. For each of these reviews some form of documentation is required. The documentation (often referred to as “docuware”) describes the event being reviewed and provides pertinent data so that interested parties can learn what they need to know. This gives the community an opportunity to ask questions about the event, and—at least in some cases—challenge it.

When a project wants to do a release review, for example, the release review documentation provides details about the overall fitness of the project, community development efforts, bugs fixed, etc. A very thorough description of what a release review entails is provided in Eclipsepedia. The Eclipse Development Process is annotated with little gems like this for most types of review.

At some point in the now-distant past, it made sense that our review documentation was assembled as a presentation. After all, in the past, we would hold review calls in which the the project that initiated the review would walk through their slides. Over time, this practice changed to one of simply providing the slides for all to review and then being available on a review call to answer any questions and discuss the review. More recently, this has evolved into a practice of making the slides available and inviting the community to ask for a call to discuss the review; today a review call is only held if it specifically requested.

The use of slides for review documentation has been bothering me lately. It’s just not the right format for reviews given the changes that have occurred in the review process. I’ve started encouraging projects to provide review documentation in HTML format. Actually, we’re doing better than that. Anne and I have started to create some review documentation templates that should reduce the amount of effort required to that of determining content.

I am further encouraging new projects to use their proposal document for their creation review. Wim Jongman, with his evolving proposal for the Eclipse Newsreader/Salvo project, as taken another interesting step of building the project proposal in the Eclipsepedia wiki. I still haven’t decided if this will change our workflow. As of right now, the project proposal hasn’t been handed over to the EMO. Does it just stay in wiki? What happens when the page is changed? I guess that changes are tracked and that the document “owner” can undo changes that they are not comfortable with, so this could work. Our “What’s new with Eclipse Projects” page will need some modification to handle wiki-based proposal documents, but this is relatively easy work. This is an interesting proposal, by-the-way, I encourage you to take a look at it.

HTML documents are the first step. I envision this evolving with time as there are some great opportunities for automation. But let’s take the first step. Thoughts?

Hey students! Looking for something fun to do this summer? Do you want to be part of the coolest open source project ever?

If you haven’t been accepted already, you’re a little late for Google Summer of Code. However, there are still lots of great opportunities to do open source work this summer. We list thousands of great project ideas in our bug tracking system. Or, if you find that too daunting, you can narrow down the list (and maybe find a specific Eclipse project that you’re interested in) by posting a note on the soc-dev mailing list asking for advice. You may also be able to attract a mentor.

I am, of course, partial to some of the projects that I’m working on; specifically, the IDE4EDU and Examples project. The Eclipse IDE for Education (IDE4EDU) project is, IMHO, particularly interesting for students as the output, an IDE for students, is directed to them and their peers.

So students… if you want to get some great experience, pad your resume, and get an early start in that all-important reputation building… this is your chance.

A couple days ago, I came across this entry in the DLTK mailing list:

We are using the Python component, but we are a small startup company and don’t have the resources to work on it ourselves. We would be interested in code completion for the Python component and debugging with Jython.

I would be interested to talk to other Python users about sharing the costs to sponsor infrastructure work like the aforementioned items.

I love it. They want some new functionality, but they’re not demanding it, or complaining about it. They’re offering to participate in the construction; they don’t have the skills themselves, but are willing to help fund the work of those who do.

It made me think of a question sent my way at a recent conference. The question was along the lines of “My company depends very much on project X. Development seems to have stopped completely on project X. What is the Eclipse Foundation doing to ensure that project X continues to exist and grow?”

So what is the Foundation doing to ensure that certain “key” projects continue to exist and grow? Well, for one, we talk about them. We talk about them with anybody who will listen. At the recent JAX/Eclipse Forum Europe conference, I presented a new talk, Ten Eclipse Projects You Should Know More about, in which gave an overview of all Eclipse Projects and focused on ~10 projects in particular, including Higgins, ACTF, Nebula, STEM, Linux Tools, and more. We also help projects create and develop community. The Technology PMC, for example, has started to do periodic reviews of community development efforts being undertaken by the projects. Part of the process is to help each project figure out what they can and should be doing to develop the community, and broaden the diversity of the contributors (and, ultimately, committers) on the project. I’m planning to expand this work into other projects. Ultimately, committer diversity is probably the best bet at ensuring the continued existence and growth of a project.

So I turned the question around. I asked the questioner what he was doing to help project X continue to exist and grow? “If a piece of technology is important to you or your organization,” I reasoned, “isn’t in your own selfish best-interest to participate in it? At least a little?”

There’s been a lot of talk recently about “freeloaders” and how it’s not fair to the organizations that invest in open source projects that other individuals and organizations can just breeze in and take advantage of all the hard work of others. To this discussion, I’ll add that so-called “freeloaders” are leaving themselves at a disadvantage. Participation (at least a little) in an open source project is your best bet at protecting your investment in that code you’re betting some part of your business on. It may not be exactly free, but over the long term even some small investment in that open source project could save you a lot of money.

I have been making my way through the results of the Great Galileo Release Review of 2009. It’s a slow-going, fairly mechanical process that eats your brain. The process has given me (if this is possible) even more respect for Anne who usually takes care of this sort of thing. I’ve been trying to work my way through the provided review documentation, ensure that project downloads contain all the stuff they’re supposed to contain (like about.html files, for example), ensure that incubating projects are labeling their downloads according in-line with the guidelines for parallel IP, and so forth. It’s only a few minutes for each project, but it’s mind-numbingly mechanical. Pity me.

It’s good that I have other distractions to break up the monotony…

I’ve added an additional review to our June 24th review date. The RAP project is undertaking the creation of a new “RAP Incubator” with the stated goal of being a place “experiment with alternative ideas and technologies”. A lot of projects have incubators. Pragmatically-speaking, an incubator is a great place to leverage the Parallel IP process while working on new ideas. It’s also a great way to grow new committers while mitigating the risk to the main project. If you have the time, please review the creation documentation and/or the project proposal; post your questions about the review on the RAP project’s newsgroup.

On June 24th, we have several project review scheduled. First, we have a creation review for the Pave project. We have a continuation review for the Ajax Toolkit Framework (ATF) project, a graduation/release review for the Jetty Project, and a release review for the eRCP project.

Currently, in Eclipse, there is a set of atomic operations intended to help users for performing variety of tasks. It is a usual case that several of these operations need to be called in a sequence to achieve a result on a higher level of complexity. It is very often that the same sequences of operations are executed frequently to achieve a family of complex tasks. It would be an effective time-saver if these sequences are automated. Such automation could also provide an error proof path for users to perform these tasks and be sure that at the end they will have results that follow the established conventions. The Pave project, being created under the Web Tools top-level, endeavors to provide this automation. Please review the creation docuware; you can pose questions and other discussion about the Pave project on the eclipse.pave newsgroup.

The AJAX Toolkit Framework (ATF) provides and extensible framework and exemplary tools for building IDEs for the many different AJAX runtime offerings (Dojo, Zimbra, Rico, etc) in the market. Tools built upon these frameworks will initially include: enhanced JavaScript editing features such as edit-time syntax checking; an embedded Mozilla web browser; an embedded DOM browser; and an embedded JavaScript debugger. Please review the review docuware; you can pose questions and other discussion about the ATF project on the eclipse.webtools.atf newsgroup.

Jetty provides an HTTP server, HTTP client, and javax.servlet container. These components are open source and available for commercial use and distribution. Please review the review docuware; you can pose questions and other discussion about the Jetty project on the jetty-dev mailing list.

The intent of this project is to extend the Eclipse Rich Client Platform (RCP) to embedded devices. eRCP is largely a set of components which are subsets of RCP components. It basically enables the same application model used on desktop machines to be used on devices. If you’re interested in this project, please take the time to read the review documentation. If you have questions about the review, please send them to the ercp-dev mailing list. General questions and discussion about eRCP occurs in the eRCP newsgroup.

I have scheduled a supplementary review for two projects that we missed on June 10th. The PHP Development Tools (PDT) and EMFT Mint projects will hold release reviews on June 17th, 2009 at 1500 UTC. When I say “hold release reviews”, I really mean that in the time leading up to the review date, I invite all interested parties to communicate their questions, concerns, and other discussion with the projects through their review channels.

The PDT project provides a PHP Development Tools framework for the Eclipse platform. This project encompasses all development components necessary to develop PHP and facilitate extensibility. It leverages the existing Web Tools Platform (WTP) and Dynamic Languages Toolkit (DLTK) in providing developers with PHP capabilities. Communicate with the PDT project about the version 2.1 release through the eclipse.tools.pdt newsgroup.

Mint is a component in the Eclipse Modeling Framework Technology (EMFT) project whose goal is to improve out-of-the-box Java developer experience when writing EMF-based software. This is accomplished by extending Java development tools (JDT) with EMF-specific enhancements. Communicate with the Mint project about the version 0.8 release through the eclipse.technology.emft newsgroup or emft-dev mailing list.

All upcoming reviews are listed on the What’s New with Eclipse Projects page.

The intent of this project is to extend the Eclipse Rich Client Platform (RCP) to embedded devices. eRCP is largely a set of components which are subsets of RCP components. It basically enables the same application model used on desktop machines to be used on devices.

New features in this release include:

• Currency with Eclipse 3.5
  • OSGi and Core runtime components from Galileo
• eSWT
  • Schema change to allow Close button to be turned on/off
  • ScrolledComposite – allows automatic scrolling
  • Link widget
  • Additional JUnit test cases
  • Bug fixes
• SDK (distributable via P2 or Pulsar)

The review is scheduled for June 24th at 1500h UTC. The call will only occur if explicitly requested by an interested party. If you’re interested in this project, please take the time to read the review documentation. If you have questions about the review, please send them to the ercp-dev mailing list. General questions and discussion about eRCP occurs in the eRCP newsgroup.

Today we held the big review call for projects included in the Galileo release. One of the interesting things that came out in the call is that the number of project reviews appears at odds with the number of projects listed in the Projects section on the Galileo Simultaneous Release wiki page. It all depends on how you count things. If you treat each row in the table, then there are thirty-three (33) projects participating. However, some rows in the table list multiple projects/sub-projects/components. In the end, we did forty-eight (48) reviews today. One project has, thus far, been a no-show. Another project, EclipseLink, released the version they’re including in Galileo some time ago and therefore did not have to participate in the review.

All projects are doing releases leading up to Galileo. Several projects are also graduating. Graduation essentially means that a project is moving from the “incubating” phase into the “mature” phase. Graduation typically occurs along with a “1.0″ release (this is the case for all graduating projects today).

There have been some challenges along the way. Many projects did not provide their IP Logs to emo-ip-team@ until very late in the game. Some projects were not aware that they are required to submit their IP Logs prior to a release. This is something that those of us involved in the process are going to try and do a better job of as we move forward. Everything is documented in the Eclipse Development Process, but I have to admit that I sometimes have problems finding what I need to know. We’ll continue to work on smoothing out this process, and in providing hints where-ever we can.

On the topic of IP Logs, Gabe and I have started working on a new generation Automated IP Log Tool. We’re still very early in the development process, so much of it is still experimental. I’ll tell you more about it in the coming weeks, but the short version is this… it’s a feature that you install into your Eclipse workbench.

Anyway, the release/graduation review call went well today. I have a few bits and pieces to work through to satisfy myself that all the projects involved are ready, but I do anticipate everybody passing. Good work everyone.

My JavaOne encounter has caused me to think a lot lately about developing community around open source projects. Here’s a good rule of thumb if you want to develop a community around you’re open source project: don’t call your potential future users “stupid”. Yes, I am making a mountain out of the proverbial molehill.

The first and most important thing is to realize exactly how great the open source software you’re creating is. If you don’t believe in it, nobody else is going to either. But this does require balance. Confidence in the value of your software and your engineering Kung-fu is good. Arrogance will turn others way. Having said that, history has demonstrated (to me) that some amount of arrogance can be valuable.

Second, you need to assume that the community that your open source project serves knows nothing about you and cares even less. And they’re not going to know anything about you until you tell them. In rare cases, the stars may align and the community will come to you, but these cases are rare. Overnight successes almost never happen overnight. In the early days of Eclipse, the Eclipse team heavily with the community they wanted to develop. They sent their rock stars out into the community to do demonstrations, host code camps, deliver talks, write papers, hold hands, and more. Eclipse was an overnight success because the Eclipse project put a lot of hard work into making it so.

You need to get out into the community you’re trying to attract and engage them in a manner that is appropriate for the community.

So… how do you define the community you’re trying to attract? How do you engage that community? How can you demonstrate the value of your open source software to that community?

I had a bizarre experience at JavaOne yesterday. And I have witnesses. Lots of witnesses. We were approached at the Eclipse booth by a gentleman sporting a “FindBugs” t-shirt. Our conversation went something like this:

The guy: Is there somebody here who works on the Eclipse project?

Me: There are three of us here that work on some different Eclipse projects. What’s up?

The guy: I found a bug. It’s a significant one. In the code, you attempt to compare two things and if they turn out not to be equal, you delete an important directory. The problem is that you attempt to compare a File to a string; these things will never be equal.

Me: That sounds like a bug to me. Did you report it?

The guy: No.

Me: How long ago did you find it?

The guy: Thursday.

Me: You’ve been sitting on a bug for almost a week and haven’t reported it?

The guy: it’s not my job to report your bugs.

Me: So, you just find bugs then. You don’t report them.

The guy: You’re stupid! [he rants incoherently for about 30 seconds and storms off, red-faced]

Me (to Lynn): What just happened?

As far as I (and everybody else in the four-booth vicinity) was concerned, we were having a rather nice, if not jovial, conversation right up until the point when I was branded as stupid in a fit of what I can only describe as Nerd Rage. FWIW, I’m pretty sure that I’m not stupid.

I do, however, think that this gentleman has missed an excellent opportunity to show just how great the project he apparently cares about is at finding bugs. I’m imaging a bug report that provides pointers into very specific parts of the code detailing the problem with sufficient detail that we can’t help but fix it. Moreover, I’m imaging that this bug makes reference to the excellent software that was used to find the bug and the engineer who worked his magic to find it. Of course, this is based on an assumption that, when you work on an open source project, you actually care about the project and want others to know how great it is. What a better way to get people excited by your project than to provide value to a community by using it for its intended purpose?

Alas, apparently finding bugs is enough. If only somebody would create a ReportBugs project at SourceForge…

Unfortunately, the gentleman stormed off in a huff before I could find out more about the bug. If anybody out there can identify the bug and provide sufficient detail to fix it, I’ll find something nice for you. Maybe a nice Eclipse golf shirt. Mmmmm, golf shirt…