Monthly Archives: February 2010

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,

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!