We had a great day yesterday at the Eclipse Day Montreal. The program was a perfect reflection of the diversity of Eclipse. Everything from IDE to RCP to IoT and beyond.

David Cummings, my partner in crime here at QNX, and I gave a talk on our work improving the user experience of our Momentics IDE, a lot of which we are now working on contributing to Eclipse. At the end of it we had a great discussion with the audience about how we enact change and make the improvements we need.

During that discussion I had one of those moments I treasure, when the words that explain what I’m thinking finally come and it links everything together. The question arose about how you deal with conflicting requirements. When you have features that people are used to and that advanced users appreciate but are things that overwhelm beginner users and make for a bad experience for them. Who wins?

My thoughts go like this. When you piss off an advanced users, well, they’re pissed off. They make a lot of noise, raise bugs, etc. When a beginner user gets pissed off, he stops using your tool because the barrier to entry is too painful. I chose the beginner. If you can get a new user to see all the greatness that we’re bringing with Eclipse, they get interested in it. They learn how to make plug-ins, and they eventually contribute to fix the things that bug them. The become the next generation of Eclipse committer, and it’s that next generation we desperately need right now.

I’m not saying we do things to deliberately piss off advanced users. We learned that with our work on the Launch toolbar. We make it great for beginners but advanced users found it useless and turned it off. In the latest iteration, we’ve fixed that and made it easy for advanced users to get at the properties pages to make the tweaks they want. It’s a balance, but if you don’t make the best attempt at reaching that balance, it actually harms the community. I wish more community leaders would understand that.

Anyway, I have had a couple of experiences now that confirm this actually works. On the CDT today, we have a fantastic young committer who started using CDT in a previous job and loved it. He was so excited he spent his personal time learning about it and got deep into the code, something that is so awesome about open source. It’s all there. He eventually started contributing patches to the CDT to fix things that bugged him. He did so many that he eventually earned his commit rights and is one of our top committers at getting things done. He was so good, one of our other committers convinced him to go work with them and now he works for an Eclipse IDE group and contributes to Eclipse as his day job.

And he isn’t the first. A number of our committers past and present came that way. I love these people, because they did it because of their passion for making great tools, not because they’re employers told them to. And it’s more committers like that who will help us keep Eclipse alive and well and on top.

So when you’re looking at a user experience problem, think carefully about how you solve it and how you treat the people who raise it. Every one of those people are potential contributors. Make them happy.