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 :).
Friday, May 21, 2010
Friday, May 14, 2010
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.
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.
Thursday, May 13, 2010
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.
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.
Thursday, April 29, 2010
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.
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.
Wednesday, April 28, 2010
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.
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.
Tuesday, April 20, 2010
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.
@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.
Monday, April 12, 2010
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 ;).
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 ;).
Friday, April 09, 2010
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.
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.
Tuesday, April 06, 2010
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.
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.
Thursday, April 01, 2010
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!
Friday, March 26, 2010
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.
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.
Thursday, March 18, 2010
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 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.
Thursday, March 04, 2010
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 ;)
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 ;)
Tuesday, February 23, 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.
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.
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.
Monday, February 22, 2010
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.
(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.
Tuesday, February 16, 2010
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:
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.
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.
Thursday, February 11, 2010
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?
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?
Tuesday, February 09, 2010
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.
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.
Monday, February 08, 2010
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!
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!
Subscribe to:
Posts (Atom)