Ballmer: Software is becoming a service

Remember my blog entry on "Software as a Service Industry". Well, I had a chuckle when I read today's ZDNet top story: "Ballmer: Software is becoming a service". See, it's not just me, lol.

I think Microsoft will have a very hard time turning into a services and solutions company. They've spent decades now focusing on building and selling great products. The paradigm shift will certainly confuse their customers for the first little while, if not their employees.

But I see it everyday. Every time a customer comes in with a specific requirement that really only applies to their environment, the stronger I feel that selling software out of a box just won't cut it any more, at least for complex software we tools builders end up making. With the ongoing costs of development and maintenance of that software, it makes more sense spreading out the revenue to match. And it places an even higher importance on the extensibility of that software, just as we see in Eclipse projects today.

So, we'll see how this all pans out, but if Mr. Ballmer says its true, it must be true, :)

"AMD to buy ATI"

Now, have you not seen that headline enough yet?

Any time there's a bit of a shakedown in our industry I'm always intrigued. It's not what the industry analysts have to say about it, and certainly not what you read in the press release from the parties involved. It's the story behind the story that piques my interest.

So, I blast through all the reports and try to piece together what is really happening and what it means to our future. For the AMD/ATI thing, the Inquirer yet again puts forth a interesting view on the insider story. Whether what they say is true or not we may never know, but I have seen a lot of rumors posted there that eventually became fact, including the AMD/ATI deal.

I do think that they present a good argument for what is happening, and it seems to be driven by the end of the MHz race (thanks, I can cook a roast in my PC case now, enough already!) and the push for many-multi-core a la Sun's Niagara architecture. AMD also has some pretty cool ideas on how to integrate co-processors that do cool things into their cache-coherent architecture and I'm sure the ATI acquisition will help speed some of these along. And the Inq is pretty sure Intel is working on similar architectures.

So what does that mean for us tools developers? Well, these events really give me more confidence in my prediction that a programming model change is a-coming. Applications will more and more need to take advantage of a multi-threaded environment to get performance gains. We can no longer rely on ever increasing MHz to save us. For C and C++, it means building more multi-threading constructs into the language. Something the Parallel Tools (PTP) people are working on building tooling for APIs like OpenMP.

As I'm sure everyone who's built a multi-threading application (such as Eclipse plug-ins) know, working in this environment is difficult and somewhat unpredictable. The door is wide open for a new set of analysis tools that we can use to scope out when things are going wrong. And I'm sure our experience with such tools in the embedded industry, where we have had to deal with unpredictability of environments for a very long time now, will become of value to everyone.

It's an interesting time again in our industry and we'll all need to keep our eyes on it and be ready to hold on tight as yet another paradigm begins to shift.

Sustaining Open Source Projects Through Turnover

When you have an open source project such as the CDT that has been around for a while, you end up having to deal with turnover in the people that are working on that project. There are usually a couple of reasons I've seen as to why this happens. Either they have been revectored or promoted to work on something else, or they've left the company that was contributing the resource to a company that doesn't want to invest their resources that way. (As an interesting side note, we have quite a few examples now of people who have switched companies but are still working on the CDT, including yours truely, but that's a topic all on its own...).

In dealing with turnover, I find myself going through a paradigm shift from young project to mature project. In a young project, you are struggling to get people and organizations to contribute to your project. So you find yourself accepting contributions that may not perfectly fit the mould and architecture you are trying to set out, but getting those contributions mean getting people involved and showing the world that your project has momentum and is "the exciting place to be".

But with turnover, without proper documentation, automated tests, and good architectural fit, you start finding that that code that helped get your project going now becomes extra baggage. You start struggling to add new features and you find you need to either replace or simply remove the functionality it provided. Without someone to keep the code alive, it quickly gathers "rust" which starts to spread to places where you are trying to do new work.

So the lesson of the day for me is too keep the long term vision, including a well laid out architecture, for the project front and center from day one. Try to influence new contributors to follow that vision and to manage the churn in that vision so that you can sustain the code as long as you can. This is all basic software engineering school stuff, but it applies to open source projects as much as it does to commercial. And I think I am now of the opinion that having a strong vision like this can serve as much of a draw for contributors as a wide open door does. Or maybe the growth in the CDT lately has given me a bit more confidence. Or maybe its my new rose colored glasses...

JUnits are my friend

Now I'm sure everyone who writes code in Eclipse is well aware of the power of the JUnit, but I just felt like expressing my appreciation for them right now.

I am in the middle of adding a few constructs to CDT's new index that didn't make it into 3.1.0 and was worried about whether the code I had just written was correct or not. Of course, the CDT is chalk full of JUnit tests for the DOM and other features, but in the mad rush to get the new indexing framework in I cut corners and didn't write any JUnits for it. Instead, I had my new Index View that I used to browse the index and visually verify things. (Now that view was supposed to be hidden since it's not quite complete but thanks to those who found it and have raised bugs against it :).

Well, now that I have a bit more time, I figured I had better make the plunge and start writing some. To my surprise, with the new indexer architecture it was actually pretty easy to programatically create a project, import some files from my test plugin into the project and run the indexer over them. I was then able to easily write some code to search the index and make sure everything was there that was supposed to be there.

Alas, of course, it showed me that it didn't and I have to now go and find out why that reference to my enum didn't get added. In the end, writing JUnits will have saved me more time than it took to write them. No more excuses. And thanks to Mr. Joe Unit for saving the day yet again!

How many engineers does it take to turn a CDT?

We had our regular monthly CDT contributors call yesterday. These are usually low key things where we quickly touch base, talk about release planning and the occasional technical issue. We've had calls that have lasted only 20 minutes. Sometimes they'll stretch to the whole hour if someone brings up a technical issue and we talk slow enough about it.

This months meeting struck me a little differently though. First of all, I was able to get a full head count and we had 21 people on the call. Of those people, I'd say 16 of them were people that have contributed code or are planning on contributing code. I also know that there were 3 or 4 such people that weren't on the call. I found that I had to cut off discussions and table them for future meetings because we were going to run past the hour we have allocated.

When I joined QNX last year and was handed leadership of the CDT, I remember mentioning to Mike M. that we had a hard time attracting contributors. At the time we really only had 5 or so people actively contributing. We knew the interest in the CDT was high and just needed to find a way to turn at least some of that interest into contributions so that we could continue to grow the CDT.

I'd have to say now we are finally getting the attention that the CDT needs. With contributors counting around 20 and a lot of people out in the community testing and raising bugs, I'm starting to feel like we can actually reach the goals I had personally for the CDT and go way beyond. We have a bright collection of talent now and they are all doing great things. Even over the last week as we opened up CDT 4.0 development, there have been some cool enhancements going in (like common navigator support) and I can't wait to try our first weekly build on Monday.

But the thing that really struck after the meeting was that I am going to be a busy man. With this many people contributing to the CDT, it's going to be a great challenge to make sure we don't run over each other. Communication is going to be key and I will take on the responsibility to make sure this communication happens and to facilitate the resolution of any conflicts that may arise. It's going to be a great run, though, and I can't wait to see what we accomplish as a team.

How many engineers does it take to push a button?

One of the benefits of being located in Ottawa is that I get to rub shoulders with the who's who of Eclipse at interesting times. One of those times happened again yesterday as the button for releasing Callisto was pushed. Now, it wasn't really a button and it took about a half an hour from the time Denis started when the mirrors were ready until all the web sites were updated and we could download Callisto. But it was a moment.

It was particularly underwelming for the newspaper guy who was there, but I did get a chance to interview with him and hopefully sent him off with something interesting to write other than a bunch of computer geeks hitting refresh until we could see the magic "3.2" appear. But such is our life.

I came away very impressed with the work that Denis and his team do. Sometimes we forget how complex an operation that a site such as eclipse.org is. But it takes a team of dedicated professionals to pull it of and my hats off to Denis, Matt, and Nathan for pulling off one of the most challenging releases you'll see in this industry. And it was pretty cool to be in the nerve center as it was happening. Not to mention, they were all using Eclipse to managed the site which was also cool.

What does Callisto mean to the CDT?

I've been lucky enough to be involved with the CDT since the day QNX proposed it to world back in 2002. It's been a very interesting journey. In the early days, the CDT was almost a side project at Eclipse where a few vendors had a dream of building a great C/C++ IDE and tried desparately with the few resources we had to reach the bar that the JDT guys continuously raised and continue to raise on us. But in those days the people working on the CDT didn't have a whole lot to do with the other projects at Eclipse.

Callisto has changed that in a lot of ways. First of all, just delivering at the same time as the other 9 projects opens up opportunities for working with them to bring their features to the C/C++ world. I've had discussions with TPTP with thier static analysis features built on top of the CDT. It's still small but a start. And others will arise in the future I'm sure. But the biggest benefit was our tighter schedule with the platform where we became early adopters and were able to get bugs fixed before having to wait for a maintenance release. And the platform team was very eager to help us out.

For the CDT, even the fact that we knew about 8 months in advance when our delivery date was going to be was a huge benefit. Until then, the release dates for the CDT were at the whim of the vendors providing committers to the CDT as we tried to match vendor release plans with CDT release plans. It made feature planning very difficult (we even had a 4 month cycle once!). And we look forward to the next release in a years time which will give us the opportunity to put forward a great program and make the major version jump to CDT 4.0.

For me personally, though, it was just the opportunity to work together with the 9 other project leads and Bjorn, Ward and Ian from the EMO. These are great people and it was a pleasure to work with them towards this great common goal that even Mike said wasn't possible. We proved them all wrong and have started a new era at Eclipse. And I hope you all enjoy the fruits of our labour, Callisto!

Can't talk now, coding...

I've been pretty quiet lately with the blogging. The main reason is that I've been working certain parts of my body off as I try to implement a new indexing architecture for the CDT. There is a lot of good news and a little bad news with this project. The good news is that I can now index Mozilla in 14 minutes on my laptop! In CDT 3.0, that took around 50 minutes, and improvement of around 75%. As well, as you change files, you hardly notice the indexer running were as it could take up to 12 seconds to deal with the change in 3.0. I almost fell over when I got the first timing at 14. Followed shortly by a dance of joy.

How did I do it? Well I took a hint from the precompiled header feature that most compilers are starting to support. As I'm indexing, and potentially other parse activities as well, I skip over header files that I have already parsed previously and get the symbol information from the index. This required building a more structured database for the index as opposed to the string based flat table in 3.0. It turns out to be much faster since parsing C and especially C++ is a lot slower than the database lookup. This is why incremental times are so fast. I just didn't realize the whole reindex operation would be so fast as well (my target was 20 minutes for Mozilla).

The bad news, is that while it is incredibly faster, it does suffer from being young. There is less captured in the index than there was in 3.0, for Mozilla about 20% less symbols. So searching for certain things aren't going to get you everything you were looking for. But I have been able to capture the high runners. More bad news, is that we are getting spurious StackOverflow errors because not all information is in the index and some of the algorithms we have for symbol resolution weren't prepared for that. So as a result, the new index is only used for Search actions where we can recover gracefully and not for content assist and open declaration.

But back to the good news, as we work more on improving the contents of the index I'll be able to direct all parser operations to it and make the CDT much more responsive for all operations (including my baby - content assist). And even as it is today, there is enough information there for the majority of workflows. Even the field engineers at QNX are extremely happy with it and these are the front line guys who need to make sure their customers are happy. More good news is that I'm getting more help with the indexer, both testing and coding. It's tough to do this as a one man show and I am appreciating all the help I'm getting from the community.

With the new indexing framework in place in CDT 3.1, the opportunities for exciting new features is wide open. And one of the major objections to using the CDT on large complex projects has been eased greatly. It's time to get the message out, now that I can lift my head away from the code!

Software as a Service Industry

Curt Schacker, apparently a veteran of the embedded software industry (well, his resume looks good anyway), has an interesting article on LinuxDevices.com on how he sees the state of the embedded software industry. His contention is that we've been been trying to shove a giant square peg in a giant round hole (his words, not mine), and that the embedded software industry is really a service industry and isn't well served by off the shelf software.

Now mind you Curt is a co-founder of, you guessed it, an embedded services company. But I have definitely seen the trend, especially in the tools area. It is really hard to sell software development tools in a box. Every customer seems to have different processes, different configuration management systems, build systems, coding standards, you name it. It is very difficult to build a suite of tools to satisfy them all.

The biggest success stories I've been a part of in this industry is when we sell the customer a box, but then follow it up with intensive support or custom development to make the software in the box work best for them. There's nothing worse, for me anyway, to have a customer who bought my box, but then let it sit on the shelf because it didn't really meet his needs. It's not so good for the reputation and future sales.

This is where programs like Eclipse really play into the business needs of software vendors. First, by sharing the development costs with other companies, our boxes are cheaper to produce. However, with Eclipse's extensibility and customizability, it is easier to take those products and customize them for individual customer's needs. Selling services may be more difficult and, as Curt mentions, doesn't provide the multiples that products do, but it might be the right approach that customers have always wanted and the best road to profitibility for software vendors.

Web server on your phone?

One of my "too many" interests in the computing industry is how to best serve up web content from embedded devices. The main use I see for such a capability is to allow maintenance personnel an convenient and standard way at getting at state and configuration information from the devices under their care. You see it very commonly used for configuring home routers such as my Linksys.

If you were at the CDT BOF at EclipseCon 2005, you would have seen a demo I gave of using gsoap to do this kind of thing. Since then, I've come to the conclusion that SOAP and related protocols are oversolving the problem. You can do what I was trying to do with simple http GETs. And with the coming out of AJAX to provide more interactive content with web pages using simple http requests, this really starts to look like the right architecture.

The problem I had was how to you integrate an http server with your embedded application. There are a few httpd library packages around but none of them appear to have enough momentum behind them to take the industry by storm. I had considered making my own but going through the http spec I quickly came to the conclusion that it would take a little more work than I wanted to soak into it at this point.

Then I ran across Nokia's Raccoon project where they've ported Apache to the Symbian OS that they use in their cell phones. My head almost fell off. I thought Apache was this big monolithic web server that is driving the bulk of the web servers on the internet, big iron types. Could Apache be made small enough to fit into embedded devices. Nokia seems to have been able to do it. And looking at Apache's modular architecture, it looks like you could write some cool modules that can interact with the software on the device without having to resort to the slow and clunky CGI interface. Very cool, and something I need to look into more.

GWT, Another Turning Point?

I still remember the first time I found out that I could drag the map in Google Maps to pan around the point I had searched for. The funny thing is that someone had to point out to me that you could do that. It wasn't at all obvious to me at first and I really wondered how the hell they did that. Was it some scary voodoo magic?

Of course, now I know. It all has to do with sending requests off to the server using JavaScript and updating the HTML on the page on the fly in what we now know as AJAX. It works in pretty much any browser that supports JavaScript and it lets you create some pretty complex front ends without having to learn MFC or Swing (and, no, this isn't a plug for people to read my page, I hate Swing for all the reasons Phillip does and won't mention it again, much) or RCP for that matter. And, being in the embedded software industry, I think this is still a great way for embedded devices to get quick remote GUI interfaces.

So, when Mike pointed out the new Google Web Toolkit, GWT, I was intrigued. Taking a look at their pages, it was reminiscent of what Microsoft has done with Visual Studio and MFC as a toolkit for Windows and what we're doing with QNX Momentics. Build a nice IDE and a good framework and developers will come. GWT turns out to be something similar for AJAX applications and uses Eclipse for the IDE.

The real question I have is, why is Google doing this? Sure they got a ton of money with their IPO, but surely this isn't charity work for us interested in building web apps that don't have anything to do with Google. But they are making a change in the industry where developers working on client software need to care more about which browser your users are going to use rather than the operating system. I think this will open the door for others to jump in and take some of the client OS share away from Microsoft. But that still leaves the question, why does Google want to do that? hmmmm....

I Hate Typing!

Those who have worked with me in the past know I have a favorite mantra that drives a lot of what I do: "I hate typing!" Now, after 20+ years working on computers, I can type pretty fast. But I can still think faster than I can type and that frustrates me at times. Mind you sometimes the extra sober thought between keystrokes has saved me from implementing the odd bad idea.

But this is the main driver for me when building tools. I find that the best tools are those that allow me to express my ideas by the fastest means possible. I have spent a lot of my tooling career building code generators for visual modeling tools, especially state machines. I've generated a lot of code relative to the number of user gestures. Customers loved it and I think it is still the best example of getting ideas into your software faster than you can type in the code. Hopefully as the Eclipse modeling tools grow, we'll see more of this.

In the meantime, we are still pretty much left to probably the most imporant tools that we have in our tool chest, the programming languages. People who work with me also know that "I hate Java". Yes, it's an evil irony that I have spent the last 5 years being a Java programmer. As the JDT adds more accelerators, like more complicated content assists and refactoring, I hate Java less. But there are just some concepts that I find hard to express in Java, like complicated memory mapped binary files like I have with the PDOM, the CDT's new index, and I just find I have to do a lot of typing to do what I need to do.

As I learn more about C#, the more I realize that it comes the closest to the way I want to work. It has the best of Java such as garbage collection and anonymous functions (anonymous classes in Java). Plus, it gives you the best of C++, such as stack allocated structs and operator overloading. And, if you don't feel like playing it "safe" you can actually do pointers and take more control over your memory. I have no immediate need to use C# for my work time, so learning it has to be relegated to hobby time, which I have precious little of these days. But it would be interesting to see how fast I can get my ideas into code without typing so much.

Tracking Language Trends

After reading Ian's post on Eclipse language support, I had to check out where he got the ranking information. It is provided by TIOBE Software's Programming Community Index. I'm sure you can debate the merits of this index and the fact it is based on hits from the top three internet search engines, but as with all polls, it is pretty interesting to look at.

I'm pleased to see that, despite continuous predictions of C and C++'s demise, they still still #2 and #3 in this index, "eclipsed" only by Java. It is also interesting to note that C is still way ahead of C++. This is something we are seeing in the embedded space, where C++ is still seen as too expensive in size and performance for devices. For very small footprints, this is actually true, but the amount of memory and CPU power available in embedded devices continues to grow and this is becoming more a cultural issue than a technical one.

I was surprised to see PHP listed so highly, at #4. I guess I'm still suffering from my brainwashing that James Gosling did on me that Java was the only language for internet applications. The rise of PHP is probably killing Perl, which isn't surprising as I consider Perl one of those "write-only" languages. I was somewhat disappointed to see the .Net languages so low, but then I'd bet that their query on Basic is picking up VB.Net unintentionally, which if true puts it on par with PHP.

I've been a huge fan of programming languages and paradigms since my university days many moons ago, which is probably why I'm so passionate about the CDT and why I keep pushing the CDT to make sure the it can handle multiple languages. To a large extent, we treat C and C++ as separate languages, so adding a new one shouldn't be that hard. We have Photran team exercising that with Fortran (which failed to make the top 20 but sits at #21, stay tuned for it's renewed meteoric rise!). I also have a hook on a student in Google's Summer of Code that is interested in doing C# and VB.Net for Mono.

Being compiled languages, they benefit mainly in the build and debug side of things, but I'm hoping to extend it to the editor and indexing side with CDT's code models. IDE generation is one thing, but to be fully functional environments for complex industrial strength languages with all the wizbang features of the JDT, you need a solid extensible framework that we are hoping to provide with the CDT. It's all really cool stuff, well for me anyway, and, of course, helps build the CDT community by expanding it's horizons.

ANTLR v3, Everyone's Parser Generator

And now for something, completely different...

I've been toying with the idea of expanding my desires to better support Windows development to better supporting .Net development. There's lot of interesting things happening there not just on the Windows side, but with Linux as well with Mono. Not to mention, there is a Java VM implementation that runs on the Command Language Runtime (CLR) called IKVM. The IKVM is interesting because I just tried running Eclipse 3.2RC3 on it and, aside from a few ClassNotFound and IllegalArgument exceptions, things ran fine albeit a little slow at times. That raises the specter of writing Eclipse plug-ins in C#, but more on that some other time.

So, of course, looking for a break from the mad dash to finishing CDT 3.1, I started writing a parser for C#. I've been dying to try out the new version of ANTLR v3, which is in early access mode of the famous open source parser generator written by Terence Parr. The biggest plus is that it promises to support LL(*) grammars, i.e. almost any grammar that isn't left recursive or ambiguous. I've spent plenty of time trying to get ANTLR to accept modern complicated grammars such as C++ and Ada, but gave up after a little while because of all the effort needed to refactoring the grammar to meet LL(K) restrictions. (For the curious, LL pretty much means top-down parser which is generally how you'd hand write one, like we did with the CDT's C/C++ parsers, and the thing in the parens is the amount of lookahead used to make decisions on which path to take. ANTLR v3 supports infinite lookahead, previously thought of as too expensive but Terence is proving us all wrong).

Well, I've just started and my initial report is "Wow!". Every time I enter a rule that used to give previous versions of ANTLR as well as LALR parser generators such as yacc and bison fits, I get no errors. And looking at the code that gets generated, it looks decently efficient, using a special algorithm to make the lookahead efficient. Hell, at this rate, all I have to do is type the grammar as it's given in the C# language spec and I'm done. Well, not really because the grammar as it is found there has left recursion and has ambiguities, but all these can be fixed with fairly simple refactoring.

I can't wait for Terence's beta in the summer, when hopefully he'll have some documentation so I don't have to guess at the syntax based on the examples. Also, he is changing the licensing of ANTLR and has rewritten the code so that he owns the copyright, which all means that ANTLR should be acceptable for inclusion with Eclipse projects (hopefully, cross my fingers). All of which should mean that it'll be easier to write parsers for new languages that we want to support with the CDT's code model, DOM, and indexing framework. Kudo's to Terence! Now back to CDT 3.1...

Sounds familiar

We've had some good discussions lately in the Planet Eclipse blogosphere about whether Eclipse project should be focusing on the concerns of users or building a platform for ISVs to add their value. In the end, I conclude that you need to balance both for the sake of growth in your community. Unfortunately, though, or fortunately as the case may be, Eclipse projects are staffed almost exclusively by Eclipse members who fit more in the ISV camp. These guys need to justify their investment in the Eclipse on the bottom line. It's the nature of the business, and there's nothing wrong with that, since without it we wouldn't have the great Eclipse that we have today.

Of course, this isn't just an Eclipse thing. A lot of high quality open source projects are staffed by ISVs and the concerns are the same. Recently, chief Linux maintainer Andrew Morton has been frustrated by the focus of his development community as well. Most of these developers are employed by OEM-types who support Linux running on their platform. But a lot of users who are using "unsupported" platforms are raising bugs that these platforms aren't working anymore. How do you get your developers to focus on something their real bosses don't care about?

Well, this is a big challenge for all open source project leads. Developers contributing to open source aren't under contractual obligation to do anything. What they do work on is generally based on the needs of their employers. Yes, that's a pessimistic view because everyone I that I work with in open source is very concerned about all users of their stuff, no just the users that their bosses care about. But when tough decisions need to be made, you can be sure that the general user loses out.

So is that all there is too it. I don't think so. One thing that I think ISVs contributing to open source often don't think of is that, you're "open". Everyone can see what you're doing. Everyone can find out that your contributing to it. And if the general community starts making a fuss, especially in the media, that the open source software that they are freely downloading doesn't work for them, that can reflect badly on the open source project. That could lead to negative publicity that your customers get to see, who may in turn start questioning the quality of the product your are trying to sell them.

As I said, the ISV's need to focus on their bottom line when they consider how to invest in open source. But they need to take everything into consideration, not just the direct needs of their product, but to make sure that the integrity of the project they are building their house of cards on stays on the good side.

Lego Open Source

Back when I was working at ObjecTime, a real-time object oriented modeling tool vendor, we tried to convince our boss that we need to port our code generation tools to support the then new Lego Mindstorms. He thought it was a great idea but couldn't come up with the business case for it. C'est la vie. That was almost ten years ago and I had almost forgotten about it.

If you're a regular Slashdot reader you'd have seen the note about Lego open sourcing the firmware for their new Mindstorms NXT brick. Well that hooked my attention. Investigating further, I found out that this little box was a pretty powerful little unit with a 32-bit ARM7 processor with 256K Flash, 64K RAM, a second 8-bit microcontroller which I assume drives the sensors and motor controls. It has a USB for connecting the brick to a computer for downloading new firmware and programs. It also has a Bluetooth interface so you can hook up to other devices, or even cooler, have multiple bricks talking to each other.

So do you get the sense this is on my Christmas list? You betcha. Can I justify it. Well not really. But it would be very cool to have Eclipse support for this target: CDT to work on the firmware and programs in C and DSDP components for target management. Maybe I can convince Ian and Mike that they need a cool demo for next year's Eclipse booth at ESC. hmmm.

CDT in Action on Big Projects

It's pretty common knowledge now that I use the Mozilla, and lately Firefox in particular, as my main test bed for scalability testing. It's a pretty big project and I have often found issues with the CDT in this environment and we are trying to address them as we can.

I was pleasently suprised the other day when by friend John Camelon (Mr. CDT Parser) brought the following article to my attention. It was written by Robert O'Callahan who blogged last summer about the promise of using the CDT for Mozilla development. At the bottom of this new article is a list of issues with using the CDT on Mozilla, a lot of which we are still working on and will feed into our CDT 4.0 requirements for next year.

I was also pleasently surprised when I went to take a look at the install instructions for ACE & TAO, a pretty big communications framework written in C++ that users have reported problems with in the past. In those instructions are instructions on how to use the CDT to develop ACE applications. Very cool.

It's hard to see how widespread the use of the CDT is out there, at least from where I sit in here. These two examples certainly have certainly opened my eyes a little. Now back to addressing their scalability problems...

New Projects 101

It's funny how we are starting to have conversations on Planet Eclipse. But, I'd like to follow up Mike's post, which was following up John Graham's post, with my own. The topic is what to focus on when starting new projects, building a good platform for ISVs, or building good tools for end users. This is something I certainly struggled with in the early days of the CDT.

My take is that what you really need to be doing as a new project is building a good community. Now what does that mean? Having happy users and happy ISVs that like your stuff and want to use it or add it to their product portfolio is certainly an important thing. Having people talk good about your project shows momentum and serves as a magnet for those who don't want to miss out on your "next big thing".

More importantly however, to the growth of a new project is attracting developers to help you work on it, and by that I mean "add code". That has certainly been my biggest challenge as the CDT project lead, but it is something that I've had some success with in the last few months, and hope to have a bit more in the next few months (if all verbal commitments turn into CVS commits :). I don't know what the magic formula is, but to my previous point, we have shown momentum with the CDT and a high profile project is certainly appealing to developers (not to mention marketing people ;).

But I think more importantly, since most of the developers working on Eclipse work for commercial vendors, you need to make sure your project can easily meet their business needs. You need to make it easy for their employees to get involved and make it easy for them to be able to leverage off their investment in your project. Having a well managed project helps, as does having a good platform for them to add value, as well as good tools to make sure their end customers are happy as well.

So, I guess that means you need everything :(. But, my point is really that you need to look at more than just what you should be working on, but also how you should be working. You need to put a business friendly face on your project to help attract vendors. As well, I think we all need to educate vendors about the business of open source product management and help alleviate their fears, which I have seen time and time again. That is something I certainly need to work on more.

Visual C++ Express Free Forever

Well, as I first found out from Ed Burnette and as I see now at the Microsoft site, Visual C++ Express is now free forever just like the CDT. I doubt anything I've said had anything do to with their change in strategy. I had a feeling, when I first saw the one year free deal, that they were just testing the waters and would eventually remove the restriction. I just didn't think it would happen so soon.

So does that make me give up on my wish to better support Windows development with the CDT. No way! There's more to it than just C/C++ development. I think Eclipse has so much to offer Windows developers that the Express Editions of VisualStudio just don't offer. As one great example, I can't wait to exploit more of TPTP static analysis and expanding it's integration with CDT's DOM. I think there is so much we can do there to make C++ programming more reliable and is something that VisualStudio doesn't offer in any form.

So I think this announcement just makes me want to improve Windows support even more that I'm going on a personal mission to make sure it happens. As always, anyone keen on helping me with this mission, please let me know. I have a ton of work to do with my regular QNX and CDT work so I'd appreciate any help I can get. But I think this is one area that can go a long way to bring the CDT and Eclipse to our much sought after Uberness.

Cross Project Issues/Solutions

One of the things I love most about EclipseCon is that I get to see what the other projects are up to. It was really cool to see the progress that a lot of the projects that were just starting up last year have made since then. One thing I've noticed though is that a lot of them need to solve similar problems. I've been pretty happy to see how these projects are starting to work together to find common solutions.

One example is the Remote System Explorer that IBM has contributed to the DSDP Target Management project. It presents a view of remote systems and provides a framework for attaching services that connect to those systems in various ways. Once people have heard about it, everyone is now taking a look. My friends at HP are looking at it as a solution to remote development for their servers (I suppose that's very similar to how IBM uses it internally) that they'd like to contribute to the CDT. Also, I see that the Parallel Tools Project is now looking at it for remote development for their big supercomputer iron.

The question that comes to mind, though, is that if this is something that can be used by many other projects aside from embedded, is it problematic that this functionality resides in the DSDP project? My answer is that, well, the RSE actually resides on dev.eclipse.org. It is being managed by the DSDP/TM project. These are essentially two different things. Anyone can get at the bits and add dependencies to them. What could be problematic is the delivery schedules of the bits and making sure things line up. This is one reason that Callisto is so important, although releasing all at the same time is having it's own set of issues.

One thing I'm certain of, though. As Eclipse continues to grow, we are definitely going to run into the very same issues I've seen in my past with very large software projects. These issues can get out of hand without good architectural control over what we are building in order to make sure that we have good user and ISV experiences. That includes everything from reducing duplication to having common API and UI guidelines. I know a lot of people hate having to comply with guidelines, but I've seen what can happen when they don't and it ain't pretty.

I think the question Mike is really asking is what role the Eclipse Foundation should have in all this. I'm not totally sure what the answer is, but I believe the best architects are the guys mucking around in the code. They usually have their finger on the pulse of the beast and in the best position to make the right call at the right time. But what these guys really need is someone to help facilitate architectural decisions, i.e. bring the group together and to do some concensus building.

I've been lucky enough to attend one of the Eclipse Architectural Council meetings last December (I'm not a member but Bjorn graciously invited me to attend). There were some great minds in the room and Bjorn was doing a good job facilitating the discussions. But I don't remember seeing anything publicized from it, and we had a great discussion on using TPTP's AGR for UI testing. And, I can't remember if any architectural decisions were made.

I think the processes are pretty much in place. I'm just not sure whether we have all the right people involved. I wouldn't mind seeing what would happen if we brought the top senior committers to the table and asked them what they thought about this or that. I'm sure they already have all the answers. But then, these guys are also really busy getting their features done for Callisto...