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.
Friday, March 26, 2010
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!
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.
Subscribe to:
Posts (Atom)