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!
Monday, February 08, 2010
Friday, January 29, 2010
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.
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.
Friday, January 22, 2010
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.
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.
Friday, January 15, 2010
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.
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.
Tuesday, December 29, 2009
Looking Forward to 2010
Last year I put out predictions for 2009. But I don't want to look like I know things that I really don't. So instead, for 2010 I'm going to list the technologies I am most looking forward to seeing come to fruition this year. As a tools developer, it's important to know what things your users will use your tools to build, and for that you really need to know what's going on in the industry. So here we go. I'm also going to forgo my standard 4 or 5 paragraph length so excuse the extra long post. It's just easier for me if I capture them all at once.
Mobile
I blogged about this in the past, but what I see happening in the mobile space reminds me so much of the revolutionary days of the early PC market, back in the late 70's and early 80's when the ability to program computers came to our homes. The same is now happening with mobile devices, all of which have freely available tools and SDKs and anyone can, and is, writing applications for them. And a rare few are even making money at it. It's a race to see who wins and despite the early lead by Apple, it's not entirely obvious to say who will.
In 2010, the momentum will continue to grow. Tablets will be the next battle ground. They should be in the 7 to 12 inch screen size range making them more useful for web browsing than smartphones. They may or may not have a keyboard so we'll have to get used to using soft keyboards with these things, although, there are rumors of patented technologies that should make it easier. And I expect the power of the SOCs used to build these will grow to make them great little gaming machines.
My main interest in this area is Android. I expect to see Android on more and more of these devices. Right now, I find the Android SDK (including the native development kit) weak for gaming and multimedia and hopefully that will be addressed this year. If it is, it will be a real challenger to iPhone.
New Linux UI
Moblin is currently leading a revolution in the Linux GUI environment space. I think it really brings Linux to the masses with a very clean social networking focused interface. Hopefully we'll see a wider deployment of it this year, especially on netbooks. But I expect they'll continue to push it down into the MID space to challenge Android and iPhone there.
The main reason I like Moblin is that unlike Android it really is Linux and uses the same SDK set that you have on Linux desktop. It's the best hope for seeing applications that are easily ported between the desktop and mobile devices, other than web apps, of course.
The other advantage of being Linux and being open source, is that the underlying library that drives the UI effects in Moblin, i.e Clutter, is available to the desktop programmer too. I am very much looking forward to what the Gnome gang have planned for it in their upcoming Gnome Shell 3.0. I am hoping that this and other changes to Gnome for the September 3.0 release will be a real game changer for desktop Linux.
Blender 2.5
What the heck is Blender? And why is a C++ hack like you interested in it? Blender is an open source 3D modeling tool. No, not software modeling, but the real 3D object modeling that you use to build games and simulations. I've been watching the game development industry mainly because I'm a geek with an insatiable curiosity on how developers build things. Building games is one of the hardest computer science problems around. That and you need great artists to make great games. It's a very cool mix of art and science. And the artists need tools too.
The Blender community is a rich mix of that and it's been fun to watch them. The new version of Blender coming out this year is a much needed rearchitecture and a bit of a reinvention of themselves. It looks to be much easier to use and I expect it'll become quite popular. Mix that with the open source software development tools we're doing at Eclipse and I see a much lower entry point for people wanting to join in on the fun.
High Performance Computing
HPC is another technology that I see inching towards the masses. The hardware that the graphics card vendors are putting out is reaching dizzying heights of multi-processing. As the tooling for these cards improves, this power will be more and more accessible to the every day programmer and it'll be very interesting to see what they build with it.
C++0x
I'm not sure whether C++0x will reach standardization this year, but I expect to see more and more of the spec implemented in GCC and other compilers. There are a lot of important new features here for C++ that will greatly improve the productivity of C++ programmers. Will it be enough to fend off the continuing progression of developers to less capable languages? I don't think so since it's still a pretty complicated language. But it should make it more appealing for those that need the power of C++.
Open Source Wins
I usually get called the "Open Source Guy" at work by those more focused on business. But I will continue to champion the need for open source software as a key element of any software business strategy. Why? Because software is damn hard to build and going it alone continues to carry a high risk of failure. If there are opportunities to work in a community, to share in that risk, and to spread out the cost so you aren't covering all of it, how does that not make sense?
At the end of the day, customers care that you give them great solutions, they don't care how you build it. If you ignore all the great work that's going on in the communities, you'll need to keep ahead of that to ensure that they see you as the best provider of those solutions. That doesn't mean competing with open source, that means embracing it and leveraging it to keep your customers happy at a reasonable cost.
Over the years, we've seen companies that have slowly embraced this strategy. Some have a ways to go before they totally get it. Notice that none of the technologies I see as industry changing are coming from Microsoft. But they are keeping a close eye on what's happening in the communities and the little test balloons they've sent over the last year will continue. And I take that as a sign we are right.
Well, that's all for now and thanks for sticking with me to the end. 2010 is going to be a great year for software development. We seem to have broken free from the shackles of the doldrums we've been in since Windows took over our world. It'll be very interesting to see where we end up at the end of the year, but it promises to be one hell of a ride.
Mobile
I blogged about this in the past, but what I see happening in the mobile space reminds me so much of the revolutionary days of the early PC market, back in the late 70's and early 80's when the ability to program computers came to our homes. The same is now happening with mobile devices, all of which have freely available tools and SDKs and anyone can, and is, writing applications for them. And a rare few are even making money at it. It's a race to see who wins and despite the early lead by Apple, it's not entirely obvious to say who will.
In 2010, the momentum will continue to grow. Tablets will be the next battle ground. They should be in the 7 to 12 inch screen size range making them more useful for web browsing than smartphones. They may or may not have a keyboard so we'll have to get used to using soft keyboards with these things, although, there are rumors of patented technologies that should make it easier. And I expect the power of the SOCs used to build these will grow to make them great little gaming machines.
My main interest in this area is Android. I expect to see Android on more and more of these devices. Right now, I find the Android SDK (including the native development kit) weak for gaming and multimedia and hopefully that will be addressed this year. If it is, it will be a real challenger to iPhone.
New Linux UI
Moblin is currently leading a revolution in the Linux GUI environment space. I think it really brings Linux to the masses with a very clean social networking focused interface. Hopefully we'll see a wider deployment of it this year, especially on netbooks. But I expect they'll continue to push it down into the MID space to challenge Android and iPhone there.
The main reason I like Moblin is that unlike Android it really is Linux and uses the same SDK set that you have on Linux desktop. It's the best hope for seeing applications that are easily ported between the desktop and mobile devices, other than web apps, of course.
The other advantage of being Linux and being open source, is that the underlying library that drives the UI effects in Moblin, i.e Clutter, is available to the desktop programmer too. I am very much looking forward to what the Gnome gang have planned for it in their upcoming Gnome Shell 3.0. I am hoping that this and other changes to Gnome for the September 3.0 release will be a real game changer for desktop Linux.
Blender 2.5
What the heck is Blender? And why is a C++ hack like you interested in it? Blender is an open source 3D modeling tool. No, not software modeling, but the real 3D object modeling that you use to build games and simulations. I've been watching the game development industry mainly because I'm a geek with an insatiable curiosity on how developers build things. Building games is one of the hardest computer science problems around. That and you need great artists to make great games. It's a very cool mix of art and science. And the artists need tools too.
The Blender community is a rich mix of that and it's been fun to watch them. The new version of Blender coming out this year is a much needed rearchitecture and a bit of a reinvention of themselves. It looks to be much easier to use and I expect it'll become quite popular. Mix that with the open source software development tools we're doing at Eclipse and I see a much lower entry point for people wanting to join in on the fun.
High Performance Computing
HPC is another technology that I see inching towards the masses. The hardware that the graphics card vendors are putting out is reaching dizzying heights of multi-processing. As the tooling for these cards improves, this power will be more and more accessible to the every day programmer and it'll be very interesting to see what they build with it.
C++0x
I'm not sure whether C++0x will reach standardization this year, but I expect to see more and more of the spec implemented in GCC and other compilers. There are a lot of important new features here for C++ that will greatly improve the productivity of C++ programmers. Will it be enough to fend off the continuing progression of developers to less capable languages? I don't think so since it's still a pretty complicated language. But it should make it more appealing for those that need the power of C++.
Open Source Wins
I usually get called the "Open Source Guy" at work by those more focused on business. But I will continue to champion the need for open source software as a key element of any software business strategy. Why? Because software is damn hard to build and going it alone continues to carry a high risk of failure. If there are opportunities to work in a community, to share in that risk, and to spread out the cost so you aren't covering all of it, how does that not make sense?
At the end of the day, customers care that you give them great solutions, they don't care how you build it. If you ignore all the great work that's going on in the communities, you'll need to keep ahead of that to ensure that they see you as the best provider of those solutions. That doesn't mean competing with open source, that means embracing it and leveraging it to keep your customers happy at a reasonable cost.
Over the years, we've seen companies that have slowly embraced this strategy. Some have a ways to go before they totally get it. Notice that none of the technologies I see as industry changing are coming from Microsoft. But they are keeping a close eye on what's happening in the communities and the little test balloons they've sent over the last year will continue. And I take that as a sign we are right.
Well, that's all for now and thanks for sticking with me to the end. 2010 is going to be a great year for software development. We seem to have broken free from the shackles of the doldrums we've been in since Windows took over our world. It'll be very interesting to see where we end up at the end of the year, but it promises to be one hell of a ride.
Wednesday, December 23, 2009
Reviewing "Predictions for 2009"
I spend a lot of my time thinking about the future. As an architect, that's probably the biggest tool in your tool belt, a crystal ball. The best designs are the ones that can be used now and a year from now.
Before I blog about what I think will be important things to look out for in 2010, I'd like to review what I said last year about 2009. If it turns out I was totally wrong, then you can take my 2010 predictions with a grain of salt, as you should anyway. So here we go.
2009: The Year of the GPGPU
Well, I'm not sure it was as big as I thought it would be, but we're certainly seeing a lot of momentum behind ATI and Nvidia's monster graphics cards come computing devices. We're still fighting software demons. Nvidia is still pushing it's own CUDA over the "standard" OpenCL that ATI seems to be more on side with. But if you see what some of Nvidia parters are putting together with their Tesla boards, you know the time is soon.
2009: The year of WebKit
While not very visible, WebKit is becoming the standard browser platform for devices including iPhone, Android and Palm Pre, along with the existing desktop browsers, Apple's Safari and Google Chrome. But if you've ever tried to use Chrome as your default browser, as I do, you still run into a lot of web sites that don't render well on it, or AJAX sites that don't even work. Even our EclipseCon submission system had trouble with Safari (although it seems to work fine in my Chrome on Fedora). No, it's actually looks like 2009 was the year for Firefox which is now the most popular browser according to something I read the other day.
C++0x won't be C++09
Now, I already knew that when I wrote it. If C++ creator Bjarne Stroustrup doesn't think it'll happen, it likely won't. I'm even having doubts it'll be C++0a (or C++10, I guess). But I hope it comes soon since it has a lot of great things that C++ developers need that a lot of other languages already have (like lambdas). The good news, is that we've started work on supporting C++0x in CDT's parser. It's going to take a while so it's important we start now.
So all-in-all, it wasn't a total failure. But then, I think I was probably stating the obvious at the time. There were no shockers, but it was fun to do. I'll give my thoughts on 2010 just before the New Year so stay tuned.
BTW, I'd also like to share my best wishes for the holiday season with you all. It's a time for reflection and I'm sure I'll do my share. 2010 is going to be a big year for me and I'll need to prepare. Merry Christmas to all!
Before I blog about what I think will be important things to look out for in 2010, I'd like to review what I said last year about 2009. If it turns out I was totally wrong, then you can take my 2010 predictions with a grain of salt, as you should anyway. So here we go.
2009: The Year of the GPGPU
Well, I'm not sure it was as big as I thought it would be, but we're certainly seeing a lot of momentum behind ATI and Nvidia's monster graphics cards come computing devices. We're still fighting software demons. Nvidia is still pushing it's own CUDA over the "standard" OpenCL that ATI seems to be more on side with. But if you see what some of Nvidia parters are putting together with their Tesla boards, you know the time is soon.
2009: The year of WebKit
While not very visible, WebKit is becoming the standard browser platform for devices including iPhone, Android and Palm Pre, along with the existing desktop browsers, Apple's Safari and Google Chrome. But if you've ever tried to use Chrome as your default browser, as I do, you still run into a lot of web sites that don't render well on it, or AJAX sites that don't even work. Even our EclipseCon submission system had trouble with Safari (although it seems to work fine in my Chrome on Fedora). No, it's actually looks like 2009 was the year for Firefox which is now the most popular browser according to something I read the other day.
C++0x won't be C++09
Now, I already knew that when I wrote it. If C++ creator Bjarne Stroustrup doesn't think it'll happen, it likely won't. I'm even having doubts it'll be C++0a (or C++10, I guess). But I hope it comes soon since it has a lot of great things that C++ developers need that a lot of other languages already have (like lambdas). The good news, is that we've started work on supporting C++0x in CDT's parser. It's going to take a while so it's important we start now.
So all-in-all, it wasn't a total failure. But then, I think I was probably stating the obvious at the time. There were no shockers, but it was fun to do. I'll give my thoughts on 2010 just before the New Year so stay tuned.
BTW, I'd also like to share my best wishes for the holiday season with you all. It's a time for reflection and I'm sure I'll do my share. 2010 is going to be a big year for me and I'll need to prepare. Merry Christmas to all!
The path to a successful e4 introduction
The last time I blogged my thoughts on e4, I got quite a storm back at me. I don't have much against e4, and frankly, I'm not to concerned about it. I am the C++ guy and in my opinion, we should be making tools and libraries to make rich client applications easier to build in C++, which is what most rich client apps are built with anyway. But while a lot of what e4 is surrounds innovation around RCP apps, the intention is that it should go beyond that. We should be able to leverage e4 in our tools.
My fear, confirmed by many, is that the projects won't invest in e4 to ensure it gets adopted by the tools on the Eclipse trains. But, it's not really that. It's that the vendors that pay the committers working on those projects aren't interested enough to invest in it. All the begging and pleading won't really change that. In my years of open source experience, I've only seen that work when there was an obvious need that was going unfulfilled. I'm pretty sure that's not the case with e4.
So if we want e4 to succeed, it's up to the community to make it happen. In fact, I've challenged the Eclipse Architecture Council to lead the charge. If we believe in this architectural change and are sold ourselves that it needs to succeed, we need to take on the task of selling it to others, especially the vendors from whom we need approval. It should be what the Architecture Council is about.
How we do that? We need to show e4 running. In particular, we need to show prominent projects from the train running on e4, if not the entire train. And, of course it needs to work well and be easy to do, i.e. cheap. That requires a really good compatibility mode for e4, which is promised by the e4 team. And we need volunteers to do the builds, report bugs, and fix them.
"Build it an they will come" only works in baseball movies. Nothing sells a new idea like showing it in action and proving how easy it is to adopt. That will take work. Hopefully we'll get the few bodies we need to get the ball rolling and give us something to run with. If we have enough people that care about e4, this shouldn't be that difficult to accomplish.
My fear, confirmed by many, is that the projects won't invest in e4 to ensure it gets adopted by the tools on the Eclipse trains. But, it's not really that. It's that the vendors that pay the committers working on those projects aren't interested enough to invest in it. All the begging and pleading won't really change that. In my years of open source experience, I've only seen that work when there was an obvious need that was going unfulfilled. I'm pretty sure that's not the case with e4.
So if we want e4 to succeed, it's up to the community to make it happen. In fact, I've challenged the Eclipse Architecture Council to lead the charge. If we believe in this architectural change and are sold ourselves that it needs to succeed, we need to take on the task of selling it to others, especially the vendors from whom we need approval. It should be what the Architecture Council is about.
How we do that? We need to show e4 running. In particular, we need to show prominent projects from the train running on e4, if not the entire train. And, of course it needs to work well and be easy to do, i.e. cheap. That requires a really good compatibility mode for e4, which is promised by the e4 team. And we need volunteers to do the builds, report bugs, and fix them.
"Build it an they will come" only works in baseball movies. Nothing sells a new idea like showing it in action and proving how easy it is to adopt. That will take work. Hopefully we'll get the few bodies we need to get the ball rolling and give us something to run with. If we have enough people that care about e4, this shouldn't be that difficult to accomplish.
Monday, December 07, 2009
"Eclipse Labs", the Eclipse game changer
Ian hinted at it in the recent flurry on Planet Eclipse and Mike just offered an extra teaser. For me, the concept of an Eclipse forge, or "Eclipse Labs" is set to change the way open source developers see, consume, and contribute to Eclipse, and more importantly, to dramatically change the culture at Eclipse.
Everyone seems to be looking for a technical solution to keeping Eclipse relevant, e4 case in point. In the end, that's not enough. We need to grow the Eclipse community beyond it's traditional realm of corporate engineers, into what we more traditionally think an open source community should be, free. Free to work on what you want, free from someone saying no to your contributions (within reason, of course). To be free as you are when working with SourceForge, but still be a member of the Eclipse community.
I'm still waiting to hear the details on the rules and mechanisms for the Labs. But if it turns out like I think it should, ;), then I'm super pumped. Pumped enough to bring Wascana out from the freezer and make the real Eclipse C/C++ IDE for Windows that should rightfully be an Eclipse community project, not hidden out on SourceForge. That will require the Lab to ship GPL'ed software, i.e. the GNU tools, and LGPL libraries. Is Eclipse ready for that? I'm hoping.
Everyone seems to be looking for a technical solution to keeping Eclipse relevant, e4 case in point. In the end, that's not enough. We need to grow the Eclipse community beyond it's traditional realm of corporate engineers, into what we more traditionally think an open source community should be, free. Free to work on what you want, free from someone saying no to your contributions (within reason, of course). To be free as you are when working with SourceForge, but still be a member of the Eclipse community.
I'm still waiting to hear the details on the rules and mechanisms for the Labs. But if it turns out like I think it should, ;), then I'm super pumped. Pumped enough to bring Wascana out from the freezer and make the real Eclipse C/C++ IDE for Windows that should rightfully be an Eclipse community project, not hidden out on SourceForge. That will require the Lab to ship GPL'ed software, i.e. the GNU tools, and LGPL libraries. Is Eclipse ready for that? I'm hoping.
Thursday, December 03, 2009
Multi-Core Programming, Paradigm Shift Required
I just caught myself sending 4 tweets in a row on the same subject. That's probably a sign I have a blog entry topic at my finger tips.
I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.
The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.
At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:
re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).
re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).
re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).
But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."
This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.
I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.
The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.
At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:
re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).
re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).
re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).
But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."
This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.
Monday, November 30, 2009
Diversity is not the only answer
Dave Carver started it and Pascal fed the fire. If you missed it, there are confusing and highly inaccurate statistics captured by the Eclipse Foundation that measure diversity in the Eclipse projects. Stats or not, there are a lot of projects where it's clear, there is one vendor paying a very disproportionate number of comitters that work on the project. And it's not always IBM.
But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?
A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I've done and career limiting decisions I've made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.
I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.
But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?
A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I've done and career limiting decisions I've made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.
I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.
Tuesday, November 24, 2009
Linux Distros, The Great Melting Pot
I've been talking a deeper look at Fedora lately as Fedora 12 was just released and I was checking out all the MinGW cross-development packages available there. While I was there I looked across all the packages included in the "Everything" folder. I even gave eclipse-cdt a try and was impressed to see 6.0.0 there (although 6.0.1 would have been more impressive ;)). It's also impressive to see so many of the Eclipse projects represented there. And just looking at the breadth of open source content, almost every open source project I've looked at is included, including the bullet physics engine, OGRE and Irrlicht game engines, blender the 3D modeling tool, clutter and mutter and even an early preview of the new Gnome Shell.
It's an incredibly rich set of libraries and tools, and it's got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it's best effort to kill performance, I'm thinking again of going back. Windows 7 is pretty and I'm very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.
The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I've mentioned this before, but the projects really do operate as silos, even Photran and CDT and we've tried hard not to do that, it's just too easy.
But it takes a group of people with the vision and the gumption to drive that vision home. I'd like the Eclipse Architecture Council to be that but as with all things Eclipse, it's really up to committers and the vendors that pay them to make this happen. Here's hoping someone does.
It's an incredibly rich set of libraries and tools, and it's got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it's best effort to kill performance, I'm thinking again of going back. Windows 7 is pretty and I'm very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.
The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I've mentioned this before, but the projects really do operate as silos, even Photran and CDT and we've tried hard not to do that, it's just too easy.
But it takes a group of people with the vision and the gumption to drive that vision home. I'd like the Eclipse Architecture Council to be that but as with all things Eclipse, it's really up to committers and the vendors that pay them to make this happen. Here's hoping someone does.
Friday, November 20, 2009
Chrome OS, it is what it is
I guess I got caught up in all the hype over Chrome OS. It's an idea I've bounced around for years as I mucked around learning about embedded Linux. Replace the standard Linux desktop UI with only a browser and throw it on a mobile device. With everything on the web these days, or at least a minimal amount to do something useful, why not?
But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.
So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it's proper name, is.
But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.
So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it's proper name, is.
You log in with your Google account and, bang, you're in the Chrome browser looking at your Google stuff.
But it is what it is. There's no application menu, no app market, or anything like that. Everything you do is over the web. I did notice an extensions mechanism, and maybe that's how you take advantage of the native environment, maybe not.
When I had thought of a Web OS, this summer, my thoughts turned to the Eclipse Run-Time and using that in conjunction with the browser to have local apps written for the Eclipse platform. I would also think you'd want to launch 3D and multimedia content full screen, or something. But that's not what Chromium OS is. It's web or bust.
So while Chromium OS is interesting, I'm way less excited about it. I think the door is still open for a netbook Linux platform that combines local native apps with the Web experience. Moblin is certainly making strides there for the consumer space. And I've been trying out the GNOME Shell which offers an experience much like Windows 7 for the power users. This story isn't finished yet.
Tuesday, November 10, 2009
Visual Programming for Multi-Processing
I spent a little time on the weekend taking a deeper look at the Unreal Development Kit (www.udk.com), and I continue to be shocked that they are giving out all this great technology to you and me to play with. And it really blew me away when I saw their Materials editor. There's a tutorial here, http://udn.epicgames.com/Three/MaterialsTutorial.html.
Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.
This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.
To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...
Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.
This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.
To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...
Saturday, November 07, 2009
Openness Shades of Grey
Motorola's newest phones are hitting the streets and promise Android goodness thanks to the latest Android release 2.0. Now if you think of Android as an open souce platform, you may have run over to the Android Open Source Project and tried to download the 2.0 source to see how they made it.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Friday, November 06, 2009
Unreal Development Kit
Wow. Unreal Development Kit. Free. Or at least free for free content. I've always wondered how developers create content for the big game engines, id and Unreal. And now I know and I have it installed on my laptop. For free. Can you tell I'm beside myself here. Check it out: http://www.udk.com.
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
Thursday, October 22, 2009
It's Crunch Time
I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
Thursday, October 08, 2009
A Good Leader is a Good Architect
I've been whining (yeah, that's pretty much the word) a lot recently about the state of contributions to the CDT and about the struggles I face even internally to get more time to spend on open source. I've been pretty frustrated and depressed about that and it's showing in my writing.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
Monday, October 05, 2009
Android Notes and Ideas for Eclipse
Here's a few notes on things I've been doing with Android. I'm under no delusion that I can actually create an app for Android. My wife wouldn't be too happy if I spend the time it would need. But I am finding that this is a great exercise getting into the mind of a mobile developer and is giving me ideas on how to improve the CDT and the Eclipse platform.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
Sunday, October 04, 2009
No where's that open source hat?
One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
Monday, September 28, 2009
Remember PluginFest?
It's been a while since it was held. The Eclipse PluginFest was a really cool event organized by Ian Skerrett and hosted by the folks at Symbian in London. It was part marketing event and part engineering event intended to show how off the promise of Eclipse as a platform by doing some interoperability testing between the different products, focusing at the time on the embedded/mobile market. For the most part, it was a success, especially for tools up the stack like analysis and modeling tools.
But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.
But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.
The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).
I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?
But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.
But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.
The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).
I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?
Subscribe to:
Posts (Atom)