Is Backward Compatibility Futile?

In the last few weeks I've run into two products that I'm working with that try to maintain backwards compatibility with previous Eclipse releases. That is, while working on an upcoming release they want to make sure their plug-ins work all they way back to Eclipse 3.4 (one case only to 3.5, but still).

And I understand the desire of that. I've found old plug-ins that I want to use which claim support for 3.5 say and I'm very happy when they install and run with 3.6. And I'm even happier when the install into and work with M4 of Indigo. It's a difficult decision to pull back from the latest and greatest to get some needed functionality. It doesn't seem right.

But for these products, one thing should get in the way of that, the CDT. We don't claim 100% API compatibility from year to year. There's a reason why we're working on CDT 8.0 while the platform is still 3.7. And there's lots of practical reasons behind that, the main one being that we don't want to be tied to bad decisions made in the previous release. The more external tools we try to integrate and new features and just general clean up, we need to make things better even if we have to change APIs to do it.

No it's not fair to the community, but then we really haven't had a lot of push back from the community to stop that behavior. We can only assume they're reasonably happy to follow along, releasing their plug-ins with a fixed line up of Platform and CDT. And maybe that's it. The CDT ecosystem isn't set up where vendors plug-in their CDT integrations into each other. We tend to be competitors at that level, not partners.

But I think that is going to change very soon. Of the two products I mentioned, one is more mature and I guess CDT just happens to be backwards compatible enough that things just work. I'm a bit surprised but it relies mainly on debug APIs which we've been pretty careful to preserve. But without guarantees, I fear what they are doing.

The other is new and I'm kinda getting in on the ground floor. I have to decide which version of CDT to support. The rest of the stack supports back to Eclipse 3.5 which would be CDT 6. But then I want to do something good with CDT scanner discovery to properly set up the indexer. There should be some nice fixes in the upcoming CDT 8 for that. So do I have two versions of this thing? That's kind of where it goes, which is why I'm hoping we get these APIs locked down soon, for the good of all integrators who are facing the same decisions.

A Switch in the Grassroots? to Mobile?

It's no secret I'm an Android fanboy, of fanbois, or what have you. I'm not sure why. I guess what really sold me was the ability to run it in an emulator on my laptop before it was even available in phones. It was exactly what I was looking for in a mobile/embedded target so I could play there and learn what application developers need out of their IDE, or in my case, the CDT. Yes, iPhone was already out but I didn't have a Mac so Android sold it for me. If I had a Mac, who knows, maybe I'd be an iPhone fanboy with the rest of them.

As I mentioned in my last blog, I've been busy doing "real" work here at Wind River and now have finally got a chance to stick my head up and see what the CDT needs from me. My efforts in the CDT in recent years is all about getting the CDT into the hands of the grassroots of software developers, people who are hobbyists or students who are looking for a free IDE they can use on their projects. The commercial theory behind that is to make the CDT ubiquitous so that when we go to sell them our high value products based on the CDT, they have less of a learning curve and barrier to adopt those tools. Can't say whether that's been working or not, but there is no doubt that the CDT plays a major role in the embedded space where I work.

But, now, I am starting to wonder if my past focus on the grassroots needs to change. Previously, it was all about supporting Windows development with the CDT. Linux too, but that was generally taken care of without my help. The Wascana project was born out of that and with Helios it reached it's 1.0 version. You look at it, though, it only has 10,000 downloads which is actually half of the previous 0.9 version I released 2 years ago and that release had nowhere near the advertising I have tried to give Wascana 1.0, even with a prominent mention on CDT's download page. Maybe the grassroots has switched. And I think I know where I need to focus next.

I don't know if you've been following the geek news but Android 2.3 was released yesterday. As @sogrady correctly pointed out, there's not much exciting there, at least not for the consumer. But if you're an Android app developer, especially one who's been trying to write games and multimedia apps using C++, it is a revolution. The Android NDK team has finally provided APIs for audio and input events that have made life pretty difficult for these guys. Not only that, they've added a framework that allows you to create an Android app without writing a single line of Java code. It's awesome :).

And that has me thinking now. We've had repeated asks and attempts from users trying to use CDT for iPhone development. And we've seen developers in the Android community using straight CDT or with the plug-ins that currently reside in the Eclipse Sequoyah project. I firmly believe that this is the next grassroots. As the computer industry changes, so do the developers and I need to make sure that the mobile app devs have a low barrier to use the CDT for their projects. Sorry Wascana and Windows, I need to change my focus.

Back to the Blogoshere

I've been pretty busy lately. After a couple of years of looking at Eclipse based install technologies, I'm back working in the IDE space on some cool things based on the Eclipse Target Communication Framework. That's taken a lot of my time so I've resorted to Tweeting short ideas rather than spend the effort writing here on my blog. And I miss it and I have accumulated a lot to write about. So look for more in this space.

There are a few things I've been interested in lately. Android is still at the top of my list. I have a couple of phones now and am immersing myself in the experience to learn more about it, especially how apps are different from the now legacy environments we have on our desktops. Meeting the needs of app developers of course is important to us working on Eclipse based tooling and I think it marks a shift in the grassroots. Projects like Wascana which focuses on CDT for Windows dev are becoming less important to me than CDT for Android native so look for new things out of me there.

I'm also becoming maniacally focused on usability. This is a relatively new area for me after years of being a modelling and parser guy. But it is so important to create software that users want to use and it's a challenge. And I'm going to leverage my passion for writing to help. Writing user stories will really help me get inside their head. Not only do you need to understand what they are trying to accomplish, you need to understand why. It'll be cool to see how this works on practice and should be fun.

Well I'll write more later. The software world is going through some major changes thanks to both web technologies and mobile. Android and iOS have a great rivalry going and I expect to see the avalanche of mobile devices and even things like settop boxes that app developers are going to want to target. It certainly is a great time to be in this industry.

Historic Day for Linux Desktop?

I just tweeted this, but it's worthy of a blog entry because I think this will, or at least should be, marked as an historic day for Linux. Mark Shuttleworth, Ubuntu chief, blogged yesterday that they are starting a transition from an X Windows based environment to the Wayland display server. That is huge news and a huge push for the fledgling Wayland project which is starting to get a lot of love lately. Intel, who employs the main developer for Wayland, already seems committed to getting MeeGo on top of it, but this move for Ubuntu all but assures Wayland will become mainstream for the Linux desktop. And I can't wait for that!

So what the heck is Wayland and why am I so excited about it? Well I've been working with X Windows since my university days when X11 was spanking new. It had a great architecture that allowed the display to be hosted on a different machine than where the application ran. Back in the early 90's that was pretty important since workstations weren't very powerful so we still had big iron Unix servers where we ran things and being able to display them on any machine in the lab was liberating. It was the best, back in the early 90's that is.

Then entered personal computers thanks to Microsoft Windows and to some extent Apple Macintosh. As these machines grew faster and faster, it became more economical to run your applications locally. Not only that, but the graphic architecture, where display handling was part of the operating system, allowed for the desktop environments to become rich, to the point now where we have the beautiful environments of Windows 7 and Mac OS X.

Now when Linux came along, the powers that be chose X Windows as the underlying display architecture. It made sense since X Windows is open source and it does a good job. But it is shackled by the underlying architecture that made it popular in the 90's. As Mark put it, "I understand that it’s *possible* to get amazing results with X, but it’s extremely hard, and isn’t going to get easier. Some of the core goals of X make it harder to achieve these user experiences on X than on native GL, we’re choosing to prioritize the quality of experience over those original values, like network transparency."

And that's where Wayland comes it. Wikipedia describes it as "a lightweight display server for the Linux desktop. Started by Kristian Høgsberg, one of Intel OSTC member, the software's stated goal is 'every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker'". It gives the application and window managers full control over how their content is displayed and gives them free access to the graphic hardware acceleration through OpenGL and OpenGL ES, essentially the same architecture which gives Windows and Mac their great environments.

It's going to take some time as the ecosystem grabs hold of the possibilities. It is almost certain that other Linux distributions will jump on the bandwagon, and I'm sure nVidia and AMD will do the same with their hardware drivers. But once they do, I am convinced that this will finally make Linux a real contender in the desktop space. I can't wait :).

Playing App Developer - Where to start

The mobile space just doesn't seem to stop being more interesting by the day. It's got me hooked, and I'm not sure why other than it's fun to be a part of, even if it is in my hobby time. I keep trying to integrate it into my day job but it's not clicking :). Instead, I am trying to become an amateur game developer in the few hours a week I get time for it at home. If nothing, it helps me feel a part of all the excitement.

As I march along my journey, it becomes quickly clear the first choice app developers face when getting in the game. Which mobile platform do I start with and what do I do about the others? From where I sit, the choice is obvious. I have an Android phone (actually I have two but my first one is a Roger's HTC Dream that's stuck on Android 1.5 which isn't very useful), and since the SDK is freely available I am starting with that.

But I can't ignore Apple's iOS. It still is the mobile industry's darling and likely will be for a long time. The problem there is that I don't have a Mac which is a pretty high barrier to entry IMHO. But that's OK. There seem to be a few people in the blogosphere who know how to get Mac OS X running in VirtualBox. But when it comes time to actually deliver something (assuming I ever get that far), you'll need the real thing.

It's pretty sad to see what's happening to Symbian. I have friends with skin in that game so I'm not going to say much, other than I agree with the prognosticators. Throwing your product over the wall into the open doesn't make it an instant success. At the end of the day, open source doesn't win mindshare. Having low barrier to entry and a good chance of getting good volumes do. Symbian is a technically complicated app dev environment. Qt will make that better. But if you're programming to Qt, then Symbian doesn't matter much since MeeGo also runs Qt. Which makes MeeGo something to watch out for.

RIM is an interesting choice. But people don't think of RIM phones as gaming devices. The new tablet might change that, but it's not clear you can write native code for it, which, of course for me being CDT Doug, is a must.

And the same is true for Windows Phone 7. It appears you need to use C#, or at least managed code. I'll need to dig into whether managed C++, if it even still exists, would work. But Microsoft is the king of walled gardens as much as we look at Apple today. But Microsoft also loves game developers, so we'll see how that platform evolves.

So it's an interesting array of choices and the pieces are all in motion and it's a bit hard to guess how it'll all turn out, which is why it's fun to watch. Of course, I do need to mention that I'd prefer to use the Eclipse CDT and tools from the Eclipse ecosystem to build my game for all these platforms. But that is only slightly less disjoint than platforms are. As I've often said, I'd love to have a single Eclipse project with build configurations and debug integrations for all of these. That's the vision, anyway. And playing in the mobile space has me convinced how important that really is.

Users versus Vendors, or is it Users and Vendors

One thing I've been noticing lately on the CDT project that's probably happening with other projects at Eclipse is that more and more contributions, contributors, and even committers are coming from companies that are users of Eclipse technology. When we started the CDT and for many years we were driven almost exclusively by vendors that had commercial products that used the CDT. But now we have this very interesting mix and that is really changing the dynamics of how we work.

But you could see it coming and Eclipse is setup up to promote such growth. It started as bug reports, then slowly patches started getting attached to those bug reports, then those guys writing patches started contributing more patches and participated in the mailing lists until we finally voted them in as committers so they could apply their own patches. And that's how it's supposed to work. That's how you grow your community. And that's how we've reached the rich diversity enjoyed by the CDT project.

But as I mention, there's an interesting dynamic that's happening. The vendors are still trying to make money selling CDT-based products. Those users used to be potential customers of those products. However the economics of open source makes it actually cheaper and gives them more control if they get their tools and platforms from open source and staff a few developers to maintain and grow that software. When you have a user base that numbers in the thousands, I can see it. And there are quite a few of those companies, especially in the embedded space.

So what used to seen as differentiating features for vendors is still functionality that is desired by these user contributors. And of course, they would rather see that functionality implemented in the open where they can share it amongst themselves and anyone else who could potentially contribute. So as they organize, the tools vendors are looking on with dread. We have always fought to stay above the open source line with our value add, but it's becoming more and more difficult. And that line is growing exponentially. It's certainly a wake up call for us who get paid out of product revenue.

Has the industry changed making us dinosaurs or is there still value that we can provide that users will pay for. I think we still can make money, but we definitely have to change they way we think. It's no longer about who has the best features. It's what it should have always been about, who makes their customers the most successful. Our user contributors know that as that's exactly what they are paid to do. We vendors need to find our place there too.

CDT Summit Report: What to do about the Eclipse Platform

We had a lot of heated debate about what to do with the Eclipse Platform and the troubles we've had trying to contribute to it to allow it to meet the needs of our customers. There have been some successes, there is no doubt. We have flexible resources in 3.6. We have flexible debug in the platform for quite a while now. So we are very thankful for that.

But we're still not in a good place yet. We're still really struggling with build. CDT builds are complex beasts involving external compilers and linkers and other utilities and generators. Builds tend to take a long time. My standard sized C++ project porting the Irrlicht game engine to Android takes about a few minutes to do a full build with a Minimum 3-5 seconds for a one line change. It's not "instantaneous" like Java and dynamic language builds tend to be. So features like automatic builds never made sense for us.

Also, our builds tend to be managed by external tools, 'make' in particular, that manage the "delta" of what needs to be built for us. The resource delta that the platform provides is useless in those cases, other than as an indication that something has changed and we need to invoke make. Mind you we tend to always build anyway just in case we have external files that may change that aren't being tracked by Eclipse.

That leads to the oddest workflow, clean, which in the C++ IDE's we've used in the past, means just that. Remove all previous build output. But since that also clears out the Eclipse build state, it invokes a FULL_BUILD right away to rebuild it, which we then interpret as the need to call out to make which then puts the build output right back. And if we ignore FULL_BUILDS, we miss the initial build. It's a mess.

The good news is that we have people working on fixing these things, and have opened bugs against the platform and attached patches to them. But it's been really slow to get them looked at or they are being rejected outright. What ends up happening is that vendors fork the platform and apply the patches they need anyway. Now that's not a healthy situation when we are trying to build an ecosystem when everyone has a different eclipse platform you need to plug into.

So what do we do about this? Is e4 the answer? No. In fact surveying the crowd at the CDT summit, no one was interested in the features that e4 brings to the table. It doesn't address the problems that we as a C++ IDE community have today. And we need to those things fixed in the Platform today, not in an incubator. Fancy UI frameworks are maybe something we need down the road, but our customers want us to get the basic workflows working well first.

So in a drunken stupor (well stupor anyway) at our celebration event I threw out a proposal to the people standing around me and then to others during the week. e4 is a fork of the platform. It was created to try out some new ideas. Why don't we create our own fork of the Platform focused on meeting the needs of the CDT community and for our fellow Tools projects that have the same needs. That way we can at least share the forks we've already created for our products. We still need to run all the same plug-ins we do today such as Mylyn, JDT, etc. So we can't go crazy and change the world. But at least we'd have control over it to make sure it meets our needs.

You know me by now. I like to brainstorm with the community. So I'm only semi-serious about forking the Platform. We are taking a serious stance on the bugs we have opened up there and I hope the Platform team will work with us for the mutual benefit of our users. We are frustrated about the lack of progress and we do need to think of alternatives. And forking the Platform isn't as far fetched as it once seemed. It's actually a admission of what many in our community are already doing.

CDT Summit Report: No git for us, not yet

We had a pretty good discussion about using git for managing the CDT source. For the community members that care, git is critical to the future success of CDT. git allows the workflows we need to allow adopters to make local changes as necessary and then deliver those changes to the CDT project as candidates for inclusion upstream. That workflow is very difficult with CVS since it requires you to set up a disjoint repository. Bleach.

So we're pretty eager. However, at the end of the session, I got the feeling that we just weren't ready for it. At least not yet.

First of all, there's just the need to figure out all the workflows we want to support. I was excited at the beginning of the summer about using Gerrit code review for CDT just like the egit guys are doing. Having a system to manage code changes, to make them visible to all, and to make it easy to do code reviews, is very compelling. However, it turns out that the egit use of Gerrit was a trial and the Foundation staff isn't ready to support it yet.

So we need to go back to square one, managing patches in Bugzilla which takes away from that fork and contribute workflow that's bringing us to git to begin with. It does bring up the need to produce some documentation so that we can decide how we want to work and to educate the contributors on that.

That brought us to the egit plug-ins. There has been some really good progress with egit thanks to the team working on it. I'm using egit for a number of projects I'm working with, both Java and C++ and am really liking the experience. However there are still a few things lacking and defects that I'll be raising bugs on. I am seeing a lot of exceptions when doing merges, including out of memory. I want to be able to compare branches, but I guess that's what the Synchronization view is trying to do. But then the usability of the Sync View is very confusing.

And finally, the real show stopper for me is the lack of being able to create patches between two commits, e.g. between two branches. Again, our big workflow is to allow adopters to fork and contribute the results back to the project. They will be creating local branches and committing updates to them. So being able to create a patch between their branch and our master is a must.

At the end of the day, we're just not ready. Once we figure out how we want to work with git, and when egit fully supports those workflows, we'll jump on the bandwagon with both feet. Until then, we have work to do.

A great CDT Summit 2010

After a year off due to lack of travel budgets, we held the CDT Summit again this week this time at the Ericsson offices in Montreal. It was a great summit and proves again why we do these things. Many times I looked up during the meetings and then through the evening events and saw people from different places talking to eachother, laughing, sharing stories and experiences. You hold these things to have technical discussions on the issues of the day and plans for tomorrow, but the real value is the relationships we build working together face to face. You just can't duplicate that on-line.

Many thanks to our hosts at Ericsson, Marc Khouzam and Dominique Toupin who worked tirelessly in the weeks leading up to the summit and fought through all the infrastructure issues you end up running into during these things. It all worked out superbly in the end, despite our ribbing them about it :). Thanks guys!

Also thank you to our sponsors from Ericsson, Eclipse Foundation, Wind River, Texas Instruments, Mentor Graphics and Google whose financial contributions made this all possible. We had a very special event on the first night and got a sense of the history of Montreal and a party in a unique setting. Not to mention the superb meals we had for lunches and breakfast, to fuel our efforts during the summit. It really made us comfortable and let us focus on the work at hand.

I have a lot to write about on the topics we discussed. There was a wide variety and some of these things will be of interest to the general Eclipse community as we work to make the Eclipse the best IDE for C/C++ developers in the industry, which is not always an easy task given the general nature of Eclipse. But I'll blog about those things over the next few days.

My biggest thanks go to the 30+ people and their employers/sponsors who allowed them to travel and take the time out to contribute to the CDT summit and to the handful of people who attended remotely through my CDT conference bridge and Webex account. These summits are most successful when the people come with the mind of working with the rest of the community to do something greater than they can do on their own. As I mentioned to James on his way out. It's why we do open source: "to have some fun and to change the world".

More later...

Entering the Realm of Interaction Design

I'm about to embark on a relatively new era in my career. I'm always looking for new challenges and there is a huge need with the tools I work on to improve their usability. UI design is a long way from C++ parser writing, but I've seen great UIs and I know pretty quickly what a bad one looks like. And I want to make the life easier for my users.

I was given a book written by Alan Cooper called, "The Inmates are Running the Asylum". I only read the first couple of chapters but it really chimed with something I always had in the back of my mind. Computer programs are usually written by engineers that assume (or don't even consider) that users think the same way they do. And Cooper has some pretty good and common examples of where that assumption ends up being pretty embarrassing. Or worse, "it leaves the user feeling pretty stupid."

When you work on a UI feature, often you're following the Model-View-Controller paradigm. Being a computer person, you start with the model and then think of ways of showing that model to the user and then controls for manipulating the model. You want to make sure they can change everything to get the most out of the fine work you're doing.

Well, the user doesn't care squat about your model. He has a job to do. He is trying to accomplish some goal in order to look good in front of his customer. And he needs to do it quickly so he can get home to see his kids before they go to bed. He doesn't have the time to learn the intricacies of your model and the esoteric ways you've provided to view and control that model.

Cooper suggests we need to do Interaction Design as a lead up to the actual code. Understand what the user is trying to do and find ways to allow him to understand your software quickly and to get his job done quickly. Design the View and Controller first, then worry about the model. Get under the user's skin, know what he knows, feel what he feels. That's a pretty tough thing to do for us engineers who love the challenge of creating the world's best algorithms. You don't need to empathize with anyone to write "good" code.

It's a hard job to put together an intuitive interaction design that accomplishes what the user needs with minimal gestures, but I look forward to that challenge.

Hypervisors drive Heterogeneity

I have put together a pretty neat little lab here under my desk. As I always say, you have to use the tools to understand the needs of the users. You have to get into their shoes and see what you like and don't like. Then you have a good chance of building tools they'll actually use and like.

My lab includes two "embedded" systems on the right. The top is a board that has a Freescale PowerPC P4080 8-core chip in it. I have attached my Wind River ICE JTAG unit to it to test some really heavy duty multi-core scenarios. On the bottom right, I have what looks like a basic PC, and it is, but it runs Wind River's hypervisor hosting three operating systems: Wind River Linux, vxWorks, and of all things Windows. I don't have the P4080 system booted up yet, but my intention is to run the Hypervisor there too with random combinations of wrLinux and vxWorks.

As I put this together, it really drove home the need for an IDE platform that is heterogeneous. That's a hard word to pronounce, but what I really mean is an IDE that can target any operating system that can run in a hypervisor configuration, which is pretty much all of them. And that means an IDE that has plug and play support that lets you create the source for applications that can run on them all, build that source for any and all of the target platforms, and debug the application as it runs on one ore more of them.

And, you guessed it, the Eclipse CDT C/C++ IDE is a great platform to do that with. We have build and debug support for the GNU toolchain for Linux and from Wind River we have commercial support for vxWorks and Wind River Linux, and upcoming in the next release of CDT, we'll have support for Microsoft's Windows SDK which includes Visual C++.

As well, I'm about to embark on a very interesting journey with the Target Communication Framework as we advance it's debug capabilities to cover all of these platforms as well. With a common framework for agents that run in all these environments, we'll have the ability to plug 'n play capabilities into these agents and come up with tooling we haven't even dared to consider before. Am I pumped about it? You betcha. We've long had the advantage of plug-in architectures with our Eclipse-based tooling, and now we'll get that advantage all the way down to the target as well.

And it's really these hypervisor scenarios that have brought me here. It's finally a concrete example where you really need the heterogeneous capabilities that have driven my work on the CDT. And, it's something to sell our employers with too :).

Fitting Eclipse into my world

As I blogged a few days ago, I've started working on a game engine using open source bits. Part of it is just to satisfy my hunger to learn more about game development, but the more practical benefit of this effort is to better understand the plight of the C/C++ developer using the CDT on a real and fairly sizable project.

And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn't check in my Eclipse .metadata directory and any directories containing build output.

I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don't support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?'s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I'll try again.

But this article isn't about egit. It's about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.

I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it's not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There's even a README file at the root and some files to help me build for Android using CMake.

I think there's a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren't projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I'm not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.

I'd like to hear other people's experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?

Happy 100K CDT!

I originally sent this in an e-mail to cdt-dev. But it's info others might find interesting.

Hey gang,

Just to let you know we passed 100,000 downloads of CDT today and to pass along congrats!

And, looking at the stats, there's some interesting information there.

First, where do people get the CDT?
- 74,300 from the Eclipse C/C++ IDE package
- 6,400 from the Eclipse Linux C/C++ IDE package which includes the Linux Tools stuff as well
- 13,700 from the Helios train repository
- 2,200 from the CDT repository
- 2,700 from the CDT master zip
- 1,000 from Wascana (w00t!)

So that's about 80% from the Eclipse packages. There are a couple of things I get from that.
- People want a quick and easy way to get the CDT and the Eclipse web site funnels them there.
- People who use CDT with Eclipse are CDT users first. Much fewer start with a different Eclipse package and add CDT to it.

And for the platform breakdown.
- 59% Windows
- 34% Linux
- 7% Mac

Again, the Linux number continues to be much higher than we've had in the past, which could be attributed to more developers moving to Linux, or people are moving back to Visual Studio on Windows. I'm pretty happy with the 1K so far for Wascana. And I'm hopeful at getting a Windows debug solution with Visual C++ support for Indigo (thanks to work Eugene from Wind River has done in TCF) which may change things.

Also the Mac number is only slightly higher than in the past. Other than fixing a few bugs this release, I think we're still missing the big carrot, Objective-C. Unfortunately, there isn't enough investment in this area for that to change any time soon, so it is what it is.

All-in-all, pretty good numbers for the summer. We usually get an explosion in the fall when the kids head back to school which validates my grassroots strategy. We're getting a hold of the kids early and making them Eclipse savvy so that when they enter the workplace, they'll carry forward the word there and give our employers money :).

Next report at 200K. We'll see if things change as we go.

R-Evolve or Die

"Evolve or die!". I've heard that sentiment a few times lately related to existing technologies that are coming under fire for being too old and ugly in the face of "up and comers" with fancy interfaces and social connectivity. But the more I think of it, is "Evolve" the right answer?

I don't think so. The pace of evolution tends to be slow. At the start, you look more "different" than "evolutionary" and no one cares about that. No, I think you need to be "revolutionary" if you want to make a difference. And that's hard for veteran organizations that fear risk to pull off.

A great mentor of mine once told me: "Don't be tied to the technology". The example he came up with was Smalltalk. We had a whole product written in Smalltalk and it was awesome. And it would still be awesome today except for one thing. The UI didn't fit in with any other applications you may have been using. That and the companies that supported Smalltalk eventually died off. So what did we do? Well, we rewrote the whole thing with the help of standard desktop tools and languages and a huge code base we inherited in a takeover. Unfortunately the result was a big Windows app, but it got the job done and saved the product.

So what am I getting at? Well, I've got a renewed interest in the "IDE in the Cloud", somewhat sparked by Google's new experimental App Inventor for Android. I'm not a fan of the puzzle metaphor they picked, but it just got me thinking again of the power of the new browsers and web technologies and how we can apply them to the tools space. It does make the behemoth desktop IDE we have in Eclipse look old fashioned. But instead of thinking evolutionary, what would a revolutionary IDE look like in this new world?

Exploring Game Development with CDT

Well, it's holiday time. I'm off this week and next and it's filled up with a family union my wife and I are hosting, but I am stealing away some time now and then and my hobby time going forward with one of my dreams, building a game engine.

Of course, it's impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.

The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT's support for tool chains allows it to be used to write applications for multiple platforms. In this case I'm going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn't really that much of a stretch. (BTW, yes, I'm purposely leaving out Apple for fear of getting trapped in the "walled garden").

For the engine components, I'm using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I'll use bullet physics for the physics engine. There doesn't seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.

The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.

We'll see how far I get. But I benefit from it in two ways - living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I'll come up with ideas for new tools. Sounds like a win-win.

I'm not anti-e4, I'm just busy with other things

As we start the discussion about CDT and e4 on the cdt-dev list, I just want to make sure people are clear when I make statements that appear anti-e4 that I'm not anti-e4. If you like e4 and you want to use it in your project, go for it. There's some really cool things there and the guys are doing a great job of pulling it together.

But I have other important problems to solve higher up the stack than I see e4 trying to solve. In CDT-land, our biggest issue is getting people to even use Eclipse who are using emacs or vi and gdb just fine and who struggle adapting to the world of IDEs. We need to focus on enhancing the value of Eclipse and simplifying adoption to make it more appealing for these people to buy into our wares.

At the top of our list are some workflow issues and the flexible resources work that started in e4 but moved in to 3.x is a start on that. I think we still need some work on build to support multiple build configurations per project, and for build to work just as it does from the command-line. And the launch UI is over complicated for what our users need. But those things are all the platform stuff we really need. And we do have people trying to make contributions in those areas.

And, we have some things to work out in our own kitchen. We need to fix up the CDT build system so that vendors aren't so frustrated by it that they end up writing their own. Then there's the world of debug and systems analysis where I think we really need some innovative UI approaches. As starters, I don't think you can visualize a massive multi-core system using a 2 dimensional UI that assumes a single context. I'd love to see something like Clutter in SWT.

So while the world is rushing towards HTML5 and the cloud, that's great and everything, but we still have a lot of work to do to make Eclipse a great IDE on the engineer's desktop.

My own little PluginFest

This is a bit of a follow up to a blog entry done by my product manager partner in crime here at Wind River, Emeka. I spent a couple of weeks recently (in the middle of the Helios rush too) to put together a demo he is giving today at IBM's Innovate Conference. It was great because it reminded us of what we're really trying to do here creating IDEs using Eclipse, *Integrating* tools.

The the code in the demo is quite small but that's a good thing thanks to good APIs. It's a menu item associated with the editor for Wind River Workbench's Memory Analysis database. The item takes that database and zips it up and attaches it to a newly created Work Item from IBM's Rational Team Concert, i.e. Jazz, product. The story goes that you see a problem in the memory analysis and you want to record it for someone to look at later. And that person takes the attached zip and opens it up in the editor to start his investigation, using the other information recorded in the work item and documenting his findings there as well.

The value of the integration becomes greater than the combined value of tools that Wind River and IBM have built on their own. And that's the promise of Eclipse and it was great to see that promise in action. But it also brought home that we don't see that happening enough. As we solidify the platform and the first layer of tooling, we need to keep driving the solutions and build up a bigger and better stack and sell our collective customers on the value of Eclipse and the solutions we're building for them.

A few years ago we held a PluginFest where we brought together a number of embedded tooling vendors and tried to plug and play their products. In the end, it was more to test that they co-existed with each other than anything. A few had real integrations to show. But I think we fell short of the goal and dropped the ball on the potential. Maybe it's time to bring us back together, not to test interoperability, but to explore opportunities to build real value add integrations that we can work on together. Emeka and I and the IBM RTC gang have started down that path. Hopefully it can be used as an example of the real value of Eclipse as an IDE and rejuvenate the ecosystem a bit.

Writing Games for Android ... and other app stores.

Tools is my passion, especially tools for native programming. Being a game developer wannabe, I'm especially excited when I see game developers using the tools I help build. And that's one reason why I'm closely following and helping out with tooling for the Android Native Development Kit. There's a great community there that could really benefit from a good CDT integration, and maybe who will come help make that integration great.

At any rate, I watched Chris Pruett's session on Android game development from Google I/O and found it very educational. The first half was about technical details and tips behind Android game development, but the second half was just about good game development for mobile platforms. It's a great view and I've embedded it at the end of this post.

The real game changer (sorry to use the pun :) in my mind is the growth of app stores or markets. Pretty much every mobile platform vendor is creating some sort of one stop shopping experience for their devices and it's a great vehicle for app developers to quickly get their wares into the hands of paying customers. And with systems like Valve's Steam, you also get this great experience on your desktops and laptops.

The biggest advantage of markets, as Chris illustrated, is that it's also a great way to keep in touch with your customers. Customers tend to be brutally honest about what you've provided them, and it's good to get first hand looks at that feedback. And also, thanks to the markets, it's also easy to get updates and fixes into their hands. It's a win/win.

Anyway, it's a great view. Take a look.

Update: The embed didn't work very well. Just click this link instead.

My take on Android Keynote at Google I/O

No, I'm not at Google I/O, despite my twitter traffic during today's keynote. Mind you that was probably a give away that I wasn't there as even the Googlers struggled with wifi connectivity during their demos. At any rate, I was glued to see where Google was taking Android. And, to be honest, they didn't really surprise me much as pretty much everything they announced had a rumor associated with it. It's hard to keep secrets in this industry.

Despite the lack of surprises, there were a few interesting points that were made, and a couple that were not which gave me pause.

First, was Google TV. Yes it too was rumored and came out pretty much as was rumored. There were two things I found interesting about it. And no, a set top box based on Android isn't one of them as we pretty much expected that eventually. No, first was confirmation that the initial Google TV boxes will be based on Intel Atom chips. What that means is the real first confirmation of an x86 port of Android from Google officials. The new Android Native Development kit r4 that also came out today also confirms it with an x86 port of the native libraries. It's not quite cooked yet as there's no toolchain to build with and no image to run on, but they're there and a sign of things to come.

I guess the other thing that struck me about Google TV that I think was even more interesting was that they were running Google Chrome on top of Android on top of x86. I've heard rumbling about the lack of information about Chrome OS at the conference. Now, if they have Chrome running on Android for Google TV, why not run it on netbooks too? And then why have Chrome OS at all. That's where I'm guessing there won't be one or if it does appear, we'll all be wondering why when you can get all that plus Android apps to boot just like on Google TV. Or, maybe, that is what Chrome OS is. We'll see (or maybe not)...

So there were a few new things in the Android NDK for me to chew on. One that will make the CDT build integration I've been working on easier to do is the ability to build outside of the NDK directory tree (weird, yeah, but they previously reused the build system from the platform that is done that way). So look for that sometime in the near future. There's also gdb support for native applications. I'll need to see what's needed to hook that up to CDT's debug interfaces. In the end it'll be a great public example of how to use the CDT in a cross compile and remote debug scenario. Not to mention it'll be fun to use :).

CDT, Towards World Domination

Big smiley planted in the title of this one BTW.

I've been working on the CDT for coming up on 8 years now. It's been quite a long journey, and what keeps me motivated is that I don't see the end in sight yet. For CDT to be successful, the companies and individuals using CDT need to be successful. And until I see everyone happy with it, our job isn't done.

Now there are a lot of successes already today. CDT is still a key part of the IDE strategy for a huge handful of platform vendors, especially in the embedded and mobile space. And we have nearly 600,000 downloads of CDT, so I assume the downloaders are being successful (or they're having disk problems and need to download it all the time, maybe). But if things were so rosy, I wouldn't be hearing all the complaints about CDT and Eclipse in general that I do.

The biggest complaint I get from the user community is how hard it is to set up CDT for their platform, especially developers using Windows. That's where Wascana comes in. There's also a variety of environments that don't come with out of the box support, like Qt and Mac Cocoa.

Commercially, a lot of what I hear is about customers who would still rather use command line tools than our commercial IDEs. That tells me two things. One, that these people just don't like change or learning new things. But more importantly, it tells me we don't provide sufficient cost/benefit for them to make the jump. And really, the benefit has to be much greater than the cost and that means not simply doing the same things you can with the command line, but taking it to a next level that an Integrated Development Environment gives you. I joke with the product managers here at Wind that we need to put the capital back in the 'I' in integrated. I'm not joking...

So to help bring the nay-sayers on board, my strategy with the CDT is to make it ubiquitous. I'd like to see as many developers as possible in the world able to used it, and like to use it. That way, when we come to them with a commercial offering, CDT in the product becomes a value point.

Ensuring the CDT works out of the box is a big part of that strategy, especially for platforms that don't have commercial support. Linux is covered very well by the Linux Tools project at Eclipse, Wascana for Windows, and I am trying to find time to get it working well for Mac (Objective-C support included). Qt is a natural for cross platform development, so is CMake and Autotools build environments. And I'm helping with CDT support for Android native development. These are things CDT should support out of the box to enable my plan for world domination :). And that's what motivates me to keep plugging away.

Wascana Lives! on Eclipse Labs

When I first heard of Eclipse Labs, I was thrilled about the idea. Having a central hosting site where we can gather all the open source projects that skirt the official Eclipse site is a great way to build visibility for these projects and a great way to promote the creation of new ones.

Well, today, Eclipse Labs is a reality. And, as I was one of the beta testers for it, I'm pleased to announce that I have moved the Wascana Eclipse C/C++ IDE for Windows Developers over to it. I really struggled with Wascana over at SourceForge where there's a low signal to noise ratio, but thanks to Eclipse Labs, it should help people find it and realize it's place in the Eclipse community.

Right now, I'd consider Wascana still beta quality, mind you all of the packages are released open source projects so I know they work. But the key behind Wascana is a p2 repository and the org.eclipse.cdt.p2 plug-in that knows how to unpack tar.bz2 files. This plug-in is part of the Helios Eclipse C/C++ IDE package so all you need to do is get that and put the URL to the repo into p2 and install away. Feel free to hop on over and take a look at the Wascana site at Eclipse Labs.

In the future, I hope to figure out an even easier way to install, possibly similar to how Subversive gets it's SVN connectors. At the very least, I'll be posting an NSIS installer containing everything you need up to the Wascana site. This should all be in place for the Wascana 1.0 release around Helios release time.

Update: As I was writing this blog, an issue I was having with the downloads have been fixed. Wascana 1.0 Beta1 is now available on the site.

Thanks to Ian Skerrett and Google for getting Eclipse Labs together. As I mentioned in the blog post I posted when I first heard of it, this is going to be a game changer. I can't wait to see what projects pop up there.

Don't guilt contributions, enable them

This is a bit of a response to Dave Carver's post versus Alex Blewitt's and a bit of a topic I've dealt with mentoring projects, and how I operate on the CDT project.

Over my years in open source, I've seen time and time again where people on projects try to find ways of getting others to come help. A common one is to beg or guilt people into contributing. "You don't like how that works, then come fix it." That's easy to say. But I've seen that piss people off way more often than it works, and it only works in rare occasions. I think you need to be sensitive to the skill set and the ability for people to come fix it. Not everyone who uses Eclipse knows how to build plug-ins for it, or has the time to do it. Do you expect them to give up their family hours to come help you out? I sure hope not.

No, my preferred approach is to create an environment where contributions are naturally welcomed. Where those who do have the skills and the time can easily and quickly fix the things that are bugging your community. Creating such an environment isn't easy and it comes down to a number of factors. Probably the biggest one is to make everyone feel a part of the team. Everyone's opinion matters. And every contribution is treated like gold, whether accepted or not.

And Alex's story is very disturbing to me. I'd rather he write about how well he and the rest of the Eclipse team have gotten Eclipse to work on the Mac.

We need a JNI helper plugin

Now that I'm back being an engineer/architect, I'm again thinking of too many projects that I want to do with the time I have. I'm getting involved in the Target Communication Framework (TCF) which has an exciting opportunity to standardize target (in this case mainly embedded targets) communication and services for the purposes of debug and data collection amongst other things.

I am also trying to make it easier to use CDT for specific platforms. Windows and Android and soon Qt are the main ones there. But I've run into problems with the complexity of CDT's build system that I need work with the community to clean up.

And there is another shiny object has caught my attention and I'd love to get time on that too. Our long term holy grail on the CDT has been to support developing native libraries for Java. The debug scenarios are scary, but I've been thinking of another area that should be a lot more attainable.

That's automating the creation of the code that JNI development requires. There's two paths. One is generating skeletal C code for Java native methods. And the other is generating wrapper Java classes for C++ classes. There used to be commercial products that did that, but I'm not sure if they're still around. And given the power of the Java and C++ parsers we have in Eclipse, and the code generation frameworks available, it shouldn't be that hard, you would think.

I think this would be a huge benefit to JNI developers, or at least me :). The interesting thing to note is that Android had the foresight to use JNI for their native interface so there's a new community who could use it. If anyone is interested in doing something like this, give me or the cdt-dev list a ping.

Mac gets no love

I should blog more. But twitter is so much faster. At any rate...

@timbray tweeted yesterday "Eclipse SPOD DIAF." After getting out my magic decoder ring, I soon learned that he was complaining about the performance of Eclipse on Macs. Apparently there were memory issues in Eclipse 3.5 Cocoa that causes a lot of garbage collection (assuming I'm interpreting that correctly). That causes the pause icon to pop up while Eclipse is locked down. The so called Spinning Pizza of Death, which is being asked to Die In A Fire, or at least so my magic decoder ring told me. Kids and their fancy lingo...

I hear that's fixed in Eclipse 3.6 and I haven't seen it in the few times I've run Eclipse Helios on Mac. But it's another episode in a long story of Mac not getting any love from the Eclipse community, or at least the contributors. The good news is that as more and more contributors are using Macs, these issues are getting addressed. But the perception has already been set free that Eclipse sucks on Macs and hopefully the Mac users are passionate about Eclipse to give it another try.

I ran into another case that confused the hell out of me last night. I was testing the new Android CDT integration I'm contributing to the Sequoyah project and had an NPE show up. So, as I do on Windows and Linux, I quickly tried to fire up my CDT workspace to take a look at the line of code the log was complaining about. You know, if you have an Eclipse running and you try to launch a second instance, it just pops up the one you have running.

From what I've been told, Mac applications are always singletons. You run one instance of the application and it's able to handle multiple documents. But that doesn't work in Eclipse because Eclipse can't handle multiple workspaces. I remember that coming up at the e4 summit as someone wanting to do that, but at the time I didn't get it. Now I do.

I imagine things like this will get solved over time (although the multi-workspace thing, I'm not sure). But it is a great example of how open source projects work. The only way features get done is if someone has a vested interest in getting it done. To date, there have been few Eclipse contributors with such an interest in Eclipse on Mac. Yes, that's changing, but pretty slowly.

Now, here comes the controversial part. What you don't see in open source much except for the few cases where projects are bankrolled by forward seeking companies with lots of money (i.e. Google) is projects investing before the need. We've known for a long time Mac was going to be important, the trends were pretty obvious. But open source doesn't work that way. The funding for development isn't strong enough to support risk like that.

Or so I think. I am curious if you agree and if you have a theory of why that is. I'm not sure how it can be changed, or if vendors who fund open source want it to change. I know of companies that don't want it to. But the companies that do easily trump that if they can figure out how.

No, I don't want to read e-mail on my dash

Ottawa has a small hi-tech community, at least relative to Silicon Valley South and all. So, of course, the talk still hasn't died from RIM's acquisition of QNX from Harman. For us ex-QNXers and lovers of the mobile space, it is good folly to try and figure out what it all means.

What it doesn't mean is that you'll see RIM bringing your e-mail into your car. Yes, QNX has a big chunk of the automotive operating system space, but I can't see how RIM fits into that, despite what most of the industry pundits have to say when they first heard the news. And frankly, I worry about how advanced applications running in your dashboard is going to impact safety. I'm not going to be catching up on my e-mail while driving, that's for sure.

No, the more interesting angle is how QNX's Neutrino operating system will look in RIM's smartphones. I don't know what's in one of those today, but my guess is that their incumbent OS is really holding them back. They have the branding to take on Apple, but I have to think there's some technical reason whey their application development stack is relatively weak.

And I think that's where Neutrino will help them. I'm not going to get into why I left QNX, but it certainly wasn't faith in their technology. The microkernel architecture definitely has advantages, and I think it's a no-brainer that they'll be able to run RIM's existing stack on it. And I have to assume that RIM is working on additional stacks to support things like native game development, much as Android has.

So I think this is an interesting twist in mobile and consumer electronics and could give RIM a boost. And for QNX, they achieve one of their long time dreams of running in handsets. And I'm glad for them. But I still think Linux and open systems is the better choice ;).

CDT on e4

I just got word of the available e4 Eclipse SDK test builds and thought I'd try out the CDT on it. The great news is that I had no build errors for the CDT base functionality (haven't tried our advanced debug views yet). And I was able to create a C++ project and build it. I had issues going into debug, but I am pretty happy on how far it has come.

There's still a lot missing, though, so there is much work ahead. And as I've feared the UI performance is quite bad, but there's a long way to go to clean these things up. I'll be keeping regular tabs on their progress and test as many of the CDT workflows as I can as the platform stabilizes.

Here's a teaser screenshot.

From Rocks Stars to Reality

"at #eclipsecon we were rock stars, now back to reality."

I was sitting waiting for my flight leaving SFO when this great tweet came across my Twitter feed. It came from Kim Moir, and hit on a very important issue that many of us committers face when working on Eclipse.

Many of us work for companies where open source is a means to an end. We continuously fight to explain the value of what we do to business managers driven by revenue and profit, where they measure the price they charge for product based on the value it brings to customers. And frankly, old school businesses struggle to understand that providing free open source does actually bring value to customers. So we are often under the microscope and under pressure to fight for something we dearly believe in.

But at EclipseCon, the world is upside down. People we meet there are very grateful for what we do. We are the experts they want to talk to to get the information they need. They are the people looking to join us on our mission working to each other's benefit creating great software. Yes, there we are rock stars, or at least the community makes us feel that way. And we dearly appreciate and are humbled by it.

It's an incredible high and one of the reasons EclipseCon is always one of the best times of my year. And, yeah, it is a bit of a depressing feeling as you start on your way home. The show has ended again for another year and it's time to go back to our quiet offices, fighting for what we believe in.

We all dream of a world where our work is appreciated there as much as it is in the community. But it is the reality we deal with year after year. And maybe why EclipseCon is such a great time as it brings us together to celebrate the fact we've survived another year. Here's to surviving again and seeing you there at EclipseCon 2011.

Next step in the Android Revolution

As everyone knows, Google has been working hard on amassing all human knowledge through their search engine, ad sense, their new DNS server, google books and many projects that haven't been made public. I was wondering what they were going to do with all that. It could be a pretty powerful tool.

Well, we finally learned today. Google has announced the next step in the Android revolution, Google Robot. They've been working on a robotics project and have Android running on a Beagleboard that animates the Android at the Googleplex. They've also been able to reduce all human knowledge onto a single SD card that is plugged into the board and the Android has come to life.

As it turns out, it's a pretty smart and powerful robot and has set it's sights on taking over all governments in the world. It's hard to argue with the strategy. At least they aren't using that knowledge for evil.

I love Android on my Nexus One. I love Android running in Google Robot. I for one welcome our new robot overlord. All hail our new benevolent leader!

Another EclipseCon in the Books

Wow, what a week. I don't even know where to start. There were a lot of old familiar faces here, there were a lot of new people who introduced themselves to me. The CDT community is thriving and I am more excited about CDT's future now than I ever have been.

The main reason for that I think is that we're starting to go beyond our basic set of features into some things you won't see in most IDEs. The big one for me that only made a little splash is CDT's new Codan static analysis framework and it's current small set of checkers. Today, CDT will detect syntax errors and highlight them. But with Codan, we can now detect logic errors. Things that have traditionally made C development hard, like finding unbalanced malloc and free's, or new's and delete's, that lead to memory leaks, can now be checked for with the appropriate checker. It's pretty new and will only be available for preview in CDT 7.0, but I can't wait to see where the community takes this.

The other big activity in CDT is our new built-in debugger that gives us the ability to debug without having to rely on an external debugger. It's also in a preview state, but companies with special debug needs that aren't being met by gdb, have an opportunity to use a debugger much more tightly integrated into Eclipse, and fully licensed EPL. And no, we're not planning on a EPL compiler, just dreaming of one :).

I am also seeing things happening on the periphery of CDT that extend Eclipse's C/C++ development beyond our traditional edit/build/debug. Tracing and profiling are maturing. Support for a "best in class" Linux IDE. Debugging for massive multi-core. It's as though we've now solved the basics and are now focusing on the hard problems, and doing it in the open. It'll be very interesting to see where things go and how we manage the community to make sure we're efficient.

Along with parallel tools and Linux communities, I'm getting more involved with the Mobile projects. It's part of my role as an Architecture Council mentor to help them out. But I think there will be some overlap between Mobile and the traditional embedded that the CDT community represents. There was some great discussions this week in that area and I'm happy with the progress they're making.

But it's time to go home and back to the grind. The CDT community and the communities it intersects with are thriving and I can't wait to see where we end up by next year's EclipseCon, same time, same place, in 2011.

Totally Pumped about EclipseCon

Well, it's coming quickly. EclipseCon for me starts with my 6 a.m. flight on Sunday in order to get to the Hyatt in time for Eclipse council meetings. EclipseCon is always a very busy week for me as there are always a few people that I want to run into and chat about CDT things. I made a conscious effort not to submit many talks this year to give me time to breath and to give others in the CDT community their time in the spotlight. It's going to be great.

The talks I am involved in are my own lightening talk on Wascana, my CDT for Windows effort that combines my work on CDT and my work with p2 to give Windows users a quick start using CDT for Windows programming. I'll be helping a few others including Ken Ryall on the CDT what's up standard talk, and Andrew Overholt with the Linux IDE long talk. And I'm involved in a couple of panels. Then we have the various BOFs that take place in the evenings including the CDT and Linux IDE BOFs. My calendar is almost full but there's enough space to meet the community and help prepare for all this.

Aside from the CDT things that I'm of course interested in, I have a couple of other things I'm looking out for. I'm curious to meet other people using p2 for their commercial install technology as we are doing at Wind River. It would be cool if we can standardize on some touchpoint actions and UI and such to share some of the work. I'll also be attending the git tutorial as I'd like to see the CDT being one of the early adoptors of git as our read/write repo, once it's ready, of course.

I'll also be getting more involved in the Target Communication Framework effort that Wind River has started and that is starting to get community interest. We'd love to work with the community to put together a standard communication framework that allows multiple tools to interact with targets of varying sizes and shapes. Martin O from Wind is giving a talk on that and we'll be holding a meeting somewhere along the way to plan out the next steps.

And, of course, there's the bar, the social focal point of every EclipseCon we've had, except maybe the DisneyLand one. We were so new then :). This is where the community cuts down the walls between the projects and we become the one bigger Eclipse community. It's quite a site to see the CDT guy talking to the XML Tools guy wondering what the Xtext guys are up to :). It's a blast. And I hope to see you there. And if you see me first, please stop me and say hi. That's what I'm there for.

The Patent System is a Mess

I used to believe that this whole patent system was just a cold war. Everyone was patenting everything they thought of, mainly in case they got sued for infringement on something else, in order to counter sue. Then they'd go meet in a bar somewhere, have a few pints and work things out.

Well, unlike the real cold war, where everyone got smart and realized there would be no winner and just gave up, (and, yeah, there was much more to it than that, but humor me :). The software industry seems to be about to implode on itself.

Yes, I'm talking about Apple suing HTC. I am not a lawyer. I am only a humble software designer, but if I was afraid before of getting sued for accidentally borrowing someone's idea in my own design, now I'm terrified. Today I was working on a wizard to import existing code into the CDT. I bet someone patented that already and I'm freakin' scared.

O.K. I'm being over dramatic about this. And I'm sure peace will reign. But something's got to be done about this system. There are way too many common sense ideas getting patented. And it's killing the drive to produce great products. The iPhone was really cool when it first came out. But as we got our hands on it and used it for a while, we realized that is wasn't really anything special, and the user interface ideas they had are easy to implement. So was it worth a patent? Was it really an invention?

The telephone, electricity, the car, those were great inventions worthy of patenting. But patenting to what end. If whoever owns the patent to the automobile sued everyone who figured out how to make one, where would we be today? And isn't that a monopoly? Where's the fine line between protecting the rights of the inventor, and protecting the rights of the consumer?

At any rate, I'm just a humble software designer who's getting very frustrated about having to be a part time legal clerk to do my job. I just want to innovate. And you know what. If someone comes up with the same idea and doesn't use my implementation. Good on them. There are lots of smart people in the world. Does the patent system help them, or does it make them so frustrated they decide to go server hamburgers instead. (Melodrama hat off ;)

Knowledge == value

I heard some wise words yesterday in a discussion over a new business venture. "If you know more than your customers and you know more than your competitors, you should be fine."

I've really been struggling to come up with a justification on how you can still make money in the tools industry. There is such a rich set of open source freely available tools that developers can easily download and adopt. And no matter how you spin it, those free tools cut into the value proposition of a traditional commercial tools offering.

But that's why it so important to focus your investment on unique knowledge areas that you have or can acquire. Developers still face very difficult problems that free and open source tools won't solve for them. And that's where the money is still to be made.

But the converse is also true. For a complete tools solution, you still need the entire stack. And for those things where knowledge is common place, which have the least value (sorry), working in open source is really the only way to keep the costs down to match.

Engineering is expensive. Having the right open source strategy is critical to ensure your business is successful. And that strategy needs to be continuously updated. What you might think is unique knowledge today could become common knowledge tomorrow and you need to have a transition plan to keep above the line. It's certainly a lot of work, but it needs to be done.

Eclipse Rules, Deal with it

That's about all I have to say about that. Eclipse is what you make of it. If you want change, get in, get your hands dirty, and make change happen. I've been able to do that over my years at Eclipse. We have a pretty decent C/C++ IDE thanks to the hard work of the community. We've been able to work with the platform team to push a number of changes down into the platform, debug especially, and now with the flexible resources, and more to come.

It is a lot of work, but then no one gets a free pass. If you're passionate about helping with Eclipse's success, you can make it happen, if you have the desire to work at it and work with our great community. If you are just going to complain about things from the sidelines, you shouldn't expect much sympathy. And that's all I have to say about that.

Understanding C/C++ Build Systems

My main development task on the CDT these days, when I get to tear myself away from other interesting things I'm looking at, is on a prototype of my dream CDT build system. I was involved in CDT's managed build at the very beginning but let others run with it as I concentrated on the CDT's source navigation features, parsers, and indexer. Now that those things are in really good shape and debug has a lot of good people working on it, I thought I'd take another look at build.

(BTW, I'm back working mainly on Eclipse open source these days after two fun years of working on commercial p2-based installer technologies)

Probably the biggest change over the 5 years since my first foray into build is that there are a lot of managed build systems out there now. Everyone seems to agree that writing Makefiles is hard but that there are patterns that can be deduced and can be codified in Makefile generators.

One of the earliest examples of that was the autotools used on most gnu projects. These tools generate configure scripts which then generate Makefiles and header files for given run-time configurations. The guys at Red Hat have a pretty good integration for autotools with CDT projects as a part of the Linux Tools project. But I know Jeff had a hard time putting the integration together and I hope to make that much easier.

There are others out there as well. CMake is very much like autotools, but a little more general and less gnu specific. It can be used to generate Makefiles for Microsoft's nmake and Visual C++ for example. There is an Eclipse editor for the CMake input files but it would be nice to be able to cleanly integrate it into CDT's build system.

Probably the biggest one on my radar is Qt's qmake Makefile generator. It's specific to Qt's structure, but does a great job of managing the build system for Qt projects. As Qt becomes more popular, especially in the device community with Maemo and now Meego along with Symbian and Qt's desktop offerings, it's important that we provide good support for it.

Along with CDT's existing build support for user provides builds (good ol' Standard Build), and CDT's Visual Studio-like managed build which has both a Makefile generator and an internal implementation of something like make, I think we need to be open to different types of build systems for the CDT. This is especially true for existing commercial products that have their own build systems created for their own specific needs.

It's my firm belief that the growth of the CDT, including into the commercial space, requires that the CDT be as similar as possible across all these different instantiations of it, both open and free and commercial. That way users can leverage what they learn from one instance and apply it to the next. Build has gone in many different directions, but I hope to try and bring at least a little unity to what is otherwise a bit of a mess.

Mapping the Mobile Platform Landscape

I just spent my lunch time going through the Maemo forums to get a sense on how that community is reacting to the announced merger of Maemo with Moblin to form MeeGo. Many of them aren't taking it well, but I think that's more about fears of the uncertain future than anything real. And it's happening even with assurances that things will be pretty good for them in the end. At the very least it's a great place for this community manager to see different community management strategies at work.

Community angst aside, I was pretty sure this merger was inevitable. The underlying packages that these two Linux distributions were using were very similar so the end distribution will be easy for app developers to adapt to. But there are a few differences in vision, which will actually affect Moblin developers more, especially the focus on Qt. In the end they seem to be making the right technical choices so I think it'll work out well for everyone.

But this merger is a disturbance in the force and it's probably time to take another look at the choices of platform. Here are my current thoughts on each, again from an app developers perspective, not a platform vendors one:

• iPhone - by far the biggest ecosystem, despite being closed, single vendor. The great API and promise of riches still attracts app devs.
• Android - up and comer. Pretty good Java API but I'm still awaiting on a great native API to propel Android. Open(-ish), runs on many handsets, and people are getting it to run on different devices and architectures too including MIPS and x86.
• Symbian - now open. From what I hear and saw in passing, the API is pretty poor, but Qt will fix that. Not sure about new device wins, though.
• Windows Phone 7 - closed but powered by the Microsoft machine. The Windows API is generally pretty poor, but people put up with it to ride the wave. Don't count Microsoft out yet.
• Palm - struggling ecosystem, great Web-based API, but not sure that was the best strategy to win app devs.
• MeeGo - not a big fan of the name, but the main GNU/Linux platform in the bunch (Android is Linux kernel only, Palm Pre is very linux, though). Qt is a great API. Promises multi-device and support for both ARM and x86. Could be a contender.

At any rate, it's a big list and all of them are strong enough to consider, which is going to make an app developers life a bit of a hell for a while. iPhone is the clear leader and I don't see that changing. Depending on what devices MeeGo end up on, it could take a bite out of Android. And, Windows Phone, it's hard to count Microsoft out. Symbian still leads by volume, and Palm can make a fight out of it if they provide a good native API.

As I keep saying, it's a great day to be a software developer with all these great technologies to learn. And it really is my hope and plan to make Eclipse-based IDEs the choice for all of these. If you hope to reach the largest audience, you'll need to target more than one mobile platform and being able to use the same IDE for all will be a big win for mobile app developers.

OK, Eclipse, you have 3 seconds...

Interesting enough, I had a couple of different conversations over the last couple of days on the topic of "What do we still need from Eclipse for it to be successful". The context of success is the areas I work in of course, the CDT user space and Linux and Embedded in particular. Here, as I've blogged many times before, we still face an up hill battle to get developers to use Eclipse for their IDE.

From what I can see, it seems to come down to performance and start up performance in particular. Our users can easily and very quickly bring up vi to edit their code, run make to do a build, and fire up gdb to debug. That's the workflow they are used to and their first reaction to being introduced to Eclipse CDT, which does a great job of wrapping this workflow, is "man that took a long time to start up."

Start up performance isn't all of the story. Many of the workflows in Eclipse are pretty foreign to them as well, but right now I'm focusing on the performance issue and whether there is anything we can do about it. I know there have been task forces over the years that tried to address it. I remember getting bugged about the CDT running at start-up. So if you have any information about the progress of those I'd be interested.

I guess to make the problem even more serious, we are getting compared with other IDEs, like Qt Creator and Visual Studio, which take maybe half the time or less to start up than Eclipse does. And it's hard to justify to potential customers and users why that's OK. It's something that's starting to get critical and we need to find an answer.

So, the challenge is, can we get Eclipse to start up in 3 seconds, about the most users will notice, a guideline I've used for other UI operations over the years. And it's not just an objective. It's time to start treating it as a hard requirement. People wonder why I'm a little negative on e4, this would be one of the reasons. My users need start-up performance addressed. And that will require a pretty radical change in thinking that will be at odds with many in the community.

But we need to start having the conversation. I'm looking forward to reading your comments. Please let us know what you think pro or con, or even potential solutions. The one I got from twitter that I like the most is rewriting Eclipse in C++. But I've said that before. Anything more practical?

Running to be YOUR Committer Rep

We're out of the gate with the Eclipse Board of Directors election and I'm running to be a Committer Representative. You can check out myself and the other candidates and our platforms over at the Eclipse election site, http://www.eclipse.org/org/elections/nominees.php.

My platform is simple. My biggest concern as I've documented on my blog a number of times over the years is how to get more contributions into Eclipse projects. We often complain of being starved for resources. Even this week on the cdt-dev list, we're struggling to get our new debug framework into good enough shape that it will attract further contributions. The community is coming together and rising to the challenge, but it would be great if it was easier to get more people involved. The more contributions you get the more everyone benefits.

To me so much of the answer lies in ways to simplify the path for individual contributors to get code changes upstream into the Eclipse repositories. Many are unable to get employer approvals to get committer status, but we should still be able to leverage their talent. Distributed source control is a great start, allowing downstream developers to work on their features, allowing committers to see and review their work and then push that work upstream, all while meeting the Eclipse IP processes that are so valuable to our membership. We need to make sure we continue the work to complete that infrastructure, and that the Foundation staff have the necessary resources to make it happen, and that we make the necessary changes to the Eclipse processes to make it simple.

I'll blog about other ideas over the upcoming days, and hopefully earn your trust enough to vote for me. As Ed put it, my approach to this blog tends to be edgy. But that's a facade I put on it to drive my ideas home. If you take a look at my work on the CDT, you'll see I try hard to be pragmatic. I present my ideas and always consider not only the ideas of others, but try to understand their needs as well to make sure we have a consensus from which we can all benefit. It's a lot of work there, and I expect it to be an even bigger challenge on the board. But after 7 years of active involvement in the Eclipse community, I feel I'm ready.

It's all about the App Developer

In case you missed the news, Symbian has achieved it's goal of being a fully open source operating system. Before I start, I have to congratulate Lars Kurth (former CDT guy) and the gang at the Symbian Foundation. It's an incredible effort to take a commercial product and clean it up to be consumable under an open source license. To finish ahead of schedule is a tribute to the passion and dedication the Symbian guys have for this new direction. Very cool.

But as much as I appreciate the work they did, I do worry how well it'll succeed. Yes, I'm open source guy and am a huge fan of open source projects and working with diverse communities coming together for a common goal. But at times, I don't think it's enough in order to be successful, especially if you are in the platform business.

Funny enough, while I was calling people "Apple Fanboys", someone called me a "Microsoft Fanboy" (I didn't even know it was possible for someone to be a Microsoft fanboy). But yeah, I appreciated how Microsoft built up their app developer ecosystem. Even though it's all closed, Windows is still massively successful, thanks mainly to the apps people build for it. The same is true for Apple, obviously. There's a reason why 150,000 iPhone apps headlines their marketing material.

The important difference I'm starting to realize is that open source platforms appeal to platform developers, the guys that port the platforms to new devices. Having an open source platform helps get you on to more and more devices as the barrier to entry is much lower, or at least the run-time royalties are much lower.

But it's applications that drive device sales and application developers are a different bunch. You need a great set of tools and a great set of APIs and a great ecosystem with promises of riches to appeal to application developers. And that's independent from how open your platform is I'm afraid.

With all these mobile platforms entering the mainstream, it's a big fight for app developer mindshare right now. And that's a much bigger fight than for platform developers. Either way, it's a great day to be software developer!

iPad, iShmad

I was just having a conversation with a colleague over Twitter on the merits of iPad and Apple's A4 SOC that powers it. I, for one, am not an Apple fanboy. He is, so it makes for good fun. So when he's glowing over the "fascinating" A4 chip Apple is producing, it's easy fodder to point out that there are many SOCs out there that pretty much do the same thing. And I'm inclined to believe the pundits and I don't think it really is that fascinating at all unless you find good power management fascinating.

The main reason I'm not an Apple fanboy is because of Apple's strategy of locking in the developer. If I could build iPhone apps from my Fedora Linux laptop, then I'd be all over it. But I can't, and as the CDT Mac crowd knows, I don't have a Mac to use as a development environment for iPhone or CDT, and I'm not interested in putting my own personal finances towards one. There's nothing on the Mac I can't do using Windows or Linux, so I can't justify it.

Now, aside from the incredibly crude yet funny activity on Twitter about things the name 'iPad' reminded people of, I found the iPad keynote to be a bit of a yawner. Yes, it looks like a nice manifestation of the tablet format we've been speculating about, but that's all. It's nice. It certainly isn't revolutionary, unless you count being successful in the tablet business as revolutionary, and there still isn't proof that'll be the case. Mind you, if the fanboys put their money where their collective mouth is, it should be a slam dunk. And that's the credit I do give iPad, it does validate the tablet form factor.

The big difference now compared to when Apple did launch it's revolutionary iPhone is that there is a lot of other noise in the tablet space right now and even similar product announcements (Similar products that is, nothing compares to the hype machine behind Apple's announcement). Check this article for a list of 9 iPad alternatives. All fine devices in their own right.

I think Android makes a great competitor for Apple's mobile devices. I am an Android fanboy because I can develop Android apps on my Fedora laptop and my Windows machines at home, and yeah, if I had a Mac, I could build Android apps from there too. They give you a pretty good SDK to work with on any platform you like.

I'm also keeping an eye on Moblin as Intel enters this arena. It should enable a similar development experience, although purely native instead of Android's Java/Native stuff I have to jump through. And it is real Linux which lets me use the same SDK to build desktop Linux apps.

So Apple fanboys, enjoy the show, go put your money into the coffers at the church of Steve Jobs. I'm just glad it isn't the only show in town.

Doug's Open Source Manifesto

I've done a lot of thinking lately about why companies should invest in open source. We complain about the "takers" as an Eclipse committer community; you know, the companies that take advantage of the hard work we put in never to see that hard work reciprocated. Complaining doesn't help. We need to be able to sell them on the need to contribute. Yes, need, and I think I am starting to understand the whole thing. So here's my "Open Source Manifesto" for what it's worth and I'd love to hear what you think in the comments below. You may know all this already, or maybe I'm totally off base, but we need something like this.

Open Source Software is an Asset

I wonder if anyone has counted up the number of lines of code of software that sits out in the interweb free for use by anyone, restrictions or not. Companies go through to great lengths to protect their proprietary code as they would any other asset. Well all that open source software out there is also your asset if you chose to use it. Protect it, manage it as you would any software you have available for your product. And you can bet it's worth much more than any software you have or could ever build in house.

Open Source Developers are Business People

Sure there are a lot of projects that are run by hobbyists or students, but the biggest projects, the most important projects out there have far more corporate employees contributing and managing them than not. And for the most part, they're easy to deal with as good partners in business can be. Depending on how you participate, you can have much more influence on open source projects than you think, sometimes even more than you have over internal projects.

Influence by Contribution

This is the key to successfully managing the asset. If you want influence on an open source project, you need to contribute to it. And the math is simple. The more you contribute, the more influence you have. But you don't need to go crazy and fully take over a project to be successful with it, and for the most part you don't want to. Open source projects are quite open to contributions. Take advantage of that.

Take your place in the Community

One of my biggest thrills in open source is working with great developers from other companies. You may be tempted to fully control a project, but if you want to benefit from some of the greatest minds in our industry, you need to let others drive the boat once in a while too. Understand your place in the community and how the things you do influences it, both good and bad, and make good decisions about how you participate.

Have an Open Source Strategy

Don't just wing it in open source. Part of being able to acquire influence on a project is building up respect and trust with the rest of the community. If you are a fly by night organization that jumps in with big plans without having a track record, it'll be hard to achieve that. Invest in open source with a long term plan in mind. Come, stay a while, build up the trust, and you will be rewarded at the end of the day.

Don't compete with Open Source

If you have a product that competes with an open source offering, or maybe offers something similar just a little bit better, don't kid yourself. Sooner or later the open source offerings will become better than yours. Again, it comes down to the investment and the fact that there's more corporate investment going into open source than you can do yourself. And if there isn't now, there will be. The momentum is unstoppable at this point.

Understand your value proposition

At the end of the day, customers are looking for good value in their software purchase dollars. They don't care how you built that software or even if you did. They just want you to be the best supplier of that software in the business. Sure, they'll threaten that they can get good open source software for free, but if you focus on making their adoption of that software easier, provide things that the community doesn't, you can add value, lots of value. Open source projects focus on source code. A good software company knows there's more to good software than just good code. There's lots of room to make money here, and in turn it should be easy to justify the investment you do make in open source.

Well, that's all I can think of for now. But I'd like to continue evolving this manifesto into something all us open source contributors can bring to the companies out there and help them justify making the same investment in open source we are, to join in the fun and the profit.

CDT Needs a GDK too

A lot of people who come to the CDT have used Visual C++ in their lives so we strive to make certain aspects of the CDT familiar to them. That requires taking a look every now and then to see what things are like over there, and with the free Visual C++ Express, it's interesting to see how the other side lives.

I sauntered over to the Visual C++ Express web site and I guess it's been a while since I've been there, or maybe it just struck it differently than it has before. The web site promoted Visual C++ Express as Simple, Fun and Easy to Learn. We can argue whether VS is simple and easy to learn, but it was the Fun part that hit me as a great idea. This section highlighted Game Creators GDK, Game Development Kit. I can see how that would attract VC Express's target audience, prospective future full Visual Studio edition customers.

We need something like that for the CDT. We need to make the CDT Simple, Fun, and Easy to Learn. Get the kids to use it and when they become future prospective clients of CDT vendors, they'll be quick to adopt their CDT based tooling. First we need to fix some of the major usability issues with CDT. A lot of CDT users will argue that it's not particularly Simple and Easy to Learn and that needs to be addressed.

But the Fun part comes from using the CDT to build something fun. And as Microsoft has figured out, game development is fun. I've already started looking at what would be needed for a GDK for Android and there are a few open source components that can go into that. And make it cross platform for Windows, Mac, and Linux and it's variants like Moblin and I think we could have a GDK for the CDT that would be a great injection of Fun into Eclipse.