Chris Aniszczyk's (zx) diatribe

As some of you know, Eclipse 3.4M6 is on the horizon. This is going to be a big and important milestone as it contains a revamped update (provisioning) system called p2. This is a crucial move for Eclipse as the old Update system which I was intimately familiar with (IFeature.STATUS_UNHAPPY anyone ;p) was antiquated… it was around before OSGi was put in as the basis of the Eclipse runtime. It’s time for a change…

What do you need to know? Well, p2 is pretty advanced compared to Update and the p2 team has done a good job with wiki-based documentation. However, for end users, there will be fairly little change in terms of what you see. The two most important things for end users I can think of is the work of creating a simpler Update UI (a work in progress) and a workflow change in how you add plug-ins to Eclipse. Do you remember that old technique of just dropping plug-ins in the plugins directory and having the old Update promiscuously install them? p2 has matured a bit and is less promisicous… however, there’s is a new ‘dropins’ folder where you can put your update sites and zip files:

The 3.4M6 release of Eclipse also signifies time for some penance. We have sinned against one of the greatest software engineering principles… eating our own dog food:

In the past, most people when they moved to a new version of some Eclipse project… we simply grabbed a new zip… unpacked it along with a new SDK or used the clever technique of link folders.

This is wrong.

It’s time to be using the p2 facilities to perform simple build-to-build updates. I have been doing this with the SDK recently and it works out nicely. When there’s a new update, I simply get the files I need using p2 and it does all the magic for me. The saying is that “old habits die hard,” and this is one habit that needs to change. In order to ensure the success of p2, it’s time to start eating our own dog food when it comes to updating plug-ins.

In Part 1, we covered defining diversity, now let’s talk about how to build diversity and attract contributors to your Eclipse (or open-source) project. Ed and I came up with this silly acronym to represent things you can do to build diversity:

• Blogging
• Blogging helps you reach your users and establish a relationship. In Eclipse land, it’s recommended to get syndicated on PlanetEclipse.org
• User Groups
• Meeting people face to face can help grow your project. In Eclipse, we’re starting to build Regional Communities.
• Incubator Projects
• If you truly love something, set it free. Control is an illusion, there’s only influence. Give up control to grow your influence.
• ListServ (Mailing Lists)
• If it’s worth talking about, it’s worth talking about in public. Use lists for things like meeting notices and development discussions.
• Demos
• People love demos. People even love screencasts more. In the Eclipse world, screencasts are king at EclipseLive.
• IRC
• IRC provides a way to know fellow committers on a different level. It can also serve as a support channel for your project. IRC is somewhat of a tradition the open-source community.
• Newsgroups
• Your users are the most important source of feedback you’ll get. Learn to harness them, they are your community and ultimately, your extended team. Sign up on the Eclipse newsgroups.
• Google Summer of Code (GSOC)
• Google pays other students to work on your open-source project. How cool is that?

There are also things like Wiki‘s and Bugzilla that are important too… with Wiki’s, you can empower your users to produce content. With Bugzilla, it’s important to be responsive, especially if you’re receiving patches from contributors. Even if you don’t have time for the patch, communicating with the contributor is important.

In the end, we believe if you share your passion with others, they will share theirs with you. Building diversity will make you and your project healthier and happier… therefore more sustainable.

Thanks for listening.