Design like you won’t be there tomorrow

For Eclipse Neon, we’re releasing CDT 9.0. Yes, it’s a major release, the first one in a long time. It’s our chance to clean up a few things that may or may not affect APIs but gives us that option. I think it’s healthy and we’re communicating as best we can our plans as they evolve to the cdt-dev list.

One thing that’s bugged me is the CDT build system. Not the thing that builds CDT but the framework we have that manages builds of CDT projects. I think it’s ridiculously complicated for certain types of projects. It solves everything and is uber extensible, but if you are building an integration, as I am now for Qt projects, where the builds are simpler or done by something else, CDT just gets in the way. It’s time to fix that.

Which got me thinking. The people who contributed the most complicated frameworks in CDT are now gone. Even the companies they worked for have become mainly inactive. As a long time contributor I’ve seen the generations come and go and I see the poor people who come now and have to deal with these things. I really feel for them.

I don’t know how much longer my employers and my wife will allow me to be a CDT and Eclipse contributor. It could be for quite a while longer or it could be over tomorrow. As I look at the things I’m working on, I have that in the back of my mind. I want to leave behind frameworks that are easy to understand and simple. And if there already exists simple frameworks that can do the job, ask really hard whether I need a new framework there at all.

As I peel away the layers of the onion that is CDT, I have to ask why some of those layers are there and whether the requirements that drove their creation are really valid any more. If it takes longer to use your framework than it would be to build something from scratch, what value did you add? I don’t want people who come after me to ask those questions of me. I want to be kind to them and leave something that really helps them. And hopefully, I’m doing that.

Eclipse, the IDE for IoT

One of my hobbies recently has been playing with my Arduino Uno. I just love how accessible microcontrollers have become along with all the little sensors and LEDs and other hardware components. It’s so easy now to make your own “smart” electronics project. Lots of tutorials on the Web and a handful of on-line electronic shops to help you get started.

What we’re also starting to see is cheap wifi chips that you can add to your project. Not only that, but chips that have the microcontroller and wifi on the same silicon and SDKs to write programs that hook up your sensors and LEDs to the internet. Anyone can jump on the Internet of Things bandwagon.

But what is the Internet of Things that everyone’s talking about? My definition is more than just accessible hardware. It includes accessible web servers and web clients as well. I have a server I pay $5/month for and was dead easy to set up. It’s small but it does what I need for now. Web development is exploding with easy to use frameworks and mobile continues to provide open, or at least freely accessible tools.

And that brings me back to Eclipse. I’m using CDT for my devices, especially as I work to make the Arduino C++ plug-ins mature enough for others to use and then add support for my other devices, the ESP8266 and Raspberry Pi. I’ve written web servers in both node.js and vert.x. The Nodeclipse plugins have helped with node, and vert.x is just plain Java and I use m2e to manage my Maven pom files and builds. And client side, well, Eclipse needs a bit of work to better support the newer JavaScript languages like React.js’s JSX and Angular 2’s TypeScript. And I’m happy to see the Andmore project keeping the Android plug-ins alive. And, of course, I have the BB10 plug-ins we’ve built as part of Momentics so I can program my phone.

That’s why I love Eclipse. I can build my entire IoT stack from device to client with the same IDE in the same workspace. I can debug the entire stack at once. We should also have the capability to navigate code from the client to device as well. What line of C++ code in my device software triggered that React component to light up in my browser? With great static analysis that a Integrated development environment can bring you, we should be able to see that.

Eclipse is uniquely positioned to be the IDE for IoT. It’s not only the technology that brings all these environments together, it’s the community. What other community has the diversity of device developers, web developers and mobile developers all working together on a common tools platform? That’s what makes Eclipse an exciting community to be a part of.

What’s next?

The Eclipse Mars release marked a special moment for myself and our team at QNX and BlackBerry. It’s the culmination a few things we’ve really wanted to get done for our Momentics users and share with the greater Eclipse community.

It is focused around the Launch Bar and we’ve received great feedback from those who’ve tried it and those trying to adapt it for their own launch configurations and remote targets. And working with the community is why we do open source. We built it first for our BlackBerry Momentics users building BB10 apps and they loved it. But as we push forward we can learn and benefit from other IDEs trying to adapt it. It just makes the architecture better for everyone and ensures we can adapt it ourselves as we try to use it for new things. Open Source isn’t a charity so we give, but it’s also not a donation as we get a lot back in return.

Now that summer is in full force and I’ve finished off some vacation, it’s time to start planning for the next year. There’s still some work with the Launch Bar to do to clean up the rough edges and get it to the point where I would encourage all Eclipse packages to use it. I also want to continue the work we started with the PTP gang with the org.eclipse.remote target management system and make it a good replacement for the Remote System Explorer. I hope to get that in place by the Mars SR-1 release in September.

I also want to get back into improving Qt support in the CDT to make QML and qmake projects first class citizens so that the CDT is a good option to Qt Creator and let Qt developers take advantage of the Eclipse ecosystem.

That led me into the discussion about how to make it easier to add languages to Eclipse, in this case QML. There’s been some great discussion on the ide-dev list and other places with lots of ideas. I want to use ANTLR 4 for the QML work and am hoping I can generalize out of that so we can make it easier to add other complex languages like it. I’d like to extend CDT’s support to all languages supported by clang and LLVM. Even Swift if that’s the direction they take to open source it.

And it opens up an area in CDT that we really need to improve to allow us to take advantage of new toolchains and build systems. The CDT build system has always been somewhat cumbersome both for adopters trying to hook our tools up, and users who are trying to set up their build environments. We’re going to work with the CDT community to see if we can come up with a simpler architecture that takes advantage of the build systems, such as Qt’s qmake and CMake, that weren’t around or as mature when we started.

I also have my personal work on the Arduino C++ IDE for CDT. IoT is a great area of focus in open source and it’s really fun to architect an IDE for. You have a lot of choices in micro-controller (Arduino, ESP8266, and many upcoming Cortex-M* boards) and Raspberry Pi and other Cortex-A* boards. We really need to have CDT in shape for those developers.

But IoT goes beyond devices, you also have the cloud that they pass data to and get commands from, and then you have the Web and Mobile clients that hook up to the cloud. IMHO, Eclipse is the best choice as an IDE to build and debug all those components. And with my recent work at QNX, I have first hand experience at that and swear by it.

Lots to do and I’m certainly not going to get it all done when I want to, but we’ll keep plugging away and accept help when it’s offered and we’ll get there.

My Journey to Mars, Eclipse Mars

Wow, Eclipse Mars is almost finished and it’s been very busy for me and those I’ve been working with. We have a lot of exciting new features coming and I can’t wait to get them into the community’s hands and see where they take them.

I’m going to write more over the next few weeks on each of these, but I thought I’d give an overview of what you can expect for Mars. They all stem from a common theme, make Eclipse easier to use and lower the barrier to entry for new users, especially those writing C and C++ as a hobby, the new breed of hobbyist computer engineers using $10 computers to build amazing electronics projects. New users mean a growing and vibrant community.

Here are the highlights.

Serial Port Library

CDT has a pretty interesting native library that provides interfaces to native tools that the Java run-time doesn’t. This includes a Process subclass called Spawner that can send Unix signals, a Pseudo TTY interface (PTY) that can be used to set up terminal like interfaces to processes, and access to the Windows Registry.

One thing that is really common with these new $10 computers, especially the microcontrollers like Arduino is that you need to connect to them with a serial port to see what’s going on. For whatever reason, the serial port libraries out in the open were all GPL/LGPL and the main one, rxtx, has disappeared. Serial port programming isn’t rocket science, so I wrote my own library and added it to the CDT native feature. My first use is with the Arduino CDT covered below.

Remote Target Management

As I was building the LaunchBar (coming up next), I needed a way for the user to select which system to launch on. I made one that was pretty simple that adapted the targets such as those we were using for QNX and BlackBerry. I then started adding features, like a View to interact with the targets and then thought about a services architecture that would add command shells, remote launching, remote file access, i.e., a full blown target management system.

Well, that reminded me of Greg Watson (from PTP fame)’s talk from a few years ago about the fact we have too many target management systems, and none of them do everything we need. So he started one that does. I decided instead of writing my own, I’d add my vision to Greg’s and come up with an uber flexible, services oriented target management system. The beauty is that it’s easy to adapt to any existing TM system. And we’ll continue to build out features and make it a suitable replacement for RSE in upcoming releases.

Screen Shot 2015-05-18 at 1.56.06 PM

The LaunchBar

The LaunchBar has been the focus of my team at QNX’s efforts to fix up one of the biggest usability issues we see with Eclipse, the whole mechanism to launch the applications you’re building with the IDE. There’s been some work to improve that over the years, such as the launch shortcuts, but frankly, other IDEs do a much better job at this.

We felt it was important for the user to know exactly what was going to happen when they hit the run button. And that’s accomplished by showing the current selection, i.e. What you’re going to launch, Where you’re going to launch it to, and How you’re going to launch it. How is simply the launch modes we’ve had in the past but make more accessible. The Where relates to my work with the Remote TM system. In this day with embedded targets and cloud servers, we’re often building software that’s going to run somewhere else than our desktops.

The most important aspect what helping the user define What they’re going to launch. And really, my objective here was to make it so that the user never needs to go the the launch configuration dialog for the most common cases. To help with that, we have an automated system the populates potential What’s. By default, launch configurations are a What, obviously, and that makes the launch bar usable with existing launch configurations. But the system is flexible, and What’s can be anything, for example, Arduino projects.

Screen Shot 2015-05-18 at 2.00.03 PM

Arduino C++ IDE

My first foray into the hobbyist computer engineer world was with Arduino. I bought an Arduino Uno and built a little system with a sensor and a wifi shield that was a kind of Internet of Thing. But after years of using professional IDEs, the last many being Eclipse, I wasn’t very excited about the standard Arduino IDE. Also, Arduino programming is done through this language called Wiring which, come on!, it’s so close to C++, why not teach hobbyists those last two or three concepts and “Program Your Arduino in C++ Like a Pro”.

And, hey, I know this great C++ IDE they can use. So, and this is the self serving part, I set out to build an integration for the Arduino toolchain for CDT. And it turned out pretty nice and I enjoy using it for my Arduino projects. And as a bonus, I get to use the same IDE, hell, same workspace, to program the server side of my Internet of Thing project. For me, that has always been the promise of Eclipse: One IDE to rule them all!

I have the plug-ins in CDT and they’ll be coming out in Mars. It’s really only a preview at the moment and you’ll need to have the standard Arduino IDE installed for it to work. As I was wrapping up the Mars work, Arduino released their 1.6 version and with it and pretty nifty library and BSP management system with an open data format. I plan on adding support for that system to the Arduino CDT plug-ins as well and that should eliminate the need to install the Arduino IDE if you so desire.

The Journey Continues

As I mentioned, I’ll write a lot more about these features in the upcoming weeks. It’s going to be hard to try them without a little documentation and that will come here on my blog for now until things mature. There’s a lot more ahead as I get feedback from the community and people try to use these things in different configurations. I already have great feedback from the Red Hat JBoss guys who are trying to use the LaunchBar for WTP that’s resulted in a pretty big last minute change. But this stuff is only successful if people use it and contribute back so I’m more than willing to listen.

Also my journey into the computer engineer hobbyist world continues beyond Arduino. I have a Raspberry Pi B and I have been able to build an ARMv6 hardware float toolchain for it. We’ll likely make this the first official embedded target support provided by the CDT as an example for the embedded vendors to follow. We should have done that a long time ago.

I’ve also just purchased a couple of ESP8266 chips. They’re little microcontrollers inside a wifi chip with a healthy number of GPIO pins, all for $10 or less. The Chinese company that makes them has put out a pretty good SDK and the toolchain is again standard GCC. I need a CDT integration for these too :).

I mentioned in my note about EclipseCon that I think this is probably the most exciting time to be in the Eclipse community since they early days. So many new features and great work being done by a diverse team of really smart people has breathed some much needed new life into our favourite IDE.

EclipseCon 2015, the Ship Tacks

I’ve been to all 12 EclipseCon North Americas. I especially love coming to this year’s venue, the Burlingame Hyatt, because it hosted the second one in 2005 which has been one of my favourites. It was a very different EclipseCon back then. There were probably more product and marketing managers than developers and the buzz was incredible. We had two of the greats in the modelling industry going head to head, IBM Rational and Borland, and it was a fun spectacle to watch from our CDT viewing rooms on the periphery. I’ll never forget it and I always take a pause when I get there to soak it all in again.

In recent years, EclipseCon has become a developer’s conference, and frankly we developers prefer it that way. You don’t get the same numbers or the same marketing buzz, but we build some very important relationships that carry us throughout the year and we wouldn’t survive without it. I’ll never forget our last time in Santa Clara and Kai Toedter still working away at the e4 challenge as we closed the bar at 2 in the morning. We developers know how to have our own fun.

It’s been a hard few years for Eclipse though, at least for the IDE. It’s been kind of sad, but we spent a lot of time complaining and worrying as more and more of our friends from the Platform started working on Jazz and Orion and not on the Eclipse platform. Having been there, I know the business decisions behind such things and it’s pretty easy to understand the need. But it didn’t make us happy, and we were somewhat counterproductive fussing about it.

This year, though, was totally different. We talked very little about that past. It was replaced by discussions and demos of the cool things we are working on now to revitalize the Eclipse IDE that we all know and love. My feeling of worry in the last few years has been replaced with feelings of hope and energy to continue on the fight to save it. And we have new leaders in the community driving it: Lars, Mickael, Sergey on the Platform, Max on Web development, Eike providing us some Oomph, Greg and myself on revitalizing target management with a new look at the Terminal and my new LaunchBar, plus all the great stuff still happening in the DSL and modeling space. Even the Orion guys seem open to working with the JSDT guys to bring the two technologies together and provide a great JavaScript experience in the IDE.

I’ll be writing about the things I’m working on over the next few weeks, including some new energy we got out of the CDT Summit and an interesting chance meeting that will bring some interesting tooling for Arduino fans. We have a lot of work ahead and it’s important we communicate and work with the community to make it right.

Eclipse solved a problem we had 15 years ago over the need for an industry standard and open platform where we could install all our tools and have them interact with each other to make a greater whole. 15 years later, we still need that. And as Eclipse jumps back to life, I’m excited for great things again and am working with a great group of developers who are all intent on making it happen. EclipseCon gives us that much needed face-to-face and the opportunity to show the community what we’re doing and invite them to join in on the fun. I can’t wait until the next one.

Making a UX splash for Mars

Over the last few weeks, I’ve been putting the finishing touches on our LaunchBar contribution to Eclipse. It started out of work we did for BlackBerry Momentics. Our goal was to simplify Eclipse as much as possible so new developers wouldn’t be so intimidated by it. One of my pet peeves has always been the launch experience. The poor new users who have to dive into the fire and figure out what all those settings in the Launch Configuration dialog are, let alone learn what a launch configuration is.

After looking around at how other IDEs handled launch UI, we built a sort of “best of” and put all the great ideas together into a uniquely Eclipse LaunchBar. The LaunchBar provides selectors for launch mode, thing to launch, and place to launch it. It also provides buttons to build the projects for that launch, to actually launch, and a button to stop all current launches. You always know what’s going to happen yet easy for new users to understand but with all the power of launch configurations only a click or two away.

Screen Shot 2014-03-14 at 10.08.11 AM

I’ll write more about the LaunchBar and how you can use it in your environment over the next few weeks. I’ve retargeted the release to Mars so that I can integrate it with the PTP’s org.eclipse.remote target management system, which I’ll also blog about soon. But to give a teaser, I thought I’d show what I’m using it for today.

I’ve become a fan of Arduino and similar microcontrollers (I have my Spark Photon order in too). My next project is to produce some sort of wearable that lets you put RGB NeoPixels over you’re body along with the microcontroller and a microphone so that the pixels flash and change color to the music you’re listening too. My prototype board looks like this:


Now, I could use the Arduino IDE to build this, but given the title of this blog is CDT Doug, you know I want to use the Eclipse CDT and things like the LaunchBar and Remote framework. And here’s what it looks like so far:

Screen Shot 2015-01-11 at 12.54.56 PM

As you can see, the LaunchBar is pretty natural. Click the Play button to “Run” “ArdunoTest” on “Uno”. Run is the launch mode, ArduinoTest represents the project for which a launch configuration will be automatically generated, and Uno is my Remote Connection to the Arduino board hanging off my USB serial port.

There’s much more to come but I’m totally excited how this is working out. I use the LaunchBar every day to launch various Eclipse run-time workbench configs and Maven jobs and now C++ project launches for my microcontroller. I can’t wait until I can get it into more people’s hands and hopefully it can help get more people excited about using Eclipse again.

CDT in the New World

An interesting thing happened the other day which I think shakes some of the foundation I’ve had in my mind about the CDT. My vision was always for CDT to support C, C++, and related languages on every platform. And that has always included Windows. Mind you, we’ve never really done a great job there but we do have lots of users using it with Cygwin or MinGW and you can argue how well they support Windows application development.

The big news was Microsoft’s Visual Studio Community Edition which is a free version of their complete IDE for individuals and small teams. This is different from their Express editions which were severely limited in the end, including lack of 64-bit support, and the inability to install plug-ins into the IDE. No, the community edition is the full thing and is a pretty important step for Microsoft as they try to keep developer interest in their platform.

As long as Microsoft charged money for Visual Studio, I always thought CDT had a play. I’ve done a little work on supporting integration with their Windows SDK (which includes a 64-bit compiler) at least for build. Debug was always a big hurdle since you’d need to write a complete debugger integration that is very different from gdb. So, really, this integration barely worked. And now that VS is essentially free to the market we serve, there’s little point at continuing that effort. The same is essentially true with Objective-C support with Xcode on Mac, which even they are drifting away from to focus on their new language Swift.

But you know, despite giving up on a dream, I think CDT has an important role to play in it’s field of strength, i.e. support for the GNU toolchain, especially as used for embedded development with it’s new found focus as a pillar in the Internet of Things. As I’ve talked about on Twitter and on CDT forums, I am working on a CDT integration to support building C++ apps for Arduino. Once that’s done, I’ll shift focus to a more complicated environment around Raspberry Pi which I hope to add better remote debug support to CDT. Yes, I know everyone loves to talk about using scripting languages on the Pi, but I want to expose these hobbyists to the real world of embedded which is almost exclusively C and C++, and get them started using CDT.

I still haven’t given up on the desktop, at least desktop support with Qt. I really want to make CDT a first class alternative for Qt development. We have a good start on it and will continue with things like a project file editor, easier setup of builds, and import of projects from Qt Creator. The great thing about Qt is that it also is truly cross platform, allowing you to write your app to run on the desktop and then migrate it to your embedded device, such as the Raspberry Pi. And supporting both of these with the same project is one thing CDT is pretty good at, or at least will be once we fix up the UX a bit.

In the past, much like the rest of the Eclipse IDE, I think we on the CDT have focused a lot on being a good platform, almost too much. While vendors have done a great job at bringing the CDT to their customers writing for their platform, including my employer :), aside from the Linux community, few of us work on supporting the direct user of the Eclipse C/C++ IDE. I think focusing on CDT’s areas of strength and targeting specific open environments and not chasing dreams will help me contribute to the CDT in ways that will actually help the most people. And that’s most satisfying anyway.

I have a dream, an Eclipse UI dream.

Humour a madman for a second :).

A few months ago, I was pretty excited about the prospect of Eclipse running against a modern UI framework such as JavaFX. Modern applications have a flow or liveliness to them. They aren’t just a bunch of toolbar buttons and menus that take umpteen clicks to do the things you want to do. They move with animations and effects that make your app feel alive. Not everyone agrees that’s what an IDE needs, but I’d like someday to take the time and experiment to see if it does.

And I’ve seen some of what’s possible. Cole Markham’s talk at EclipseCon this year on using the JavaFX e4 renderers for the RCP apps he was building showed the potential. His apps are beautiful and much thanks to the CSS capabilities and animations in JavaFX. It can be done and it can be good.

But what of the Eclipse IDE? Originally I thought we could port SWT to JavaFX and then introduce JavaFX slowly into the vast collection of IDE plug-ins. From Tom Schindl’s great work on this and his experience with it, I’m not sure either of us, or anyone for that matter, thinks it’ll really work. The paradigms are just too different. Maybe JavaFX can evolve to make it closer (and it is indeed still a young API), maybe not.

Where to then? I sometimes go down a dark path looking to too see where the next revolution in IDEs would come from. Eclipse was quite disruptive back in 2000 and had great success. But have we reached a stagnation point forced on by the architecture and tragedy of commons it has brought onto us (without standards and with uber flexibility, every plug-in has been free to implement their own UX and many have)? Will IDEA lead the way with it’s better funding? Will QtCreator take over the C++ world? Or is everyone just happy with their text editors and command line tools that we’ll regress back to the 1990’s?

Well, if there is to be a revolution, a new IDE framework that will fix all that’s broken with the existing ones, I’d actually like to look back at Eclipse. Often when I explain why we have Core and UI plug-ins for all our projects, I’ll bring up that maybe one day we’d like to replace the UI with something else, something not SWT. And maybe this is it. Reuse the valuable Core plug-ins we have that support build and debugging and static code analysis and source control integrations, and replace all their UI plug-ins with new ones that use a new UI framework based on JavaFX.

Am I insane or naive to think that would work. Maybe I don’t think that would work. But I can dream. And maybe someone with the resources will think it’s a good idea and make that dream come true. Or maybe not.

Motion Sensor to Phone App – an IoT-kinda Project

My son Alex is autistic. That presents a lot of challenges for my wife and I and, of course, for him. He’s generally at peace, but suffers from a lot of anxiety in situations that are new and he really wants everything to work out OK. We also have a very nice backyard with a gazebo on the deck and days like today, my wife and I love to sit out there. But from there we can’t see if someone comes to the front door and we don’t want Alex to have to deal with solicitors or what have you giving him a situation he can’t handle.

So that was the germ of an idea, which of course for me, has grown to a pretty big hobby project (with work implications, of course). Searching for possible solutions, I ran into the Adafruit website which has some great tutorials on how to build gadgets for this very type of problem. They sell a motion sensor for $10 that I could place on the front porch somewhere to detect when someone came up (not everyone rings the door bell and the motion sensor is more interesting).

Now, I want the motion sensor to raise a notification on my phone when someone triggers it. Very cool problem for we architects to have to solve. First do I go Arduino, Raspberry Pi, or BeableBone? Given the simplicity of the hardware, a single sensor, doing a board that has a GPU and HDMI out seems like ridiculous overkill. So I’ve gone Arduino and bought an Uno as well. I love the Arduino because it gets you into the core of the embedded world. There’s no OS, just bare metal and your code, and a few library functions to get you going. Everyone with a computer science degree should have had to do something with an Arduino. It’s the absolute core of what computers are.

Next up, I have this web site,, which I host on DigitalOcean. It has an nginx front end to WordPress for this exact purpose, to host web apps as well. So I want my phone to connect to it, and the motion sensor so I can find out when it gets triggered. Adafruit sells a wifi shield for $40 which is supposed to be good. But to start, I’ll just use the serial port on the Arduino to send messages on my laptop and have a node.js server that forwards it to the server.

On the server, I’m going to use vert.x. I notice a few Internet of Things type projects that are using it. The plan is to have a vert.x vertical to watch for REST calls coming from node.js and eventually from the Arduino itself with the wifi shield. Phone apps will connect to the server using websockets managed by another vertical so that when the sensor triggers, it can send in a REST call which gets forwarded over the vert.x event bus to the websocket server which can the forward it to the phones. It’s beautiful in it’s simplicity and in the minimal amount of code I need to write to actually get this to work.


So it’s projects like this that feed my passion for the Eclipse IDE. I want to be able to do all of this from a single workspace. CDT to do the Arduino code, Nodeclipse to do the node.js server, m2e and JDT to do the vert.x server, and ADT for the Android app and Thym for Cordova. If I’m missing pieces, I will build them and make them available. A proper Arduino CDT port is first on the list. I’m also curious how easy it is to do vert.x development in Eclipse. And everything needs a good debug solution from end to end (which may be a challenge on the Arduino since it doesn’t have an OS). This would be a great showcase for the Eclipse IDE and it’s place in the Internet of Things. I’m going to do my best to get this working. More in future posts.

P.S. I hesitated to call this an Internet of Things project. Designs like this have existed forever. They were just industrial automation systems with reporting to a central server. But if it gets me noticed, then while in Rome…

Who are you building this for? A UX Story.

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.