Monthly Archives: September 2006

JDT/CDT, Can’t we just get along?

So between putting the finishing touches on CDT 3.1.1, some QNX work items, and dealing with the various summits and stuff, I’ve started working a little on my CDT/Windows Debugger API integration. It didn’t take too long before I got my workspace set up to work on it. I’m creating Java classes that will plug into the CDT’s debug engine (or engines as the new Debug Services Framework comes together). I’m also creating C++ code to implement native methods that talk to the Windows APIs. I’m also about to figure out the right way to do callbacks from those APIs trough my C++ code up into the Java code.

I’m trying to follow as much as I can the SWT model by doing as little in the native code as possible and putting most of the logic in Java. As much as I prefer C++ to Java, I don’t have a good answer to the question “How do you debug the debugger” so I’ll be relying on the Java debugger and good ol’ printfs to get me through.

But once you have a mix of CDT and JDT projects, the workflows aren’t pretty. The first thing that hit me was when I was in the C/C++ Perspective and hit the New Class button to create a Java class. Uh, nope, that creates a C++ class. So I’m starting to find myself flipping back and forth between the Java and C/C++ perspectives to get the right navigator views and toolbar buttons at the right time. It’s a pain and it would be nice if we had a “Code” perspective or something where we could write code without the context switching.

And then, there’s the result of my work. When I do get the debugger integrated, I may just wish to debug my debugger or some other JNI application with it. The “Holy Grail” for us in CDT-land has always been to be able to step from Java code into C++ code and back and forth seamlessly.

We’ve talked about this since the first CDT get-together back in July 2002. I’ve tried to get it to work with some success but got sidetracked with other things. The guys at Intel presented a proposal on such an environment at our Spring summit, bit I haven’t heard much about that since. I’m interested in hearing peoples’ opinion on whether this is something they feel is important for Eclipse. And, of course, I’m interested in ideas on how we can build a community to help make this happen. If nothing, it will be a lot of work.

Right Place, Right Time (part 2)

Having concluded that I haven’t done anything really to help guarantee the CDT’s success, I do have a few mantras that are hopefully contributing to a healthy community.

  1. Be open. This was actually pretty hard at first when it was only QNX and then only QNX and IBM/Rational when the only people who cared about what you were doing were sitting down the hall or across town. But with the CDT development community spread around the world, working in the open is critical. In the CDT we have healthy discussions in Bugzilla and on the cdt-dev list and are looking at ways to share ideas and work together more often and more fluidly.
  2. Equality. A lot of open source projects tend to be dominated by one or two organizations and unfortunately a lot of Eclipse projects are this way. In the CDT, no one dominates. No organization has more than around 5 developers and most are around 2. And there are over 10 organizations involved. We honor the veto committer voting system so we aim to get consensus before taking big steps and usually do.
  3. Spread the Word. At times I feel like I’m a part of our marketing team here at QNX, and I guess part of my role is that. You can hope people stumble onto your project and get interested, but the media has a role to play helping you spread the word. And with the number of online magazines and webinar services in business now, they are always looking for a new angle. Take advantage of it.

That’s the main ones I can think of right now. The funny thing is that, as a developer, all of them go against the grain of who we are. We all love the code we write and feel we are owed some degree of ownership over it and feel we don’t need to explain it to anyone. But as soon as you click that Commit button, it’s out there for anyone to see, change, criticize. The best rule of thumb I have is to be open and honest about my work and to appreciate the opinions and ideas of others. We’re all in this together, no matter who signs our paychecks.

Right place, Right Time (part 1)

One thing I’ve been asked recently is to share why the CDT is successful in the Eclipse community. It’s a really hard question for me to answer since I’m not sure I can trace anything I’ve done as a project lead to help with this success. That and I’m not sure whether it really is successful. I’ve been pretty happy with its popularity with over 340,000 downloads of CDT 3.0.2 and 35 developers attending last weeks CDT summit. I think we still have a long way to go to reach the quality levels of the JDT and VisualStudio, but now that we have so much attention on the CDT, we’re trying to address that. So, I think the real question is – why is the CDT so popular, and what have we done as a project to help achieve that. My answer is in two parts so I’ll make this a two part blog entry.

So the first part of my answer is this: “Dumb luck”, or maybe slightly less self-deprecating, “Being at the right place at the right time”. QNX started the CDT back in 2002 because we needed an IDE to help developers writing applications for our operating system be more productive. Now, we’re not an IDE company and seeing what IBM had in store for building an open source community around Eclipse, we reckoned that would be the right way to go for the CDT as well. The hope was that lots of other non-IDE companies needed an IDE too and we could all share the development cost of it.

It was a gamble and it did take four years to reach this point, but in the end we were right. The reason the CDT is so popular is that there is a huge need in the non-Windows market for a universal IDE that vendors and users can easily leverage for their own needs. Given the huge popularity of Eclipse and with the CDT being the C/C++ solution for Eclipse, it just becomes natural that people gravitate to the CDT. That and the CDT promises to be a high quality, feature rich C/C++ development environment that you have had to pay money for in the past. Everyone like free stuff that’s good.

So in the end, I don’t think we’ve done anything in particular to help make the CDT as popular as it is other than simply having the right solution at the right time. I wish I can claim otherwise, but it is what it is. In the next part of this blog entry, though, I will try to list some of the things we’ve tried aimed at making sure the CDT is an open, welcoming community that will hopefully keep this momentum going. Having something good and free helps with consumption of your open source project, but it doesn’t provide any guarantees that it’ll attract developers to help you build and test it.

CDT Fall Summit Wrap-up

When I finalized the agenda for the Fall Summit this year, I didn’t think there was any way we’d fill up 3 days. Thinking back to last year, we really ran out of things to talk about by noon on the third day. I also figured that it would be a great idea if we had some time to go through the code and work through some of the nitty gritty details with the gang huddled around a laptop. So I decided to set aside Thursday afternoon for that.

Well, at the end if it all, given the number of topics we had to chop out and the number of items where I had to say that we were running behind, we could have spent a whole week. Mind you our brains would have been mush. They were anyway after three days. It was great to see that we have a big development community that knows a lot about the CDT and want to make it even better. It also showed that we need to do this more often, maybe not travel, but find some way to share ideas and debate even virtually.

One of the best items we had, at least for me, was at the very end. I asked the group how we could improve how the CDT is run as a software project. The answer I got back was that we need to work hard on ensuring we have quality releases. In the past, we’ve been very accommodating to developers, accepting that they come and go and contribute what they can when they can. But that adhoc approach to project management isn’t leading to high quality releases, especially at the x.x.0 releases. The team showed a strong desire to, well, be “managed” as a software development team, much like they are when working on their own commercial projects.

So that is now my number one challenge. We need to tighten down the processes, be more strict on quality, and start putting together guidelines that we need the developers to follow. We also need to ensure that our test coverage is managed and improved. Manage the CDT much like any software development project. To me the big challenge is that none of these developers have any contractual obligation to follow any of this. And we have developers from over 10 different organizations. This is open source and they are volunteers (or at least their organizations have volunteered them). So it is going to be a bit of a delicate balance to ensure we have the right mechanisms in place and that the developers honor them.

But at the end of the day, I think just having processes and guidelines will give the developers something to follow and they will probably feel naturally obliged to follow. And with the strength of the characters that we have working on the CDT, I’m sure a little peer pressure will help too. I am very excited about moving into this next stage in the maturing of the CDT project. If it all works, maybe I’ll do an MBA thesis on it :).

More Open Source Hardware

I’ve got Google Alerts notifying me when something comes up with Eclipse CDT and another one for Eclipse embedded. I’m starting to get a few of these a week, including two today. One came from Lattice Semiconductor. What was noteworthy in this case was they were also open sourcing the design for their 32-bit microcontroller. Now these guys are a lot smaller than Sun who open sourced the design for their Niagara 8-core Sparc chip. But I’m starting to wonder if there really is a trend happening here.

If this means we’ll see more people customizing chip designs using hardware description languages and building the software that will run on them, then Eclipse is an obvious host for this kind of hardware/software codesign activity.

CDT Summit Day 1

Well we got off to a great start at the Summit today. The day went by real fast and we were all pretty burned out by the end of it so it must have been good :). One highlight for me was when I asked for hands on who was a committer. I got the 7 or so I was expecting. I then asked who had contributed patches. To my happy surprise, I got over 20. That explains why we have so many patches outstanding in bugzilla for the CDT. It is certainly one sign the CDT contributor community is healthy, but its also a sign that we have a lot of work ahead to keep up and to start nominating more committers.

We spend the day introducing eachother and then dug deep into the CDT DOM. I have to admit that one was really dry, and I was the one giving it. We then got an update from the Intel team on what they’d like to do with the build information in the new project wizard and the project properties. Looks like a big change that should hopefully smooth out some workflow issues that we have there. Another big day tomorrow as we review some of the new source navigation and indexing features and dig into debug.

Another thing I’m trying is Skypecast to broadcast the proceedings. You can check it out by following the link. It is definitely a technology preview and we had a hard time getting remote people hooked up to the sound system we have running without horrible echo and feedback. But the broadcast out sounds O.K. (as long as I mute the mic on my laptop, sorry Norbert!) I’m sure it would work better if everyone was working through headsets, instead of trying what we’re doing with capturing the audio through a sound board. But it is an interesting way of communicating when working on open source projects.

CDT Summit Eve

The CDT Fall summit for this year starts tomorrow here at QNX headquarters and I’m getting both excited and nervous, as I guess I should. We’ve had a number of summits in the past starting all the way back with the first one in July 2002 when QNX brought the CDT as we know it to the world. That summit and pretty much everyone since then has had kind-a the same feel. Lots of people have been interested in what was going on, but few have had the resources to commit to helping out.

But you know, there’s nothing wrong with that. It’s a pretty difficult decision for corporations to commit resources to work on open source projects. It’s difficult to track the return on their investment and there are a slough of legal issues that need to be addressed and tracked to make sure the IP walls are set up correctly, and I’m not just talking networking. I’ve learned to be patient, not get too down when hopes fail to materialize. In the end, simply using the CDT and distributing it in their products means that the CDT is getting good test coverage, which is just as important these days.

My feel for this one, though, is different. Maybe it’s because I’m starting to be overly optimistic. We have around the same number of attendees registered as we did last year, and a lot of them are the same faces. However, this year most of the attendees have been contributors to the CDT. Some have become committers over the year and some will become committers shortly after the summit. We’ll use this as an opportunity make sure we are talking to eachother and co-ordinating our work. We’ll also use it as a team building exercise as I’m sure we’ll find a few battles along the way. It sure helps when you know the person at the other end of the bugzilla entry when smoothing over issues.

Finally this year, it looks like our contributors summit will focus much less on recruiting contributors and much more on co-ordinating actual contributions. It’s a much funner summit to run and hopefully a much funner summit to attend.

Open Source Hardware

I’m sure I’ve told this story before somewhere, but I used to sit across from an ASIC designer many years ago. This is when I first started using ObjecTime Developer for software modeling back in the early 90’s, a couple of years before I joined the company. He was marveling at how we software designers had started using graphical tools, just as ASIC designers were abandoning similar tools for textual description languages. I’m not sure why they made that transition, but given the complexity of the chips they were designing, my bet is that the graphics didn’t scale well for them and the tools back in the early 90’s weren’t very good – no Eclipse back then!

This guy was coding in a hardware description language called Verilog. I peaked over his shoulder one day and saw that it looked a lot like C code. I found that very interesting but it took many years before I sat down and took the time to learn a bit more about the language and what it could do (there wasn’t much of an Internet back then either). It indeed was C-like and was structured a lot like C, and I’m sure suffers the same scalability issues that programming in C can sometimes cause. Thankfully, there is an Eclipse plug-in to help you write your own Verilog code.

Fast forward to the recent future and my interest in MultiCore processing, I found it quite interesting when Sun announced that they were open sourcing their Niagara line of processors. Diving deeper, I was able to find the Verilog code for their T1 chip published on www.opensparc.org. Other than being cool to look at and maybe interesting for students to learn CPU design with, I didn’t really see the benefits of open sourcing a CPU design.

Then yesterday, I ran across an announcement from Simply RISC that their engineers had taken the open source T1 code and made a simple SPARC embedded processor out of it. Of course with the T1 source being GPLed, they have released the source for their CPU as well. Is this the start of something? I’m still a bit doubtful. Chip companies make most of their money on the designs they come up with, not necessarily the chips themselves. But it is an interesting phenomenum to watch out for.

MultiCore: The True Promise of Eclipse

So, I needed a board to help try out some JTAG things (for those readers not involved with embedded development, a board is a little computer kind-a thing). We had just received an OMAP board which uses a TI chip that contains both an ARM general purpose processor as well as a TI DSP (digital signal processor). Of course, my focus was on the ARM processor that runs our operating system and it was pretty cool to getting it up and running with little effort.

But after a while, I started wondering what people use this board for. I’ve been away from embedded development for a few years and man have things changed while I was away. I soon discovered that the main use of this thing is for audio processing. There are some audio jacks as well as a connector to plug in an LCD screen. By programming some audio processing algorithms into the DSP, you could make a pretty cool multimedia device with this thing.

My curiosity then wondered over to how one would program the DSP. If I had a compiler with an integration with the CDT and a debugger that understood how to debug the DSP and that was also integrated with the CDT, then I’d then have a complete multi-core development solution where I could have regular software projects and DSP projects and work on them all at the same time.

It’s a very interesting time in the embedded industry with the multi-core phonmenun. I think we’ll see a lot of new processors come out that have specialized parts. What I hope to see, and I’m pretty sure it will happen, is different vendors working together integrating their Eclipse-based technologies and unify their development activities into a single workflow for the developer who sees these boards as a single target. That is the true promise of Eclipse!

Did someone say doughnuts?

I just read Bjorn’s note comparing doughnut stores to open source businesses. From what I hear that note probably made more an impact on Canadians that it did others. For some reason, we’ve rallied around the doughnut as our national past time and our waste-lines are paying the price!

At any rate, I totally agree with his assessment. My spin on it, you can make money by packaging up open source and selling priority support for it, and you can make money by taking open source and customizing it for a small vertical market. Certainly we at QNX are doing the second, taking Eclipse and customizing it to work well for developers writing applications for our operating system.

Another analogy I thought of also has to do with Tim Hortons. After Wendy’s (the burger Wendy’s) merged with Tim Hortons you started seeing a lot of Wendys and Timmy’s co-located in the same restaurant. So the analogy could go that people love doughnuts. So when the come to Tim’s and get their fix, they see the Wendy’s there and decide to stay for lunch.

So what I’ve also seen vendors do is package Eclipse as a sort of loss leader to get people interested in their higher margin products. My recent blog on the JTAG vendor Ronetix is an example of that. And I think we’ll see a lot more as well as Eclipse becomes ubiquitous (2.27 million users!). Vendors will find they have to play the Eclipse game just to keep up with the Jones.