The community never ceases to surprise me

I hate blogging more than once a day. But as soon as I posted my last one I checked the CDT bug reports to see what was coming in. I ran into this one, 207482, raising the issue that the option to intermix header and source files in the Projects explorer isn't working. That's no good since I hate that we separate them now. But I didn't realize we had put in that option and will have to try it out and see what's wrong.

But never mind that. What really made my day was the e-mail address of who raised it, whirlpool.com. You know, I suppose that appliances are so advanced these days that they have a processor and a hunk of firmware that runs them. And why not use the CDT to develop that firmware, it's one of the things we're really good at. Assuming that's what this guy is doing (and I don't think it's my place to ask since that's probably proprietary information), Cool!

Ever rising expectations

You know there was a time when I though syntax highlighting was a cool feature. It made it easier to see your code by allowing you to focus on the things that are important, like the names of functions you call and variables you have. With the correct coloring, keywords tend to slip into the background where they belong.

Well, content assist with STL iterators doesn't work. If you define a Class A with a member x and you have a list<A> of them, you want the iterator i-> to give you the x. No, really, it's the cat's meow of content assist - interpreting the i to find out it's a iterator template instantiated on A then resolving A to find out what it's members are. The unfortunate thing is that this used to work up until CDT 4 when we moved content assist to use the new index framework instead of always doing a complete parse. It's much faster now, but we don't have all the necessary information about templates in the index yet.

And, of course, with our active CDT community, people are starting to raise bugs on various things that aren't working with templates. For C++ developers, the Standard Template Library is an awesome tool. It greatly simplifies the code you have to write to use generic collection classes and it does it with all the type-safety and performance that C++ is famous for. I guess I shouldn't be surprised that people expect the CDT to work with them as well as it does regular C++ classes.

But, under the hood, this is an incredibly complex beast. When we got it working first in CDT 3.0, despite the somewhat slow performance, I was proud of the team that we were able to make something like this work. It was a lot of effort by some really smart people, who unfortunately have moved onto other projects. And luckily we have a new set of really smart people who will continue the effort as we move to the new index. So we will get it working again.

It is very interesting to see, though, the expectations that IDE users have now. It certainly has come a long way. Once we get the template thing done, our next biggest demand is C/C++ refactoring and we have some more smart people lined up to look at that. If you were to start a new C/C++ IDE today, it would be a daunting task to meet these expectations. I'm glad we have the history and the team we have now on the CDT so that we have a chance.

Assert.isTrue(false) never works

In case you were wondering, this pretty much throws an exception every time. Although, I one of my first mentors often tried to blame stray electrons on some bugs so, I guess if he was right, there could be times when this does work. But I wouldn't put money on it.

I ran across this particular piece of code when it showed up in a bug report recently. It came at the end of a if-then-else chain as the else that the author didn't expect to ever run. Well, this one unfortunate user found some way to make it run. Maybe it was a stray electron, or maybe it was just a corrupt preference store. We'll have to see.

But this did bring up another of my mantras for software development. Don't throw an exception that you don't plan on catching. Sometime we use exceptions as a crutch. If we get to some point where we can't figure out how to continue, we just throw an exception and don't need to worry about it any more. At least until the exception bubbles up to the UI and the poor user has to deal with it.

It's a tough job to put in all the possible error handling for a given situation. If you're building a safety critical system, you get a whole boat load of funding to pay for that effort. But when you're building a software development tool, you often feel that you don't have the time to work on code that you don't think will ever run. But it really does pay off in the end. When you have hundreds of thousands of users of your software, there's a pretty good chance one of them will run into a stray electron or two.

Trust Matters

I just finished reading this article on a recent failure with the International Space Station. Something caused all three Russian-built computers on the ISS to fail at once while the Space Shuttle was docked and the Americans were installing a solar panel. I love reading post-mortems like this and wish we did more of them in the software industry. You certainly learn a lot about what can go wrong on a project.

In this case, they found the problem to be with condensation causing corrosion of power lines and an eventual short. That caused an unfortunate chain events that activated an unfortunate feature, a single command that would turn off all three computers, nullifying the triple redundancy. Once that was identified it was easily and "creatively" corrected and everything is fine now.

But the thing I got most out of the article is that one of the bigger problems was the original incorrect assumptions made by the team that caused the determination of the real problem to take longer. Being from different countries, they team started out by blaming each other for the failure instead of taking a non-partisan approach and trying to solve the real problem.

This is something I try to do as much as I can, which is unfortunately not often enough some times. If there's a problem, start with the assumption that I screwed something up. None of us are perfect and that group starts with me. That helps me take an honest look at the situation and if it is my fault, we can find it quicker. If not, then the fact that I'm not trying to hide from the problem should help there too.

When you are involved in an open source project with contributors from different companies, especially when the companies are competitors, you can end up in the same scenario. It is hard to build trust in those situations, and when your building something complex and run into problems, that trust becomes very important. To be successful, you need to trust that the other people are doing a great job. If you fall too quickly into the "blame game", you'll only get the project, and yourself into deeper trouble.

ESE 2007, another great Summit in the books

Well ESE is over for another year. I found this one much better for me than the last. This is a real tribute to the growing strength of the CDT community in Europe and the effort people made to come here and introduce themselves. I had a lot of fun with them and my peers in the Eclipse community. It really reminds me why we make this effort to contribute where we can.

Here are a few more points I took home from the week:

• There were a lot more people from the embedded space at ESE this year than last. So many of the vendors in this space see the value the CDT has provided them. Hopefully this will also lead to continued growth in our contributions :)


• The guys from BMW CarIT gave a great presentation on how they are using the CDT in their tool chains. They have a really cool target system comprising of 70 processors working together and are trying to get them all to do more work. It's a great real life example of using the CDT for complex embedded systems. Hopefully they'll post their slides to the ESE pages soon.


• The BMW guys also let out a secret that I'm glad got out. Building an integration to a compiler with the CDT for managed build is really easy. A day's work tops. I wouldn't mind seeing a concerted effort to co-ordinate these, maybe make a public repository of them. That'll also push some CDT vendors to add more to their products than just a managed build plug-in.


• The BMW guys and others I talked to also showed me that there really are end users of the CDT that also write plug-ins to do the specialized tasks that they do. One of them even said this was getting to be a problem since there are getting to be a lot of them and is getting hard to manage version line ups. This is one of the great promises of Eclipse and part of what is supposed to make our Eclipse-based products so good. I'm excited to finally see it really happen.


• Being without wireless LAN for almost all of the conference was really inconvenient and left me to writing blog entries late at night. But it did help me pay attention more to the speakers, which I guess is really a good thing. But lets hope it doesn't happen again :).

Well I should get to bed so that I can get to the airport at a good time tomorrow. Thanks to everyone I met here at Ludwigsburg for making me feel welcome and I hope to see you all at another Eclipse event soon.

CDT day at ESE

Now that I get to one of these things, i.e. Eclipse Summit Europe, I really get why I need to be here. I've met a number of people that were interested in the CDT who were very glad to meet me. I got some really good questions from many of them who are extending the CDT for their own build and debug tool chains. CDT in Europe is very much alive and thriving and it was a great opportunity for me to see what all was going on and to help where I could.

The day got started very late as my talk wasn't until 5 p.m. It was great to see around 30 or 40 people attend, more than last year. We then followed it up with a BOF late in the evening where we had a great discussion from a number of different people using the CDT on areas where it could improve and where thing are working better than expected.

I really got a feel for the diversity of the people interested in the CDT as well. I had a number of silicon vendors ask me questions on how to integrate their specialized toolchains with the CDT. This is definitely a hot spot with the CDT and something I didn't really anticipate. I'm much more used to RTOS vendors working with the CDT, but these bare metal guys are doing some pretty cool stuff.

I also learned that there not one, but two groups looking at C/C++ refactoring for the CDT. It's a very tough area and our current AST implementation presents a lot of challenges for them, but give the number of people who showed interested in having that functionality at the summit, it could be the next great step for the CDT. I hope things work out there.

The day closed off with a nice social closing with a number of the Eclipse Foundation staff. They are a very cool bunch of folk that have a lot of passion for what they do and in growing the Eclipse community in all directions. As Mike presented in his opening, he wants the Foundation to be around for 50 years doing something interesting. If they pass on their passion down the line, I'm sure this can be achieved. As long as they don't get too many German bartenders mad for bringing in Burger King even though the restaurant was closed. Oops, I guess what happens in Germany should stay in Germany, oh well...

Hello from Ludwigsburg!

I'm here in Ludwigsburg, Germany already a day into my Eclipse Summit Europe experience. I'm glad I'm here. Looking at the CDT contributor community, I'd say we get half of our contributions from developers based in Europe. And given the number of people that have come up and introduced themselves to me, there is a lot of CDT interest here and it should be a busy week for me.

I'm watching Erich Gamma's talk as I type this. He's giving a very refreshing look at the history of Eclipse and how we got here. It's really a tribute to the vision from him and the gang at OTI that an effective development organization could form in the open source community. We've had our growing pains, but a number of projects are now thriving in this environment, especially IMHO the CDT.

I have my talk on CDT 4.0 later today and tonight we have a CDT BOF. I look forward to seeing who will be at the BOF and if you're here, please feel free to stop me and introduce yourself. I'm finding my picture on my blog is making easy for people to spot me :)

Multi-core everywhere

I was just reading about ARM's latest announcement for their new A9 processor core. I'm a bit of a fan of ARM and not just because they have a committer on the CDT :). They have a very interesting strategy when it comes to their market and rely fairly heavily on open source tools to enable software developers to use their small low power cores.

What struck me about the A9 core is that it comes with built-in support for multi-core configurations of up to four cores on a single System-on-Chip (SOC). One of the concerns I have heard of ARM in the past is the performance of their cores, particularly their earlier versions. Going multi-core makes a lot of sense to help alleviate that without too much of a power overhead. And it opens up a new class of software application that can take advantage of it.

But once again, the spectre of doing multi-threaded development is starting to take hold in another sector of the industry. Are embedded tools ready to handle this? Even more important, are embedded developers ready to handle it. This is a recurring theme in my blogs and I still haven't found the answer.

My gut tells me the best way for programmers to deal with the complexity of multi-threaded development is to introduce a new programming paradigm that simplifies the thought process and puts doing multiple things at the same time as a first class citizen. This is what we did when programs became gigantic and the old functional approach didn't scale. Objects were our saviour.

The era of multi-core brings new challenges and I wonder out loud, is there a better paradigm to help us deal take advantage of all power it brings while allowing C and C++ developers to leverage their skills at embedded development? Is OpenMP the answer? Or does it go far enough as a new paradigm? Something to look into.

Hey-lo, the software industry on center stage

I can't really get too far away from it without talking a little about Halo 3. I'm pretty sure most of you weren't up watching live coverage of the Halo 3 launch last week for 4 1/2 hours on cable TV. My son Alex made sure I did. He was so excited he could hardly stand it. And as if by co-incidence, the next day our new XBOX 360 Elite and our copy of Halo 3 Legendary Edition, ordered from two different sources, arrived with in hours of each other. He was in heaven and we've been a Halo house since.

I was fascinated by it all, and not because of my fascination with Master Chief, whose helmet is on display in our family room (for now). It wasn't partly because I couldn't believe there would be 4 1/2 hours of live TV coverage of a video game launch (what the heck was that), or that people would be lined up for hours on end waiting for a copy when they could probably walk in later that afternoon and get one in 10 minutes.

No, it was because when you tear away the layers of marketing and packaging and 3D models and animation, you had a pretty sophisticated chunk of software. Whether it was coded in C++ or C#, I'm not sure. But it is code and the developers could have easily used the CDT to build it, although I'm pretty sure they used Visual Studio ;).

It's hard to imagine what the programmers at Bungie were thinking that day. When you're busy mucking with class definitions and for loops and trying out everything you can to squeeze out every bit of performance out of your latest algorithm, I'm sure you don't consider that you'd have thousands of people camping out overnight waiting to get a copy. Hell, you're probably sitting there sick that someone will run into some latent bug in that mess you made.

But there is no doubting how cool it is to be in this industry and to see the affects that software has on everyday people's lives. Most of us get into it because we love the challenge of making computers do stuff. But whether you're building the latest block buster video game, or the next generation C/C++ IDE, you are making a difference in the world.

Another CDT Summit in the Books

By the end of the three days, it really hit home why we go through the effort of organizing and traveling to the CDT Fall Contributors Summit. While it got off to a slow start, by the last two days we were busy getting deep technically and on Thursday afternoon even browsing through source code to see how to implement some of the new features. That's something that is pretty hard to do if you don't have 7 or 8 guys huddled around the projector screen. And with the CDT, those 7 or 8 people come from different continents.

Aside from the Debug features I mentioned in my previous post, we got into a few key areas. The team at IBM Toronto are working on new parser frameworks that should make it much easier for the CDT to handle language variants. In CDT 4.0, we released support for Unified Parallel C (UPC) that was built as an extension to a new C99 parser. They are also looking at techniques for making the indexer even faster. I think this will be great for the C environment. I still am worried about how this will scale into the C++ world and the crazy template libraries people create and use.

We also talked a bit about remote development and how we could support it with the CDT. This is the scenario where the source code, build, and debug all happen on monster remote machines while the developer accesses them from a workstation. I think we're still pretty cautious about making sure we don't do too much damage to the CDT architecture to make this happen. But one key feature I think we're all mainly in agreement on is to make sure the CDT works while all file access occurs through the Eclipse File System (EFS). I am also hoping use that to add support for Visual Studio style Add File/Exclude File so that users coming from that environment, which a lot of CDT users do, can continue to manage their projects somewhat independent of the file system.

At the end, it looks like we have a pretty good plan for Ganymede, the newly numbered CDT 5.0. There aren't a lot of big architectural changes like we've had in the past. That will definitely go a long way towards bringing the CDT to a new level of maturity where we have documented and trustworthy APIs and can focus more on quality, cleaning up the Bugzilla backlog and adding more automated tests.

It really felt to me that the CDT has grown up a lot in the last year, and that's a big thanks to our contributor community and the great collection of committers that have been involved with the CDT. Our team has really stabilized and everyone knows each other now and we really do work together well. And, of course, there's always room for more...

CDT Summit Half-way Point

Well, we're half done the CDT summit. We started with some general discussion on CDT project management and planning for Ganymede. We've picked 5.0 for the CDT version number. That comes with the commitment to finally manage our APIs so that the community can rely on them and read documentation about them.

We've had a long discussion on various aspects of debugging. The good news is that the Debug Services Framework that the Device Debugging project is working on will become much more tightly integrated with the CDT. There's been some good work on the GDB/MI integration with DSF and we'll have an interesting decision to make around the February timeframe whether to make this the default gdb integration mechanism for the CDT packages at Eclipse.org.

Another interesting requirement we are hearing a lot is the need to reduce the dependency that Eclipse has on Projects and Resources. Features like project-less debugging are important to users in both embedded and desktop communities. The focus is on the activity, i.e debugging, and less on working with projects and build settings. The debugger drives what files you are working with, not the user. Along with the need to support Visual Studio's ability to add to and remove files from projects without changing the underlying operating system in an easy manner are very important.

So while we really don't have any big new features coming, other than refactoring which we haven't heard to much about yet and the people working on it unfortunately weren't able to make it. We are becoming more focused on making users feel more comfortable with the CDT. And that includes users who are coming from the emacs/vi world as well as other IDEs. That'll be a good challenge.

CDT Summit Eve

Twas the night before the CDT summit and all through the house not a creature was stirring, except for my son waiting for the Halo 3 launch. Luckily I pre-ordered and it'll be arriving by mail so I don't have to stay out all night. Which is good since the CDT summit starts tomorrow and it looks to be three days of hard work while we plan for the next release of the CDT next summer for Ganymede.

Every summit seems to have a different atmosphere and I have no idea how this one will go. We've gone from being desperate for contributions two years ago to a whole pile of features landing at once last year. I think this year will be the search for maturity, at least I hope so. We're five years into it and we still don't have firm (or as my good friend Michael Scharf says, "crisp") APIs. We need to get this right soon or we'll start missing the window where the current mess is acceptable.

We also need to take a good look at everything to do with Debug. Little has changed here in five years either and we're still dealing with a paradigm, while fine for Java developers, is foreign to C/C++ developers. We had a good code camp today with the Device Debug folk and the good news is that we're all feeling the pain and have the desire to do something about it.

We also need to work on other workflows as well that are driving our users mad (and more importantly our customers). The whole IResource system has never worked the way C/C++ users want, especially those who've used other IDEs. All they want is to be able to add files to projects from anywhere and to exclude files under project folders. This is getting to be very high in my list of complaints I've been getting recently. I have some ideas on this and we'll see if they can fly.

It should be a good week, and I think were going to walk out of it with a lot of work items. Interestingly, the toughest ones will require changes in the Eclipse Platform and we know how challenging that can be, and not necessarily for technical reasons...

Take the high road

Just a hint. If you are a key player in a project promoting open source tools for native Windows, stop calling them Microsnot and stop calling the API Woe32. You're really just hurting your project's credibility especially when the tools are in such need of some.

Anyways. Just a knee jerk reaction to watching one of the "real" open source project mailing lists. I hear about the rawness that people on these lists can show but to experience it first hand, really makes me wonder what they are trying to prove. Yeah they are hard core techies and for a lot of these projects that's what's needed to be as good as they are. Maybe I've been in the corporate world too long, but it really turns me off. Especially when I'm worried whether the project will survive and am thinking of helping out. It's certainly something that's not acceptable on the Eclipse mailing lists I peruse.

As much as people bash Microsoft and as much as I love Linux and other alternative platforms (including QNX Neutrino ;), I can't join in the bashing. What's the point? What are you hoping to achieve. Microsoft changed this industry. The vast majority of developers I know are running Windows as their main development platform. That wasn't true 10 years ago when Solaris (or rather SunOS) and Unix in general ruled the shops I worked at. Give Microsoft the credit their due. We all know open source is a better development model for core technologies. We don't need to rub their noses in it.

BTW, I'm sitting outside on a nice 21 degree Celsius evening here in the outskirts of Ottawa enjoying the fire on my deck with my favorite beverage in hand listening to a Trance Internet radio station and surfing the net on my laptop via my wireless router after spending a nice evening with my wife and sons. Life can't better than that for this techno geek who always seeks to take the high road...

Microsoft's everywhere

Someone asked on the MinGW-users mailing list about editors that they could use with the MinGW tools. People do have a few choices and, of course, I offered up Wascana as an option. I'm not sure if Microsoft was really answering the question, though ;)

> Hello...
>  
> I'm thinking in create an editor of C/C++ code
> Integrated to MinGW.
>  

There's also Wascana based on the Eclipse CDT.

    http://wascana.sourceforge.net

Doug.

------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
------------------------------------------------------

Defy all challenges? That's my moto :)

Time for an Eclipse Corp?

I'm not sure why, but Mozilla has been floating around my world a lot in the last few days. First was Ian's conjecture that Eclipse should sometimes be more like Mozilla. That led me to take a look at what the fuss was about where it finally hit me what Mozilla.com was. It's actually a real company that funds development of Firefox with revenue generated by Firefox's search engine integrations. Apparently they get a ton of money, well $50M+ annually, to spend that way.

Now today, I read that Mozilla is going to try out that formula with Thunderbird. Firefox was probably the right thing at the right time. I'm not sure Thurderbird is, although I'm thinking of tossing Yahoo's slow mail, I mean web mail, interface and switching to T-bird for my home mail. Although, I still love Outlook (especially after a couple years of not using Outlook ;) for my work e-mail. But the idea of funding Thunderbird development to improve it's chances in the market is an intriguing idea.

This is something I've been thinking about in the last couple of years that would be good for Eclipse. The Platform versus IDE wars flame up once in a while and the underpinnings of the Eclipse Foundation and the way most Eclipse projects gets staffed really does force the Open Source version of Eclipse to be a platform, and not necessarily the technically best IDE in the market. And, although we don't run up to them much in the C/C++ space, Netbeans is apparently jumping by leaps and bounds and is starting to be recognized as the more user friendly IDE.

So I wonder out loud. Could a not-for-profit Eclipse Corp. fund an independent collection of developers that could focus on making Eclipse both a great IDE and a great Platform while still providing value for the Board members who would most likely need to fund this venture, at least at the beginning? What would the scope of this corporation be? It couldn't fund every Eclipse project since not all Board members get value out of all of the projects. But there may be a logical place to start and grow as more funding became available. Or would this create a poisonous community of have's and have not's. Interesting to wonder about anyway...

SCO loses, innocense already lost

You know a year ago or two or three, SCO filling for bankruptcy would have been a huge headline. Nothing has shaken the open source world more than SCO's lawsuit on IBM for allegedly stealing their intellectual property and putting it into Linux. Open source went from the innocence of sharing to a mine field of hurt over night. Communities like Eclipse understand the balance between commercial and open. Many do not, and SCO certainly did not. Open source was a threat and instead of finding a way to leverage it for their own good, they chose to attack.

But in a mess of technicalities, it ends up they didn't have a leg to stand on in the first place. The apparent good heart of Novell, who apparently actually owns the legs, saved the day. Now we can rest and look forward to golden times. Or can we?

I actually think we got lucky. If SCO had been successful, what would that have meant to corporations contributing to and relying on open source software for their products. We certainly got a glimpse of that world as corporate legal teams maneuvered to protect their corporations' interests. Pretty much all of the legal safety mechanisms in place at Eclipse is there for that reason. It's frustrating at times, but they're there for good reason.

There is still a lot of fear over the use of open source and I don't think SCO filing for Chapter 11 is going to change that. New "villains" are on the horizon. Many will stay on the horizon visible enough to make people think. But I don't think they'll go away.

SCO has changed us forever. And maybe we'll look back and say it was a good thing. But you have to wonder what the world would have been like if everyone embraced open source for the mutual good that it can be. But then, maybe it would still have looked a lot like Eclipse anyway...

Wascana article and a Windows focus

There's a good article on the Every Flavour Beans blog about Wascana. It gives a pretty accurate overview of what I'm trying to achieve and some pretty good suggestions. This is then followed by some screenshots showing what Wascana is all about. I definitely appreciate the exposure and the suggestions.

One of the suggestions which I'm running with is to refocus Wascana back on Windows development. I haven't received much positive feedback on my plan to provide the same environment for Linux and Mac. And I need to honestly evaluate what I can do with the limited time I have available to spend on it. Windows has the most need from both the CDT's perspective and users who want to use the CDT there.

The Linux distros have been doing a great job of including the CDT and necessary library development packages that I don't think we need extra help for that, other than to test it out and make sure these packages work. And I would really need to spend time on a Mac to understand what's needed there, but that isn't going to happen any time soon. We can always revisit these platforms if people step up and want to help get Wascana working there.

This should also give me a chance to get deeper into the MinGW toolchain. It's screaming for a 4.x gcc and a debugger that can understand both Windows and GCC world. I'm not sure how I can help there yet but I should spend some time figuring that out. But given the feedback that I'm getting on Wascana, we are heading down the right path with it.

High tech isn't always the answer

I have two sons, one of whom, Alex, is Autistic. That presents its own challenges in our life but my wife and I are getting to be seasoned veterans in that battle now that he's 14, and our "typical" 13 year old son is getting that teenager attitude which is a whole ball of wax on it's own.

At any rate, Alex has an obsession with a few things like most Autistic kids do and I appreciate most of them. Two of them are video games and Star Wars. And, of course, that means we have pretty much every Star Wars video game that's out there. The latest addition was one he found on eBay Canada called Star Wars Dark Forces. I wasn't sure what it was, but given the $6.95 price, I was sure it was pretty old. But it was cheap enough, so I ordered it for him.

Well, when it arrived I looked at the CD and found it was copyright 1994. Will this thing even work on our XP box at home? Well after I found and installed a Sound Blaster emulator, it runs like a charm. And you know what? He loves it! It looks like DOOM II and probably uses the same engine from id Software. It's pretty well done for 1994 but cheesy as all hell.

But I felt a lesson in all this. We often work hard in the software industry to pile features into our boxes and provide the latest bleeding edge of technology. But we often lose site of what this hole industry is about. It's about the people who use this stuff. If they're not happy with the end product, they we just wasted a lot of our time and money. And probably a lot of theirs.

And I guess that's what's led me in the last little while with the CDT. I don't work on the indexer much any more. I'm glad that we have a few other guys looking at it. And that's given me more time to focus on cleaning up the user experience. Because, no matter how fancy our stuff is under the hood, if people feel that the CDT is too hard to use, they won't even get far enough to try out the fancy stuff. And sometimes, at least in my house, 1994 technology is plenty fancy enough :).

A new era for QNX

So how to you take a great technology and bring it to a wider audience? For those of us working on open source projects, we know what to do. You create a community for it. And that's what QNX is doing starting today with the introduction of the Foundry27 portal.

Now lets get something straight from the start. This isn't open source. We've taken great pains to make sure we didn't mislead anyone into thinking that it is (unfortunately some members of the press haven't). But it does give everyone access to the source code and to the developers via forums. And, as long as you are using it for non-commercial use, you have free access to the tools and the SDK to play with it. We are even working on ways for people to contribute any of their cool work through the portal to others that may be interested. But, commercial users still have to pay for development seats and run-time royalties.

The idea is really to lower the barriers that people feel when they approach commercial software. Cut through the sales people and lawyers and just let me play with your stuff to see if I like it. This is something that many companies, even Microsoft, are trying to do to woo developers. QNX is going pretty far though by giving a public face to its staff, which is a pretty major culture change that I remember going through when I started working on the CDT. But we're intent on making sure developers get what they need and feel comfortable in this new community.

As with all communities, this one will need to be nurtured and it'll take a bit of time to work out some of the kinks just a Eclipse did in the early days. But we have learned from that experience and there is a lot more software out there to support something like this. But the focus really is on people as it should be with communities and this is a much friendler face on some really good technology.

Hibachi, a lesson in diversity

I've always been interested in Ada. Unfortunately, I've never had the opportunity to work on a project that required me to use it. But from studying it over the years, I can immediately appreciate it's strong type system, inherent support for multi-tasking, and focus on helping the programmer write quality systems. I can think of many projects that would benefit from Ada, especially in the safety critical embedded systems arena.

As part of my vision for the CDT (or dream, I guess) has always been to support multiple programming languages and Ada was one I wanted to see. But with a lot of ideas I have for the CDT, I neither had the time or real community support for it. So when Tom Grosman from Aonix approached me proposing they contribute their ADT code to Eclipse, I jumped at the chance to help.

And I'm glad I did. The Hibachi project is the result of Tom's work and is nearing it's creation review. I have been trilled at how Tom had gone about talking to his competitors and other vendors and interested parties and built up a strong community, even before it got started. They have a firm plan that immediately focuses on meeting objectives that would enable all vendors to get value out of Hibachi. This will then promote additional contributions to make Hibachi the best Ada IDE in the business. I can't wait to see them in action.

There are a lot of things at play here that is a trend I've seen with successful Eclipse projects. In many ways the forces are there to make it happen. Customers are demanding high quality IDEs based on Eclipse, the free community would love to see Eclipse support for their favorite tools, vendors would love to provide it all but to do a good job of it, they really need to work together and share the burden. If you can harness all this energy and make your project a friendly place to participate, then I think you have the clear formula for success.