Eclipse DemoCamps

We would like to remind and encourage you to participate in one of the Eclipse DemoCamps during November and December. We have over 20 DemoCamps organized in different cities around the world.

What is an Eclipse DemoCamp?
Stealing from the wiki:

Eclipse DemoCamp is an opportunity to showcase all of the cool interesting technology being built by the Eclipse community. It is also an opportunity for you to meet Eclipse enthusiasts in your city.

The format of the DemoCamp is pretty informal. The idea is for a group of Eclipse enthusiasts to meet up and demo what they are doing with Eclipse. The demos can be of research projects, Eclipse open source projects, applications based on Eclipse, commercial products using Eclipse, whatever you think might be of interest to the attendees. The only stipulation is that it is Eclipse related.

Please take this opportunity to get involved and sign-up for a demo at a DemoCamp located near you today.

See you there!

Eclipse Members Meeting 2007

We finished up the Eclipse Members meeting for another year. The meeting was held in Chicago this year. With our commitments of the Eclipse board meeting on Wednesday, we attended the members meeting on Thursday.

We started the day with Mike Milinkovich (Executive Director) reviewing the Eclipse Foundation staff (17 people) and introducing the two new employees:
Gabe O'Brien - Darn good programmer working in Portland
Barbara Cochrane - IP Management working in Ottawa.


We all had a look at the download statistics.
The new Eclipse packages have significantly increased number of downloads with the expected spike for the Europa coordinated release.

China has continued to be the country with the highest percents of downloads at 21% followed by United States and Germany.

We reviewed the Strategy Update. The new items going forward:

• foster OSGi based tun time platform for applications.
  
• increase divesity and transparency in the projects. Focus on creating a community of innovation.
  
• encourage improved usability and out of box experience in the projects.
  
• make IP leadership a competitive advantage for the Eclipse community.
  
• implement programs for university outreach.
  

We walked through the IPZilla improvements and these are detailed in another post.

Old news to us on the board but the Q3 update for the board of directors included the approval of new trademark guidelines by the board and the creation of the IP working group.

There are lots of conferences on the horizon including:
Expect 400 attendees

Expect 400 attendees with possibility of numerous remote attendees via online linkup.

EclipseCon 2008. March 17-21, 2008 San Jose, CA
Call for papers opens October 16; Deadline is November 19. Expect 1500 attendees.

Looking ahead the Foundation is busy planning for EclipseCon, working on the improvements for IP process, planning for Ganymede.

Some areas specifically called out for opportunities to get involved were the Babel translation project and the Eclipse UI working group.

Bjorn Freeman-Benson (Director, Open Source Process) presented on the current reality of the Eclipse Development Process and the tweaks that are required to keep the reality matching the written process. The EDP needs to codify what we the community think is important and what we are willing to enforce for the good of the community.
Successes include the Architecture council mentoring of new Eclipse projects, the project release reviews and the open and transparent committer elections.

Bjorn reiterated that the goal of the EDP is reality not fiction.

One suggested tweak is to move the EDP to encourage diversity goals and that projects should strive to have diversity instead of the current wording where projects must have goals and are required to have diversity.

We received project updates from Bjorn on the most recent and interesting state changes of some of the over 80 projects within Eclipse. Bjorn also indicated the plan to have project dashboards - to provide even more useful information for community.

The new Eclipse members were introduced. Check them out:
Webtide - scalable AJAX and comet; core developers of jetty

Replay Solutions: tools that plug into Eclipse - capture and replay bugs

Ian Skerrett (Director, Marketing) presented the marketing update Q3/2007. We had 59 blogposts from the Europa review contest...and all of the reviewers got shirts. Planning on more and similar "promotions" in the future.

At both the board meeting and the Members meeting we had several "outside" presentations. All were thought provoking.

Matt Lawton, IDC presented on "Generating Revenue with Open Source Software".
Companies must now compete on their business model and there is lots up for grabs.
Last year there was 1.8 billion from standalone OSS revenue and this projected to 5.8 by 2011 with a growth rate higher than that of traditional software revenue growth.

Tony Bailetti from Carleton University was all about "Making money from OS".
Companies need to be clear on how they will make money from OS
Make money from OS template
- increase buyers willingness to pay for companies offers
- increase size of market
- decrease buyer willingness to pay for competitors
- decrease suppliers coast of working with you

We then did an impromptu case study of Innoopract via Jochen Krause reviewing a simplistic model of Innoopract's business and how it mapped to the template.

We ended our work at this gathering with a committer breakout session. We had a great question and answer period with Bjorn as the Eclipse Development Process expert, Janet Campbell (Legal Counsel & Manager, Intellectual Property) as the IP expert and all the committer representatives providing some wisdom from the trenches. Great practical application and exchanges to round out the day.

More meeting information can be found here.

We can look forward to seeing the members / committers at the meeting next year. Hope you can join us!

IP Process Update: IPZilla Improvements

The Eclipse foundation staff, the Eclipse board and your humble committer representatives have been hard at work improving the tools and interactions that implement parts of the Eclipse intellectual property (IP) process.

An IP Process working group has been tasked by the board to suggest and follow the changes being made by the Eclipse foundation staff.

The current set of improvements being worked on:

• a portal based contribution questionnaire that will drive a simplified workflow for committers to submit an IP contribution questionnaire (CQ) into IPZilla.


• quick action buttons to do the work for you for common workflows.


• Automatic code scanning with a keyword scan tool...looking for those pesky swear words, derogatory comments and "problem" indicator words.


• IPZilla now has project incubation status indicated in the request as well as some helpful canned work queue queries. The little egg is everywhere!

Other improvements that are planned in the shorter term include more workflow improvements, better emails (unique style and better wording) as well as reminder emails when progress has been halted on a specific CQ awaiting input.

Long term we can hope to see an implementation of an attachment / JAR scanner to really help the committer understand what kind of crazy nested hierarchy is in that JAR file.
Also planned is the automatic notification of projects that have requested usage of a JAR when a new version of the JAR has been approved for general usage. We can also hope to see the real requester of the CQ displayed in IPZilla.

What's in a noteworthy keyword?

I remember in the past, as an Eclipse user, looking at the New and Noteworthy document for each milestone with glee. It was something to anticipate when each Eclipse milestone was released... you thought to yourself, what cool stuff will be in this milestone?

Now, as an Eclipse committer, I'm on the side of generating some of these New and Noteworthy items. I have created a bug requesting that a new keyword be added to bugzilla called noteworthy. The purpose of this keyword is three-fold:

• Make it easier for committers to tag what items they think are noteworthy. A common workflow for committers towards the end of a release is to scan the bugs fixed and pick and choose noteworthy items. I think we can improve this.
• In the best interest of transparency, our users (and even our committers) would like to see where noteworthy items come from and to be easy to query what's new would be great.
• For people like the EMF team who like to automatically generate release notes with each release, this can be a way to mark specific bugs as noteworthy ones.

So, if you're a committer or even a user who think this would be useful, please comment on the bug. If you're a committer on a project that doesn't publish these new and noteworthy type of documents, I highly recommend it as it's something your consumers may enjoy to read.

IPZilla Summer Vacation 2007

No...the plan is not to have IPZilla go away for the summer :-)

Rather the Eclipse foundation is planning work to improve the user experience of both the Eclipse committers and the Eclipse legal staff when working with IPZilla.
This work will require no changes to the Eclipse IP Policy.

Please check out the goals and the plan: link.

As committer representatives we are excited about these proposed changes. I know that it would have made my life easier with my previous experiences outlined here: link.

Dare we wish for summer to end? :-)

Trademark and Logo Usage Guidelines

Howdy Eclipse committers! The committer representatives want to make sure that you are aware of the updated Trademark and Logo Usage Guidelines. As Mike mentioned, the big difference is that project names, acronyms and logos are recognized as Eclipse trademarks. If people recall the Mylar -> Mylyn transition, this was the primary reason for the rename.

To put it simply, the Eclipse Foundation takes a lot of pride in the cleanliness of the intellectual property within Eclipse. Trademarks are considered intellectual property, therefore as committers, we must ensure our project names and logos are clean. Plus, as committers, we can come up with cool and funny names like TPTP or COSMOS for our projects ;)

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 :)

Culture of Collaboration

Collaboration, collaboration, collaboration... how high do Eclipse committers value it? Is Eclipse missing something to help us as committers collaborate better amongst each other? I personally think so, especially after talking to some committers at Eclipse Forum Europe last week. Let me use an example from the field, there's a nameless independent committer on the Modeling project who has to use Skype, MSN, AIM, IRC and Yahoo just to communicate with his teammates (in real-time). From my point of view, that's kind of painful. For people who work in large companies where the committers on the project are mostly from the same company, it's not a problem since you have your own internal messaging system (I personally take this convenience for granted).

In my opinion, in order for Eclipse build diversity in the future, we need to create a culture of collaboration. To put it simply, we just need an easy way to talk to each other in real-time :)

I opened bug 126089 awhile ago with a proposed solution. The solution in its simplest form is an Eclipse Foundation XMPP server where all committers have accounts on (this would be part of getting your accounts provisioned when becoming a committer). If we really wanted to eat our own dog food, committers could use ECF to connect to this server (or their favorite messaging client).

What do committers think? Is this important? Do we really need yet another messaging system? If committers support this, I and the other committer representatives will do our best to make it happen.

Experiences with the Eclipse IP Process

In this week's integration build we have upgraded the org.apache.ant plugin to the Apache Ant 1.7.0 release.

To achieve this, I participated in the Eclipse IP process for non-EPL code...and I survived!

Seriously, the process was smooth, easy to understand and required only a modest time investment on my part.
I opened the request on January 31, 2007 and received approval on April 13, 2007.

Getting the approval (or denial) took much longer than I would have liked. To be honest, I was getting fairly nervous about getting a decision before the lockdown for Europa.
It is important for committers and the community for contributions to get in in a timely manner.

There will very likely be bugs that the community finds in Ant 1.7.0 and our integration of Ant within Eclipse. I have found three so far. These take time and exposure to find and fix.

As well, I believe we are a major channel for getting the new Ant releases out to the world. We had a much longer delay than in the past This is a delay in getting all those extra eyes looking at the code and finding the bugs.

Eclipse is a force in the open source community and we need to continue to have these strong indirect influences. Every delay in bundling or using other open source offerings potentially reduces this influence.

Parts of the IP process that we propose could be improved:

• indication of target date: similar to Eclipse bugs, an IPZilla request should be assigned a target and the target needs to be more refined than "Europa" or whatever the current release is. It made it difficult for me as a committer to plan my work not knowing when the approval would be coming. Predictability is important for any process.

• do the code review and board approval in parallel: it took an extra 19 days for the approval while timing out on the board approval. From my understanding this change is already in the works.

• more people to handle the load: we are serious about our IP process and we need to ensure that we have the people to deal with the work load. New IPZilla requests are just going to keep coming in and likely at an increased rate as the Eclipse ecosystem continues to grow.
  

I will be interested to see the next round when Ant 1.7.1 is released: how we evolve the IP process and the differences when a previous version of a contribution has already been approved.

We are very interested in other committers experiences: what worked well, what could go more smoothly.
Please comment so we all can work together to make this part of Eclipse even better.

Bugzilla and Flags

Howdy committers, we just wanted to make you aware of some upcoming changes to bugzilla that the Foundation (and a personal agenda of mine) has been working hard at (thanks Denis).

They are detailed in the following two bugs:

• Bug 177815
• Bug 178109

In the simplest words, flags have been added to each bug to aid searching. The flags are:

• reviewed: request a code review/flag as reviewed
• pmc_approval: request PMC/project lead approval/flag as reviewed
• documentation: flag to indicate documentation has been updated.

Also, flags have been added to patches so committers have the option to +/- a patch indicating to the patch contributor that he/she should redo the patch (see picture below).



If people have thoughts, we encourage committers to comment on the bug report or discuss it on the newsgroups.

Should Bjorn and/or Ward attend board meetings?

Probably many folks are just like me and have found Bjorn and Ward to be of invaluable service to the committer community. When I have questions about processes or infrastructure, these are the guys I go to for answers. Their latest work on a new portal is just one fine example; of course they had some help too from people like Karl Matthias and Sharon Corbett. I've often wondered how some of the councils could function without Bjorn's no-nonsense attitude, organizational skills, and personal dedication. Of course I've gotten mad at him before too, and anyone who knows me well knows that I may seem like a nice friendly guy, but when I get mad, it's not a pretty scene. But let's not go there! I'm learning not to do that in public. The point is, at that time I was taken aback by his extremely constructive reaction to my harsh criticism; that really made me respect him a great deal. Bjorn's a very good listener.

So to get to the point, I think it would provide significant value to the committer community if Bjorn and/or Ward could attend Eclipse Board meetings as observers. This would help provide continuity over the years and would help both these guys to understand more about what's going on and hence be even better helpers for our community.

I'm very curious how other folks feel about this?

Howdy Committers!

Hello Eclipse Committers (and community!), this is the inaugural post on the new committer representative blog. There are five newly elected committer representatives this year:

• Chris Aniszczyk
• Darin Swanson
• Ed Merks
• Jeff McAffer
• Konstantin Komissarchik

To start things off this term with the theme of open communication, the committer representatives have decided to do two things:

• Create a blog to keep committers aware of our activities this year.
  
• Create a newsgroup to facilitate discussion amongst committers and committer representatives. This newsgroup is meant for committers only and is open to the public for the purpose of transparency. The committer representatives plan to use this newsgroup as a way to work with committers to see what they desire or how they feel about a particular issue. A good example of an issue would be what to do with committer status? Should there be fine guidelines of when a committer would lose commit rights due to inactivity? Should there be different levels of so called committership? This is just an idea but we encourage committers to post their concerns regarding various issues.
  

In the end, we look forward to working with the committers this year in an open and transparent way. We're all ears ;)

What the heck is a committer rep anyway?

In a comment to Chris' initial committer rep post Eugene asked:

can you please explain what committer representatives can actually do and what kind of activities should we expect from you all?

It's a great question and I'll take a bit of space here to say what I think the committer reps can/should do.

First and foremost we are full and regular members of the board of directors of the Eclipse Foundation, a not-for-profit yada yada, etc, etc entity. We happen to have been elected to that position but that is neither here nor there. As members of the board we have to look out for the best interests of the Foundation. So no matter what committer motivated axes we might have to grind or business models might be funding the work at Eclipse, when working on Board matters, all members must have the success of the Foundation front and center.

Now different people have different ideas of success. That's actually what makes working on the board interesting IMHO. There are some really interesting people and discussions at the board meetings. In general, the committer reps have naturally tended to focus on things that improve the lives of committers as a way of enhancing the Foundation. Good software drives interest in membership and use which in turn drives success/security of the Foundation. Makes sense. Concretely in the past year that I have been on the board the committer elected reps have worked hard on such things as:

• IP policy changes to create a fast-track process for incubating projects
  
• Improvements in infrastructure and uptime
• The latest rev of the development process in particular the creation of the mentor role and the potential to rejuvenate the Architecture Council

I just picked a random three that sprung to mind. Committer elected reps are free to join the various committees (e.g., finance, IP, ...) that focus on particular areas as they see the need and desire.

So what should you expect from the committer representatives? More of the same I should think. Actually, last year was particularly fruitful at the Foundation level for committers IMHO. The problem is that we failed to communicate effectively what we were doing. This blog is a tangible attempt to address that failing and you should expect to see more information flowing out to you.

It must be said that the communication issue is complicated by the fact that board discussions are confidential until the board decides to publish minutes, results, policies, ... Board members, elected or otherwise, need to take care in communicating board discussions. It comes back to the role of board members -- to act in the best interest of the Foundation. Going off and blogging that we are considering merging with NetBeans would be counter productive. Well that was a joke but you get the point.

Turning the table around a bit, it would be good for us to hear from the committer community at large what you think we can/should do. Some information flow back to the board. Take the workareas mentioned above as template or examples of the kinds of things that board members can work to accomplish. We can't get a particular IPzilla CQ expedited but we can promote ways of streamlining the IP process. We can't go to project X and demand better quality but we can help put in place a mentorship program that would help X be more successful.

The committer elected board representatives are one of several windows the board has onto the committer community and vice versa. We should seek to be as transparent as is legally possible and act as a lens in focusing committer issues into items on which the board can take action.