Does "Eclipse Europa Needs Some Polishing"?

I ran across this review of Eclipse Europa on eWeek that came out yesterday. It confirms almost every concern and hope that I had for the Europa C/C++ package that people have been downloading in droves from eclipse.org. And it was really interesting that this guy is a former Windows C++ developer who is very familiar with Visual Studio who is now doing Mobile development, the exact scenario that we see a lot of and is the biggest growth area for Eclipse on the C/C++ side.

The first thing that hit me was his summary: "Eclipse Europa is a solid IDE, but it could use more refined packaging for the Windows platform". If you're a regular reader of my blog, what more can I say.

The sore points that he ran into really home for me. His biggest complaint was the install. He had expected the C/C++ IDE package to include the gcc compiler. There are still way too many steps to getting this package to be useful for C++ developers. "Nothing leaves a more sour taste in a Windows user's mouth than an application not working properly, or requiring additional manual configurations, after clicking finish on the installation wizard's final panel."

He also had trouble dealing with the Eclipse workspace paradigm. Visual Studio is much more flexible about what files are included/excluded from a project. This is an area we really need to deal with to make these guys comfortable.

He had some good things to say too, though, and he really showed why I think Eclipse will be attractive to Windows developers once we clean things up. The CVS integration is unbeatable. He loved the CDT editor and navigation features including CDT's new Call Hierarchy view. It's these features that really bring the CDT into the mainstream.

One thing to notice, though, is that the title of the article seems to address all of Europa, at least that's what readers will see first. That's why we really need to be careful when we present Eclipse as an IDE. It isn't an IDE accross the board (not to open that debate again). But users see the word IDE and have pretty high expectations. And when it falls short, it looks bad on everyone.

The Need for Diversity

I'm in shock. Amongst other emotions that I'm still trying to figure out.

I came into work this morning and checked my e-mail to find that Danny Smith from the MinGW project had sent an e-mail "Bye" to the mingw users and developers mailing list. Bye? What do you mean bye?! Just as I was getting excited about the future of MinGW with it's spanking new modern compiler, the only guy working on it has quit. I don't know what to think. Is it a bad joke? Has someone broke into his e-mail account and sent the message. The responses from the other MinGW developers leads me to believe not as they politely wished him well in his future endeavors as well as expressing their fear for the future of the project.

And fear we should. I was always concerned over the lack of progress with the MinGW compilers. The seemed stuck on 3.4.2 as the official release for a long time (and now, probably even longer). Danny had come to the rescue and offered hope that the wait was over and we'd soon be able to enjoy all the great improvements to gcc in recent years. But now it appears someone else will need to take on this challenge. And it appears to be a big challenge as there were a number of bug reports flowing in (one of which was mine) and I was getting worried that Danny would get overwhelmed.

The timing of this is interesting, especially after my blog entry yesterday. But I've also been in a number of discussions in Eclipse lately over the need for diversity for projects to succeed. If contributors to a project all come from one company, what happens to that project when the company needs those resources elsewhere. The CDT was able to survive such an incident because we had contributors from many organizations who stepped up to fill in the holes (and I still can't thank them enough :). But there are projects at Eclipse who haven't worked hard enough to make sure they diversify like this and it is something to worry about if you rely on such projects.

And that's the position I find myself in. I was relying on MinGW's 4.2 compiler to make Wascana a super appealing environment for Windows development, even for commercial use. Now, I'm not sure what I'll do. Maybe it's time to apply some focus again on the Windows SDK compiler and debugger integrations. Although, unless by some miracle Microsoft let's me redistribute their SDK, it violates Wascana's primary mission as a simple to install complete IDE. And I doubt I would have ample time to contribute to MinGW and I don't really have the expertise anyway. And I have QNX work piling up. And CDT stuff to prepare for. Like I said, I'm still trying to figure this whole thing out...

The True Meaning of Wascana

While the progress on Wascana has been slower than I may have liked, it is progressing. And I've been very pleased with the positive feedback I've received on it. Almost everyone I've heard from says it's the right solution at the right time. A complete CDT IDE is hard for people to set up themselves, especially for noobs, and that is Wascana's primary mission in life, to make this easier.

But there is another reason for Wascana, and one I use to justify spending some of my work time on it. I've often seen marketing staff from various vendors promote their Eclipse-based tools as, well, Eclipse-based tools. Now in the Java space, that definitely means something. But in the embedded world, it doesn't have the same punch. It's almost like customers are saying "yeah, so?".

This has been the main driver behind my work on improving the CDT for the "grassroots" segment of our industry. These are the guys just getting into programming, or are doing it as a hobby, or people working in a start-up. People who don't have a lot of money to spend on expensive tooling but who would benefit from a good free IDE. And while there are good IDEs out there for free, there is so much more upside to Eclipse.

But I had reached a road block in my pursuit of supporting the grassroots. We had reached the point that their biggest hurdle was setting up the CDT with a good compiler and debugger and set of run-time libraries. This is the stuff that Microsoft's Visual C++ has always been good at. And if you look around, thanks mainly to the growth of Linux, there is getting to be a pretty good set of open source tools and libraries.

And I guess that's why the time is right for Wascana. I think we can build a pretty good free open source IDE from all this, and the feedback I've received is that it will be very popular. And if that becomes true, then commercial products based on Eclipse will benefit from the extra visibility and the investment will have be worth it. So while I've had to pursue Wascana out on SourceForge due to licensing and IP requirements on Eclipse projects, I consider Wascana to be an important part of the CDT, both for the desktop developers who want a good open source IDE based on it, and for commercial vendors who want their CDT-based IDEs to be successful.

Too clever for me...

Brian Kernighan, of Kernighan and Richie fame, or K&R (if you did't know, Richie created the C language and Kernighan helped him right the book on it). At any rate, Brian has this famous quote which I can't seem to find the root source but I found it quoted many times:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

And that perfectly explains my frustration in the last couple of weeks trying to understand two very clever code bases. Not only is debugging twice as hard, but being a new guy trying to understand the code is at least twice as hard. Hmm, maybe here's a new quote for people:

"Learning code is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, the only one who'll be able to understand it."

Unless the person learning the code is twice as smart as you. Or something... At any rate, I'm not twice as smart as most people so I get to struggle trying to figure this stuff out.

BTW, as I was searching around for the source of the Brian's quote, I ran across this interesting interview with him that gives a glimpse of the human side of Unix and C as they were created at Bell Labs many years ago now.

Lunar Eclipse filling my Inbox

Hey gang, there's a lunar eclipse Tuesday beginning at 3:51 CDT. I personally can't wait until it's over so that my google alert on "eclipse cdt" can stop reporting this thing...

From Old to New

I was hunting and pecking around looking to see what is happening in the industry as I do probably too regularly (I really got to get some code done...). At any rate, I ran across some slide shows that ZDNet were showing on old computers. I still remember the buzz and excitement us young geeks had as computers hit our neighbourhood streets. I don't think I'll ever see something like it again.

Anyway, one of the pictures was of the first computer I ever typed a program into. It was an HP-85 (click here for the real site that ZDNet borrows the pictures from) that my best friend's dad used at his work for the Fisheries Department at Government of Manitoba office in town. And it was where it all started for me and it was cool to see the picture. Yeah the thing had a tiny screen and a proprietary CPU, but it did speak BASIC and I remember being excited trying to figure it out.

Of course that is contrast to the latest computer, or at least processor, that caught my eye, Tilera's TILE64, a monster 64-core machine organized as a System-on-Chip (SoC, peripheral interfaces included). It especially sparked my interest because of the market it's trying to address, embedded systems for video and advanced networking. Intel can go on about their server and desktop monster multi-core machines, but there is a real need in the embedded space for this technology too. I can imagine some pretty wicked things that embedded devices could do with automation and robotics and such with this kind of horse power.

But as with all monster multi-core machines coming out, I still think we need a better way to program them so that we don't get lost in the complexity of getting our programs to do multiple things at exactly the same time. Hell, I spent a good part of the last couple of days solving a deadlock issue in the CDT, and that was just two threads colliding...

A lesson in scalability

I just read the Skype blog where a Skypian describes (well glossed over, but we get the gist) what happened with their two day outage last week. I don't use Skype very much but I know a few people that use it for their work and were at least inconvenienced by it. I read the report with somewhat the same reasoning that one watches Nascar, to see the big wreck and find out how it happened. But reading these things helps you think about how you could avoid such wrecks in your day job, so it's useful reading.

The story goes that 30 million computers around the world running Skype all downloaded a Windows Update and did a restart, all at the same time. I always wondered how Microsoft's servers could keep up with that, but I guess they did very well. But when those 30 million Skype users all tried to log into Skype after their restart all at the same time, bad things started to happen and everyone got booted off the system.

Now, being a software professional, it's not clear to me how this outage could last two days. Normally, you get a timeout if the server is busy and after some amount of time you retry. You'd think there would be a variability in the timeout so that everyone doesn't retry all at once, but maybe that was the flaw they found.

But the lesson of the day is to always consider the "impossible" since sooner or later, it may not be impossible. We run into that with the CDT. We find users who take the CDT and import any old project they may have and expect the CDT's parsers to find everything. In a lot of cases, we're fine, but we definitely don't take into consideration all possible scenarios. And I think that will be the next phase of CDT's lifecycle, to reach that maturity where our feature set does work on more and more projects and we can have more and more happy users added to our community. Openning our minds to the impossible will help us get there.

Just when you needed a Boost

I've been aware of the Boost C++ library for quite a while, but in the context I had to deal with it, it was painful. The Boost library is a collection of C++ templates intended as a trial ground for additions to the Standard Template Library that is part of the C++ standard. Some of them according to Bjarne, have made it into the next standard C++0x. But they stretch C++ templates to the limits, and as such, stretched the CDT's C++ parser to it's limits and broke it. In the early days of the CDT, we eventually just skipped it.

But lately, Markus on the CDT team has been testing his indexer work with Boost, and I've had a number of requests from people to include it in Wascana. So I decided to take a fresh new look at it.

Now I was expecting some simple container templates and utilities and such. And there were things that are much needed like a threads package for multi-threading your app and a regular expression utility class.

But I was amazed at some of the big constructs they have there. The first thing I ran into is a complete lexer/parser subsystem including a preprocessor. With that, it wouldn't take to long to build parsers in C++, and maybe even a C++ parser.

As well, there is a Statechart engine. This is something I've dealt with a lot in my past and it was cool to see a solution that involved templates and States as objects and some of the neat tricks it used to implement action code. Whether it scales to real size state machines, I'd have to dig deeper to see.

I've always been amazed at how powerful C++ templates can be and how the compilers can take all this template code and specializations and such and optimize it down to some pretty efficient code that you probably would have written by hand. But with templates, you work at a higher level of abstraction, meaning higher productivity. Boost gives you some pretty powerful abstractions. We'll see how easy they are to use in practice.

Debugging the Debugger

I've been trying out MinGW's new 4.2.1 gcc compilers. As I mentioned previously, they're experimental. But I've gotten really good feedback from people that moving to 4.2.1 is a great move and will help make MinGW a serious choice for developers.

They actually have two variants of gcc that they're working on. One of them supports exception handling based on the debug information gathered using the DWARF standard. It's apparently much more efficient than the default one based on setjmp/longjmp. I'm not sure what that all means, but my take is that the dwarf version is better.

At any rate, I had a problem using the dwarf version that I didn't have using the default (sjlj) version. If I specify the path to a file using Windows traditional back slashes, e.g. ..\main.cpp, gdb got confused and I couldn't set a breakpoint on a line. And, unfortunately, CDT's builder builds files this way and I my breakpoints failed to get set.

So, I downloaded the source to MinGW's gdb, configure and built it and set up a debug session, all within the CDT (this worked since configure generates forward slashes). I was able to set breakpoints, look at the dwarf symbol data that gdb was trying to use and found where the line number info was missing. And with that information, I was able to generate a hopefully helpful bug report that the MinGW developers can take, or if I find the time, I can try out different solutions. The only trouble I had was making sure which gdb was which :).

At any rate, this brought home again why I love using IDEs for development (which gave me a great intro for an article I'm writing). The productivity of using a debug environment that provides point and click visualization of debug information has to be at least ten-fold over using command line debuggers, and maybe a hundred-fold over using printfs. Once you start using it, you'll never go back.

The Master Speaks, Bjarne's vision of the future

I'm not sure whether you'd call him a Jedi master, or a Dark Lord. I guess that depends on your opinion of C++. To me, I've always affectionately called him Barney (which I'm sure he'd hate), and, of course, I treasure my copy of "The C++ Programming Language", the "Barney Book".

Bjarne Stroustrup, the inventor of C++, recently gave a rare public talk at the University of Waterloo, Canada's top university for computer science. The topic of the talk is the new version of C++ called currently C++0x (he mentions that if it slides into 2010, they may just call it C++0xa, and yes he has a pretty good sense of humour). But he also talked a lot about the past and present of C++. You can download the talk here but be warned it's huge and you may want to use the bittorent.

I'm a long term fan of C++ since I used it for my grad studies work back in 1989. It was a no brainer to me that it became so popular. Bjarne was able to bring object-oriented constructs and generics to C programmers without compromising on performance. And C++0x has performance square in it sites as it works to clean up some of the complexities of the language and bring new concepts that desperately need standardization like threads.

He also had some great examples why performance is criticial, even in today's world of fast computers with lots of memory. Embedded systems have always had performance as high priority, and in the world of mobile, high performance also means using less power, which makes power consumption a performance issue. Also, if your application uses less memory and is faster, that leaves more resources available to add more functionality and making the system even more useful.

So while the world still seems to be jumping on the Java/C# or Ruby/PHP/Python bandwagons, C++ still and always will have it's place. 3 million C++ programs can't be all that wrong...

Can we help these guys be successful?

I received a Google alert pointing at from this developer who is making the transition from Windows to Linux. Obviously, to do so, he has to drop Visual Studio as his IDE of choice and has picked Eclipse and the CDT for his Linux work. Despite some of the difficulties in setting up the CDT, he picked it as "rivaling Linux's best IDEs".

This transition was one of the scenarios we thought about in the early days of the CDT that would make the CDT successful for desktop development. But it is really only recently that I am starting to see this become more and more common. I think Ubuntu was desktop Linux's tipping point. And as Linux becomes more popular there, as the momentum in the press seems to be showing, I think there will be more and more developers looking at Linux when building their applications. And the CDT, technically, is positioned well here.

But the one thing that made me disappointed with the gentleman's post was the frustration he had setting up the CDT to work properly for him. And, you know, this frustrates me as much as it does these people. We've made long strides at improving the CDT, especially in this area, but it appears the message isn't getting out, and maybe we missed something.

And to be honest, the people that are getting the CDT from Eclipse directly and trying to make it work like this aren't getting the support they need to be truly successful with the CDT. If you get your CDT from a commercial vendor, then you have a much better chance since the vendors generally make sure the environments work properly for their customers (we do our best at QNX to do so for our customers). But the committers working on the CDT are kept very busy by their employers, as they should, and that is making it very difficult to get a focused effort to make the CDT truly work well out of the "open source" box.

And this comes back to the Platform versus IDE debate. The CDT at Eclipse.org is a Platform. It's not an IDE. It misses several components that make it a true IDE. Support for people trying to use it as an IDE is probably the biggest one missing. I'm trying to do something about it in open source with the Wascana project, but sometimes I get the feeling that I'm fighting a losing battle. And without success on the desktop, I don't think the CDT can truly be Uber.

Or maybe I'm just feeling down since my holidays are over and I have a ton of work piled up...

MinGW gcc 4.2.1 now available

Danny Smith from the MinGW project has posted his work on porting gcc-4 to the MinGW platform. From the mingw-user mailing list, it looks like a lot of people were waiting patiently for it. One thing I've learned in my days working in open source, it really makes you mad when someone complains that a release or some feature isn't ready yet. But, I know I'm glad it's finally here, even if it is currently experimental (with the target of 4.3 being the official version).

So what's the big deal with gcc-4 versus gcc-3? The biggest thing is a new optimization framework which promises to be able to generate faster code even accross functions. This is an area where commercial compilers excel. And gcc-4 brings MinGW into the mainstream being releases only days after the official 4.2.1.

The other interesting thing is that the port also supports OpenMP, a standard API and language extensions to support parallel programming. I know the PTP people will be very interested in that. Also, there is support for Objective-C++, which we've had numerous requests to support with the CDT.

I've started updating the Wascana installer to include this new compiler and a couple of other updates it requires. Tune into the web site to find out when 0.9.3 will arrive (with all it's fancy new branding too :)

Man, I could use a paint shop plug-in

So I'm stealing away a couple of hours here and there on my second set of holidays to work on Wascana. One of the things I've done is created a logo. You can see it on the home page. It's pretty simple, an orange moon to represent a lunar eclipse, and a blue 'W' for Wascana. I made it using Paint.Net, a photo editor written in C# (for some reason...). But it was pretty handy since it supported layers and let me draw simple shapes like the circle and text.

The next phase of the exercise was to then use the logo to create images for the icons and bitmaps in Eclipse. I wasn't too happy with how Paint.Net scaled the images and I wanted more control over the properties of the circle and text. I tried a number of different programs, an old version of Paint Shop Pro (when it was still owned Jasc) and GIMP for Windows. Neither did what I wanted.

But that got me thinking. Why isn't there a plug-in for Eclipse which does this. I am making bitmaps for my .product file. Eclipse is for everything and nothing in particular, why not image editing? (And this plays into one of my dreams for Eclipse - and why not take to the next level and do 3D model editing too, both needed for game development - but I digress.) Does anyone know of any activity in that area?

Eclipse CDT, More than Just for Writing Code

I think I've gotten more Google Alerts about "Eclipse CDT" in the last couple of weeks than I ever have. It's a great sign that people want to talk about their experiences, good or bad.

The latest one I got was from something called the "Reality Factory 2 Development Weblog". The author had struggled with the performance of CDT's content assist in Callisto, and I understand why. In Callisto it did a full parse including all the header files included by the file in the editor, which for C++ with lots of templates and stuff, it took quite a while. In Europa, one of the features my intern worked on over the winter was to migrate this to use the index for the contents of the header files. It's way faster, and the author was very happy to see it.

It's also interesting to see the comparisons with Visual Studio. The author states that in many cases, Eclipse and the CDT are actually faster than VS and he's switched back to Eclipse. That's cool to hear. It's been a while since I used Visual Studio regularly but it's looking like we're reaching one of the bars we set for ourselves of being as good as VS (being as good as JDT is the other one, BTW). This makes me believe even more that Wascana is important as a path for VS users who want to switch to Eclipse with all the components they'd expect of an IDE. This is definitely one of the main growth areas for the CDT I see in the coming years.

And the author of the blog entry really brought home why that's true. It's not just Eclipse and CDT's support for writing code. It's all the other plug-ins available to developers to help them in all areas of software development, including managing bugs with Mylin and source code repositories with Subversive. Even the built-in web browser gets kudos for helping out. Taking a look at the big picture of the Eclipse ecosystem, you really do get a sense of the value proposition of Eclipse. Embedded and enterprise developers get it, and we just need a vehicle to get that to the desktop developer too.

Using Eclipse CDT for MySQL C Development

I got a pointer to this blog entry in my Google Alerts this morning. It's an article on how to write a C application that talks to a MySQL database. And it's done using the CDT. Very cool!

This is exactly the kind of article we need more of, showing the CDT in action solving real world problems. The CDT can be used for anything but a lot of people still don't know that yet.

Baby's first "Hello, World!"

(Warning! Major geekness in this one :)

My youngest son is 13 now and his report card looks a lot like mine did. Good in math and science, sucks at literature. He's pretty much a twin, although he's way more interested in sports than I was at that age. And looking back, I guess I was about that age when I started getting interested in programming. My best friend's dad had an HP "portable" computer he used at work and we used to fool around on it trying to make it do stuff.

It was a pretty exciting time back then in the late 70's as home computers were born. TRS-80's came into existence and were the first machines I wrote for, or at least typed my first programs into while hanging out at the local Radio Shack (and, yes, that was in Regina, too). There was no way my family could afford one. And taking a look around my house now with three laptops and two desktops for four people, my kids are way spoiled!

So, I was at the book store the other day, looking to see what people were writing books about (in case the urge to write one ever overcomes my wife's objections :), I saw a copy of "Game Programming for Teens". It looked simple enough for a 13 year old to pick up and it uses a version of BASIC, just like I did when I started. And it's about making games, which he has expressed interest in, so I picked it up. Yesterday, he typed in his first program, the same program everyone types in when learning a new language. The eternal "Hello, World!". I was a proud papa, in the geekiest way a dad could be I guess. And I can tell by his enthusiastic "This stuff is confusing (meaning complicated), but I get it!", he's started down that same path that I did.

But what makes me a little upset, though, is that there isn't such a book to get kids started using Eclipse. The BlitzBasic demo that came with the book is one ugly IDE. I showed my son the CDT and it looks way more impressive. This is one reason I'd like to see Wascana become the IDE of choice for desktop hobbyists, and why I focus so much on supporting the grassroots of our industry with the CDT. If we can get people using Eclipse early in their careers, then it should be a much easier sell when those people come shopping for our products that are built on Eclipse. At least that's the dream, but I fear we still have a long way to go before making that a reality.

Introducing ... Wascana Desktop Developer

As I reported earlier, I have to change the name of "CDT for Windows" to something else. While doing so, I want to try address a big sector that I think we've kept trying but kept missing, and that's the C/C++ desktop application developer.

So here it is, the Wascana Desktop Developer, or simply Wascana. What's a Wascana? Well, since I was in Regina and I had some people comment on my last blog entry to name it after Regina, I did. Wascana is the Cree word for "Pile O' Bones", and was the original name for Regina. The beautiful park and lake in the center of Regina is called Wascana Park. They just finished a cool redevelopment project of the lake, which was an impressive engineering achievement on a tight budget. And this distribution really is a pile of bones, a collection of open source components that we're bringing together to make a skeleton that desktop application developers can dress up. Or something like that :).

I originally planned on addressing the needs of the Windows developer, but, given the strenghts of CDT at cross platform development, I'd like to expand this to cover all desktop operating systems, including Linux and Mac OS X. And I'd like to provide a set of open source cross-platform libraries that support a variety of desktop applications. The wxWidgets library is a natural. I'd also like to support the hobbyist game developer, one of probably the most interesting area of desktop development. Something like Ogre and SDL would fit that bill.

I am also making my Microsoft C++ compiler and Windows debugger support a part of this project to try and get more interest (i.e. help) with it. I've been disappointed in the progress of MinGW, e.g., there's still no gcc 4 port. And gdb is still gdb and has a lot of issues on Windows. So I think MSVC support needs to be there to for Wascana to make any serious inroads on Windows.

Linux will be interesting. Ideally, we'd like to leverage the tools and libraries as they come with the distributions. We'll need to make sure we get the right versions lined up, maybe with some super packages or something. We'll have to see.

And as for Mac, well I'll need help with that but I know there are a lot of Mac developers using the CDT.

BTW, I've renamed the CDT for Windows project at SourceForge and unfortunately, the didn't forward the old name to the new name so I apologize for the confusion and hope you can find us at http://wascana.sourceforge.net.

What's in a Name?

Well, I've been in this business long enough to realize that naming a product is tricky business. I had fears that calling the distribution of the CDT, tools and libraries for Windows, "CDT for Windows", that I'd get a letter from Microsoft one day telling me not to use the word Windows. Well, what I got first was a letter from Eclipse about the word CDT. As per Eclipse's new Trademark Usage Guidelines, CDT is a trademark of the Eclipse Foundation, and using it in the product name "CDT for Windows" is a violation. (Even though it is open source, you can still consider it a product, I guess).

Now no one get upset. I have a great relationship with the Foundation staff, and I can clearly see the need to protect the CDT brand. It wouldn't take much to clone the CDT and make some tweaks and still call it MyCDT (which has been done, BTW), and if not done well, could do harm to the work we've done at building up that brand. So while, I'm disappointed about the prospect of losing the most natural name for the CDT for Windows distribution (which took me about 5 minutes to come up with), I will comply.

The name change also triggers something else that has crossed my mind as I received feedback and looked at the state of the CDT. We are sorely lacking in contributions from the desktop developer space. Despite this, there is a huge contingent of CDT users that are using it for that purpose. And as the need for cross platform development tools grows with the growth of Mac and desktop Linux, we really need to start addressing that shortfall.

So to help with both problems, I would like to shift the focus of the CDT for Windows distribution, more towards CDT for Desktop Development and open the door to building a complete IDE that targets all desktop operating systems. If I can grow a community around that, and maybe even attract commercial interest, then hopefully we can close the loop and build momentum into that potentially lucrative space.

But first, I need a name for such a project that keeps all the lawyers happy...

BTW, at the moment, I'm visiting my birth place of Regina, Saskatchewan in the heart of the Canadian prairies. I didn't realize how beautiful a place it can be, at least in the summer :). If you ever get a chance, it's an interesting place to visit.

SourceForge vs. Eclipse

As you may know, I've started up an open source Eclipse distribution called CDT for Windows out on SourceForge. (If you haven't, feel free to take a look ;). My top objective for this distribution is to help out people who have Windows machines and who want to try out using Eclipse for C/C++ development. We've received numerous complaints and bug reports from people who've tried to make something like this on their own. And so far the reception for this distribution has been warm and I'm pretty happy with it and excited about its future.

One thing that is bothering me, though, is that I can't release something like this from Eclipse itself. Mind you now, I didn't really try, but I think the feedback I got when I talked about it was that there was no way the Eclipse Board would allow the tools and libraries that are GPL and LGPL licensed and with uncertain pedigree to be released from an Eclipse server. And I am the first one to stand up and promote why these legal requirements are important to ensure the pedigree of products that would like to redistribute Eclipse. But, I wouldn't begin to expect vendors to redistribute CDT for Windows. So why does this still bother me?

I guess it comes back to the reason why I'm doing CDT for Windows in the first place. I'm trying to grow the CDT community into the Windows development space. If you've heard me speak, you know I've been trying to do this for years. Visual Studio obviously rules there, but I think Eclipse has a lot to offer Windows developers. And there are lots of them. If we can grow the CDT community there and make them happy, this should help the CDT. And having a good base of CDT users should also make developer products that target for other platforms, like the one from my employer ;), more attractive, making the Eclipse membership happy too.

So, I'm doing this for the benefit of Eclipse. But I can't do it at Eclipse. And the irony isn't lost on me. But at the same time, I'm really enjoying the freedom I'm having doing this at SourceForge. It may come around and bite me in the behind at some point. But for now, CDT for Windows users can benefit from it even if does come from SourceForge, which is where many of the packages I'm distributing are coming from anyway...

Eclipse, a Platform or an IDE?

This debate has popped up again recently as it seems to regularly at this time of year. I've added comments to the odd entry or two. So I figured I should make a statement in my own blog and to make sure I'm clear on where I stand on this issue.

Is Eclipse a platform for tools vendors, or an kick ass IDE for end users? From my vantage point being a project lead on the CDT and working for an Eclipse member company, Eclipse is clearly a platform, not an IDE. A great product manager who I used to work with asked me a great question one day early in my career on the CDT. I mistakenly used the term IDE and he asked a great question. "How can you call it an IDE if there's no compiler?" In other words, how can it be an "Integrated" Development Environment, if it doesn't come with everything you need to actually use it?

But Eclipse is a great platform for making IDEs and they are available from a number of sources, just not from Eclipse itself. And a lot of those sources are from the board and add-in provider members who help fund the Eclipse Foundation and who fund the vast majority of the contributions to Eclipse. This is a business, and I have no problem with that, and this group is focused on making sure their commercial products get the most benefit from Eclipse as a platform as they can. Because of that, though, none of them are really working on, or even, why there are road blocks to making Eclipse from Eclipse a true IDE.

So it feels like there are two issues hanging in the air. First, if we are not really distributing a true IDE from Eclipse, then I think we really need to stop calling it one. The user community expectations have been set high and we often see them disappointed by what they get from Eclipse. I believe it is really limiting the success of Eclipse. Yes it's great now, but I am sensing a slip and everyone is all of a sudden worried about NetBeans for some reason.

That leads to the second issue. Eclipse needs to be a great IDE. And I mean the one they download from Eclipse.org. This is an area where I hear Netbeans is beating Eclipse. Sun is investing in Netbeans to make it a great free IDE out of the box. They don't seem to have a commercial interest in making money at it (which makes me wonder why Sun does any of the Java stuff that they do).

But at Eclipse, that isn't the mindset of the decision makers. I get the sense that they are actually afraid of the free Eclipse competing with their products. I guess if all you are doing is packaging up the free stuff and charging for it, you have a point. But the products that I see Eclipse members building aren't that, so why the fear?

I've invested a lot of personal effort into making the CDT a great IDE. I've seen the feedback we get when the average Joe developer tries to build his own IDE with it. It's not an easy task and they often fail. But I want these people to be successful. Because some of them, one day, will have a need to use my commercial product, and if their negative experience continues to linger, I don't want that impacting their purchasing decision...