We've had some good discussions lately in the Planet Eclipse blogosphere about whether Eclipse project should be focusing on the concerns of users or building a platform for ISVs to add their value. In the end, I conclude that you need to balance both for the sake of growth in your community. Unfortunately, though, or fortunately as the case may be, Eclipse projects are staffed almost exclusively by Eclipse members who fit more in the ISV camp. These guys need to justify their investment in the Eclipse on the bottom line. It's the nature of the business, and there's nothing wrong with that, since without it we wouldn't have the great Eclipse that we have today.
Of course, this isn't just an Eclipse thing. A lot of high quality open source projects are staffed by ISVs and the concerns are the same. Recently, chief Linux maintainer Andrew Morton has been frustrated by the focus of his development community as well. Most of these developers are employed by OEM-types who support Linux running on their platform. But a lot of users who are using "unsupported" platforms are raising bugs that these platforms aren't working anymore. How do you get your developers to focus on something their real bosses don't care about?
Well, this is a big challenge for all open source project leads. Developers contributing to open source aren't under contractual obligation to do anything. What they do work on is generally based on the needs of their employers. Yes, that's a pessimistic view because everyone I that I work with in open source is very concerned about all users of their stuff, no just the users that their bosses care about. But when tough decisions need to be made, you can be sure that the general user loses out.
So is that all there is too it. I don't think so. One thing that I think ISVs contributing to open source often don't think of is that, you're "open". Everyone can see what you're doing. Everyone can find out that your contributing to it. And if the general community starts making a fuss, especially in the media, that the open source software that they are freely downloading doesn't work for them, that can reflect badly on the open source project. That could lead to negative publicity that your customers get to see, who may in turn start questioning the quality of the product your are trying to sell them.
As I said, the ISV's need to focus on their bottom line when they consider how to invest in open source. But they need to take everything into consideration, not just the direct needs of their product, but to make sure that the integrity of the project they are building their house of cards on stays on the good side.
Monday, May 08, 2006
Wednesday, May 03, 2006
Lego Open Source
Back when I was working at ObjecTime, a real-time object oriented modeling tool vendor, we tried to convince our boss that we need to port our code generation tools to support the then new Lego Mindstorms. He thought it was a great idea but couldn't come up with the business case for it. C'est la vie. That was almost ten years ago and I had almost forgotten about it.
If you're a regular Slashdot reader you'd have seen the note about Lego open sourcing the firmware for their new Mindstorms NXT brick. Well that hooked my attention. Investigating further, I found out that this little box was a pretty powerful little unit with a 32-bit ARM7 processor with 256K Flash, 64K RAM, a second 8-bit microcontroller which I assume drives the sensors and motor controls. It has a USB for connecting the brick to a computer for downloading new firmware and programs. It also has a Bluetooth interface so you can hook up to other devices, or even cooler, have multiple bricks talking to each other.
So do you get the sense this is on my Christmas list? You betcha. Can I justify it. Well not really. But it would be very cool to have Eclipse support for this target: CDT to work on the firmware and programs in C and DSDP components for target management. Maybe I can convince Ian and Mike that they need a cool demo for next year's Eclipse booth at ESC. hmmm.
If you're a regular Slashdot reader you'd have seen the note about Lego open sourcing the firmware for their new Mindstorms NXT brick. Well that hooked my attention. Investigating further, I found out that this little box was a pretty powerful little unit with a 32-bit ARM7 processor with 256K Flash, 64K RAM, a second 8-bit microcontroller which I assume drives the sensors and motor controls. It has a USB for connecting the brick to a computer for downloading new firmware and programs. It also has a Bluetooth interface so you can hook up to other devices, or even cooler, have multiple bricks talking to each other.
So do you get the sense this is on my Christmas list? You betcha. Can I justify it. Well not really. But it would be very cool to have Eclipse support for this target: CDT to work on the firmware and programs in C and DSDP components for target management. Maybe I can convince Ian and Mike that they need a cool demo for next year's Eclipse booth at ESC. hmmm.
Tuesday, May 02, 2006
CDT in Action on Big Projects
It's pretty common knowledge now that I use the Mozilla, and lately Firefox in particular, as my main test bed for scalability testing. It's a pretty big project and I have often found issues with the CDT in this environment and we are trying to address them as we can.
I was pleasently suprised the other day when by friend John Camelon (Mr. CDT Parser) brought the following article to my attention. It was written by Robert O'Callahan who blogged last summer about the promise of using the CDT for Mozilla development. At the bottom of this new article is a list of issues with using the CDT on Mozilla, a lot of which we are still working on and will feed into our CDT 4.0 requirements for next year.
I was also pleasently surprised when I went to take a look at the install instructions for ACE & TAO, a pretty big communications framework written in C++ that users have reported problems with in the past. In those instructions are instructions on how to use the CDT to develop ACE applications. Very cool.
It's hard to see how widespread the use of the CDT is out there, at least from where I sit in here. These two examples certainly have certainly opened my eyes a little. Now back to addressing their scalability problems...
I was pleasently suprised the other day when by friend John Camelon (Mr. CDT Parser) brought the following article to my attention. It was written by Robert O'Callahan who blogged last summer about the promise of using the CDT for Mozilla development. At the bottom of this new article is a list of issues with using the CDT on Mozilla, a lot of which we are still working on and will feed into our CDT 4.0 requirements for next year.
I was also pleasently surprised when I went to take a look at the install instructions for ACE & TAO, a pretty big communications framework written in C++ that users have reported problems with in the past. In those instructions are instructions on how to use the CDT to develop ACE applications. Very cool.
It's hard to see how widespread the use of the CDT is out there, at least from where I sit in here. These two examples certainly have certainly opened my eyes a little. Now back to addressing their scalability problems...
Tuesday, April 25, 2006
New Projects 101
It's funny how we are starting to have conversations on Planet Eclipse. But, I'd like to follow up Mike's post, which was following up John Graham's post, with my own. The topic is what to focus on when starting new projects, building a good platform for ISVs, or building good tools for end users. This is something I certainly struggled with in the early days of the CDT.
My take is that what you really need to be doing as a new project is building a good community. Now what does that mean? Having happy users and happy ISVs that like your stuff and want to use it or add it to their product portfolio is certainly an important thing. Having people talk good about your project shows momentum and serves as a magnet for those who don't want to miss out on your "next big thing".
More importantly however, to the growth of a new project is attracting developers to help you work on it, and by that I mean "add code". That has certainly been my biggest challenge as the CDT project lead, but it is something that I've had some success with in the last few months, and hope to have a bit more in the next few months (if all verbal commitments turn into CVS commits :). I don't know what the magic formula is, but to my previous point, we have shown momentum with the CDT and a high profile project is certainly appealing to developers (not to mention marketing people ;).
But I think more importantly, since most of the developers working on Eclipse work for commercial vendors, you need to make sure your project can easily meet their business needs. You need to make it easy for their employees to get involved and make it easy for them to be able to leverage off their investment in your project. Having a well managed project helps, as does having a good platform for them to add value, as well as good tools to make sure their end customers are happy as well.
So, I guess that means you need everything :(. But, my point is really that you need to look at more than just what you should be working on, but also how you should be working. You need to put a business friendly face on your project to help attract vendors. As well, I think we all need to educate vendors about the business of open source product management and help alleviate their fears, which I have seen time and time again. That is something I certainly need to work on more.
My take is that what you really need to be doing as a new project is building a good community. Now what does that mean? Having happy users and happy ISVs that like your stuff and want to use it or add it to their product portfolio is certainly an important thing. Having people talk good about your project shows momentum and serves as a magnet for those who don't want to miss out on your "next big thing".
More importantly however, to the growth of a new project is attracting developers to help you work on it, and by that I mean "add code". That has certainly been my biggest challenge as the CDT project lead, but it is something that I've had some success with in the last few months, and hope to have a bit more in the next few months (if all verbal commitments turn into CVS commits :). I don't know what the magic formula is, but to my previous point, we have shown momentum with the CDT and a high profile project is certainly appealing to developers (not to mention marketing people ;).
But I think more importantly, since most of the developers working on Eclipse work for commercial vendors, you need to make sure your project can easily meet their business needs. You need to make it easy for their employees to get involved and make it easy for them to be able to leverage off their investment in your project. Having a well managed project helps, as does having a good platform for them to add value, as well as good tools to make sure their end customers are happy as well.
So, I guess that means you need everything :(. But, my point is really that you need to look at more than just what you should be working on, but also how you should be working. You need to put a business friendly face on your project to help attract vendors. As well, I think we all need to educate vendors about the business of open source product management and help alleviate their fears, which I have seen time and time again. That is something I certainly need to work on more.
Saturday, April 22, 2006
Visual C++ Express Free Forever
Well, as I first found out from Ed Burnette and as I see now at the Microsoft site, Visual C++ Express is now free forever just like the CDT. I doubt anything I've said had anything do to with their change in strategy. I had a feeling, when I first saw the one year free deal, that they were just testing the waters and would eventually remove the restriction. I just didn't think it would happen so soon.
So does that make me give up on my wish to better support Windows development with the CDT. No way! There's more to it than just C/C++ development. I think Eclipse has so much to offer Windows developers that the Express Editions of VisualStudio just don't offer. As one great example, I can't wait to exploit more of TPTP static analysis and expanding it's integration with CDT's DOM. I think there is so much we can do there to make C++ programming more reliable and is something that VisualStudio doesn't offer in any form.
So I think this announcement just makes me want to improve Windows support even more that I'm going on a personal mission to make sure it happens. As always, anyone keen on helping me with this mission, please let me know. I have a ton of work to do with my regular QNX and CDT work so I'd appreciate any help I can get. But I think this is one area that can go a long way to bring the CDT and Eclipse to our much sought after Uberness.
So does that make me give up on my wish to better support Windows development with the CDT. No way! There's more to it than just C/C++ development. I think Eclipse has so much to offer Windows developers that the Express Editions of VisualStudio just don't offer. As one great example, I can't wait to exploit more of TPTP static analysis and expanding it's integration with CDT's DOM. I think there is so much we can do there to make C++ programming more reliable and is something that VisualStudio doesn't offer in any form.
So I think this announcement just makes me want to improve Windows support even more that I'm going on a personal mission to make sure it happens. As always, anyone keen on helping me with this mission, please let me know. I have a ton of work to do with my regular QNX and CDT work so I'd appreciate any help I can get. But I think this is one area that can go a long way to bring the CDT and Eclipse to our much sought after Uberness.
Tuesday, April 18, 2006
Cross Project Issues/Solutions
One of the things I love most about EclipseCon is that I get to see what the other projects are up to. It was really cool to see the progress that a lot of the projects that were just starting up last year have made since then. One thing I've noticed though is that a lot of them need to solve similar problems. I've been pretty happy to see how these projects are starting to work together to find common solutions.
One example is the Remote System Explorer that IBM has contributed to the DSDP Target Management project. It presents a view of remote systems and provides a framework for attaching services that connect to those systems in various ways. Once people have heard about it, everyone is now taking a look. My friends at HP are looking at it as a solution to remote development for their servers (I suppose that's very similar to how IBM uses it internally) that they'd like to contribute to the CDT. Also, I see that the Parallel Tools Project is now looking at it for remote development for their big supercomputer iron.
The question that comes to mind, though, is that if this is something that can be used by many other projects aside from embedded, is it problematic that this functionality resides in the DSDP project? My answer is that, well, the RSE actually resides on dev.eclipse.org. It is being managed by the DSDP/TM project. These are essentially two different things. Anyone can get at the bits and add dependencies to them. What could be problematic is the delivery schedules of the bits and making sure things line up. This is one reason that Callisto is so important, although releasing all at the same time is having it's own set of issues.
One thing I'm certain of, though. As Eclipse continues to grow, we are definitely going to run into the very same issues I've seen in my past with very large software projects. These issues can get out of hand without good architectural control over what we are building in order to make sure that we have good user and ISV experiences. That includes everything from reducing duplication to having common API and UI guidelines. I know a lot of people hate having to comply with guidelines, but I've seen what can happen when they don't and it ain't pretty.
I think the question Mike is really asking is what role the Eclipse Foundation should have in all this. I'm not totally sure what the answer is, but I believe the best architects are the guys mucking around in the code. They usually have their finger on the pulse of the beast and in the best position to make the right call at the right time. But what these guys really need is someone to help facilitate architectural decisions, i.e. bring the group together and to do some concensus building.
I've been lucky enough to attend one of the Eclipse Architectural Council meetings last December (I'm not a member but Bjorn graciously invited me to attend). There were some great minds in the room and Bjorn was doing a good job facilitating the discussions. But I don't remember seeing anything publicized from it, and we had a great discussion on using TPTP's AGR for UI testing. And, I can't remember if any architectural decisions were made.
I think the processes are pretty much in place. I'm just not sure whether we have all the right people involved. I wouldn't mind seeing what would happen if we brought the top senior committers to the table and asked them what they thought about this or that. I'm sure they already have all the answers. But then, these guys are also really busy getting their features done for Callisto...
One example is the Remote System Explorer that IBM has contributed to the DSDP Target Management project. It presents a view of remote systems and provides a framework for attaching services that connect to those systems in various ways. Once people have heard about it, everyone is now taking a look. My friends at HP are looking at it as a solution to remote development for their servers (I suppose that's very similar to how IBM uses it internally) that they'd like to contribute to the CDT. Also, I see that the Parallel Tools Project is now looking at it for remote development for their big supercomputer iron.
The question that comes to mind, though, is that if this is something that can be used by many other projects aside from embedded, is it problematic that this functionality resides in the DSDP project? My answer is that, well, the RSE actually resides on dev.eclipse.org. It is being managed by the DSDP/TM project. These are essentially two different things. Anyone can get at the bits and add dependencies to them. What could be problematic is the delivery schedules of the bits and making sure things line up. This is one reason that Callisto is so important, although releasing all at the same time is having it's own set of issues.
One thing I'm certain of, though. As Eclipse continues to grow, we are definitely going to run into the very same issues I've seen in my past with very large software projects. These issues can get out of hand without good architectural control over what we are building in order to make sure that we have good user and ISV experiences. That includes everything from reducing duplication to having common API and UI guidelines. I know a lot of people hate having to comply with guidelines, but I've seen what can happen when they don't and it ain't pretty.
I think the question Mike is really asking is what role the Eclipse Foundation should have in all this. I'm not totally sure what the answer is, but I believe the best architects are the guys mucking around in the code. They usually have their finger on the pulse of the beast and in the best position to make the right call at the right time. But what these guys really need is someone to help facilitate architectural decisions, i.e. bring the group together and to do some concensus building.
I've been lucky enough to attend one of the Eclipse Architectural Council meetings last December (I'm not a member but Bjorn graciously invited me to attend). There were some great minds in the room and Bjorn was doing a good job facilitating the discussions. But I don't remember seeing anything publicized from it, and we had a great discussion on using TPTP's AGR for UI testing. And, I can't remember if any architectural decisions were made.
I think the processes are pretty much in place. I'm just not sure whether we have all the right people involved. I wouldn't mind seeing what would happen if we brought the top senior committers to the table and asked them what they thought about this or that. I'm sure they already have all the answers. But then, these guys are also really busy getting their features done for Callisto...
Thursday, April 13, 2006
Boot Camp, an Eclipse Developer's Dream?
I've been following the Apple announcement around their Boot Camp with a bit of intrigue. It wasn't too long ago I had a Mac G5 on my desk running both Mac OS X and Yellow Dog Linux and it was mighty cool. Unfortunately with the other priorities I had, I didn't get to do too far with the setup. That and my previous employer wouldn't let me take it with me when I left :).
Now, when I look at the top three platforms in my CDT downloads stats, I find Windows (68%), Linux x86 (26%) and Mac OS X (3%), that's 97% of my platforms. Now if I could run all three of those operating systems on a single machine, wouldn't that make my life easier? I think so. And maybe a lot of Eclipse developers may think so as well. That and the Mac hardware seems to be pretty well designed and something I'd be really happy with.
I think Apple has made a good move in providing the ability to load Windows on their hardware. They can go one step further and allow Linux to be loaded in as well. Then, you might see a lot of the Apple hardware on people's laps when the next EclipseCon rolls around. Now if I can convince my new boss to sign a PO for one ;).
Now, when I look at the top three platforms in my CDT downloads stats, I find Windows (68%), Linux x86 (26%) and Mac OS X (3%), that's 97% of my platforms. Now if I could run all three of those operating systems on a single machine, wouldn't that make my life easier? I think so. And maybe a lot of Eclipse developers may think so as well. That and the Mac hardware seems to be pretty well designed and something I'd be really happy with.
I think Apple has made a good move in providing the ability to load Windows on their hardware. They can go one step further and allow Linux to be loaded in as well. Then, you might see a lot of the Apple hardware on people's laps when the next EclipseCon rolls around. Now if I can convince my new boss to sign a PO for one ;).
Thursday, April 06, 2006
Cool CDT Tutorials
Ian pointed this out in a comment in my last entry but I though I'd bring this out in a new entry.
Matt Ryan from Novell, who I met down at EclipseCon and has done some work with CDT and SUSE Linux, has put together a number of tutorials on using the CDT on Linux. I went through the using CDT with autotools one, mainly because I wanted to know myself. I found the tutorials very thorough, easy to follow, and just plain good looking. That and I learned alot about autotools.
Feel free to head over to the Linux University for Developers hosted at Novell. Matt also invites anyone who wants to create their own tutorials and send them in and he'll add them (instructions at the bottom of the page).
I'll also give a plug to the Wink application created by Satish Kumar from DebugMode which is a cool free screencast creation utility that Matt and others have used to create demos and tutorials. Now everyone can create good looking tutorials!
Matt Ryan from Novell, who I met down at EclipseCon and has done some work with CDT and SUSE Linux, has put together a number of tutorials on using the CDT on Linux. I went through the using CDT with autotools one, mainly because I wanted to know myself. I found the tutorials very thorough, easy to follow, and just plain good looking. That and I learned alot about autotools.
Feel free to head over to the Linux University for Developers hosted at Novell. Matt also invites anyone who wants to create their own tutorials and send them in and he'll add them (instructions at the bottom of the page).
I'll also give a plug to the Wink application created by Satish Kumar from DebugMode which is a cool free screencast creation utility that Matt and others have used to create demos and tutorials. Now everyone can create good looking tutorials!
Eclipse for DCC, Take 2
Taking a look at where the CDT is being successfully deployed, we see that the CDT has a huge base in Embedded as seen at the Embedded Systems Conference. I am also getting a hint that the CDT is being adopted well for Linux development from our download count and the interest we've seen from both Red Hat and Novell/SUSE. As well, thanks to the Parallel Tools guys, we are seeing the CDT being used for High Performance Computing (HPC).
But, as I've said in the past, the one area that I'd love to see more contribution to the CDT, and Eclipse in general, is in Digital Content Creation (DCC) and game development. The CDT is natural for writing the C/C++ code required for these applications and I do have a few notes from people who are doing just that. But there are a lot of "assets" that go into game and visual effects development and I think Eclipse has the capability to do so much more for these developers.
Recently I've been poking around at the current efforts at JSR'ing Java for OpenGL and OpenGL ES for embedded. I also ran across an old workspace where I had implemented one of the snippets from the SWT OpenGL page to run in an editor window. I had forgotten how cool that spinning torus was running inside Eclipse. But it did give me a hint that it should be possible to build a 3D modeler and even a 2D texture editor in Eclipse. And with tools for writing scripts in languages such as Python or Lau, and you've almost got the complete package.
Given the size, at least in revenue, of the gaming and visual affects industries, I think there is room for Eclipse in this picture from the Collada DCC tool interchange standards effort. The major DCC tool vendors have quite a strangle hold there at the moment. But with the ability of Eclipse to bring such a wide variety of tools together in one platform and to build communities that work together for the benefit of all, I think it is quite a compelling story.
But, as I've said in the past, the one area that I'd love to see more contribution to the CDT, and Eclipse in general, is in Digital Content Creation (DCC) and game development. The CDT is natural for writing the C/C++ code required for these applications and I do have a few notes from people who are doing just that. But there are a lot of "assets" that go into game and visual effects development and I think Eclipse has the capability to do so much more for these developers.
Recently I've been poking around at the current efforts at JSR'ing Java for OpenGL and OpenGL ES for embedded. I also ran across an old workspace where I had implemented one of the snippets from the SWT OpenGL page to run in an editor window. I had forgotten how cool that spinning torus was running inside Eclipse. But it did give me a hint that it should be possible to build a 3D modeler and even a 2D texture editor in Eclipse. And with tools for writing scripts in languages such as Python or Lau, and you've almost got the complete package.
Given the size, at least in revenue, of the gaming and visual affects industries, I think there is room for Eclipse in this picture from the Collada DCC tool interchange standards effort. The major DCC tool vendors have quite a strangle hold there at the moment. But with the ability of Eclipse to bring such a wide variety of tools together in one platform and to build communities that work together for the benefit of all, I think it is quite a compelling story.
Thursday, March 30, 2006
Asterisk, the Über OSS Business Model
When I first got out of university, I was hired to work at Bell-Northern Research (now fully integrated into Nortel) like a lot of Canadian kids did back around 1990. There I got a passion for the telephony industry working on software for their central office switch products. I just found it cool how someone's voice can get digitized and then merged, switched, and split off to someone else's phone on the other side of the planet faster than you can blink an eye. The hardware was cool and the software didn't seem too complicated except for the protocol handling between different countries who all seemed to embrace different standards.
I often thought it would be pretty easy to turn a low cost PC into a small switch, or PBX, with the right interface cards. But, I was also pretty sure it would be way too expensive since that industry was still driven by the big telecom companies who weren't about to sell things on the cheap.
Recently I ran across the Asterisk project (who presented at EclipseCon, BTW) which is making open source software that will let you do just that. It has tons of features for making your own PBX including voice mail, conference bridges, and voice over IP support. But where do you get the inexpensive hardware? Well, Asterisk just happens to be sponsored by Digium, who just happens to make such toys. As it turns out, one of their staffers wrote the software and they decided to just give it away for free and start an open source community around it.
That makes way too much sense. It turns out that a lot of people had the same idea that I did and a lot of them are turning that idea into businesses. These guys benefit from the free software and Digium benefits from these guys buying their hardware. Since it is open source, you can plug in other vendors' hardware but since Digium started the project, they have the bulk of the mindshare. It's a risk they've taken but if you have the confidence in your "for money" products, taking the plunge to get that mindshare can pay huge dividends.
Eclipse kind of follows this model, although not as blatant. Check out Digium's booth at VON Spring 2006. It has Asterisk everywhere. Everyone loves an open source project that lets them do cool things, so people stop by. Once you are there you can see one of Digium's 12 partners to buy some cool hardware and services. Everyone wins.
When people ask me how you make money with open source software, this is where I will send them. These guys are teaching a good lesson on open source business models.
I often thought it would be pretty easy to turn a low cost PC into a small switch, or PBX, with the right interface cards. But, I was also pretty sure it would be way too expensive since that industry was still driven by the big telecom companies who weren't about to sell things on the cheap.
Recently I ran across the Asterisk project (who presented at EclipseCon, BTW) which is making open source software that will let you do just that. It has tons of features for making your own PBX including voice mail, conference bridges, and voice over IP support. But where do you get the inexpensive hardware? Well, Asterisk just happens to be sponsored by Digium, who just happens to make such toys. As it turns out, one of their staffers wrote the software and they decided to just give it away for free and start an open source community around it.
That makes way too much sense. It turns out that a lot of people had the same idea that I did and a lot of them are turning that idea into businesses. These guys benefit from the free software and Digium benefits from these guys buying their hardware. Since it is open source, you can plug in other vendors' hardware but since Digium started the project, they have the bulk of the mindshare. It's a risk they've taken but if you have the confidence in your "for money" products, taking the plunge to get that mindshare can pay huge dividends.
Eclipse kind of follows this model, although not as blatant. Check out Digium's booth at VON Spring 2006. It has Asterisk everywhere. Everyone loves an open source project that lets them do cool things, so people stop by. Once you are there you can see one of Digium's 12 partners to buy some cool hardware and services. Everyone wins.
When people ask me how you make money with open source software, this is where I will send them. These guys are teaching a good lesson on open source business models.
Monday, March 27, 2006
CDT Reaching Uberness?
In case you didn't hear John Duimovich, our Tools PMC lead, at the EclipseCon wrap-up, he declared that the CDT was reaching some sort of "uberness". I had to look in Urbandictionary.com to find out what that means. "Far superior to all other things"? Well I wouldn't go that far, ever. There are far superior things, like C++ itself :) Oh and maybe the Eclipse community.
At any rate, it was a great week for the CDT. We had about 60 people brave late notice and a late timeslot to attend the CDT BOF. We also had a good number at my talk on the using the CDT on Firefox source. However the bright lights didn't allow me to do a head count. All through the week, I was very encourage through people's comments. It's almost like, "Hey good thing the CDT, you guys have tough challenges given the language environment you have to deal with, but we trust you are going in the right direction. We'll help where we can. Keep up the good work." It is something the CDT contributor community should be proud of.
I was also very encouraged with commercial interest in the CDT. This is the source of most of the manpower contributing code to the CDT. According to my latest count, I should expect an additional seven committers over the next year, doubling our current size. This will go hugely towards allowing us to do some great things.
The best of the week came on Friday. As everyone else was meandering their way home, the CDT contributors decided to stick around and have a full day of meetings. There we closed off on 3.1 plans and took a good look at CDT 4.0 due out summer 2007. For me, anyway, it was like starting to see my dreams for the CDT come true. In addition to our plans for core model additions to help the parser deal better with build configurations, we now have plans for templates for project creation and beyond, an internal builder for MBS removing the need for make (this may actually land in 3.1.x), and JNI debugging, our uber holy grail.
With all that good news including the great new features for CDT 4.0 and the influx of new contributors, I am absolutely thrilled. It'll be a big challenge to make sure we managed the growth and make sure we don't stumble all over each other, but it's a challenge that I relish in and one that may just lead us to some sort of "uberness".
At any rate, it was a great week for the CDT. We had about 60 people brave late notice and a late timeslot to attend the CDT BOF. We also had a good number at my talk on the using the CDT on Firefox source. However the bright lights didn't allow me to do a head count. All through the week, I was very encourage through people's comments. It's almost like, "Hey good thing the CDT, you guys have tough challenges given the language environment you have to deal with, but we trust you are going in the right direction. We'll help where we can. Keep up the good work." It is something the CDT contributor community should be proud of.
I was also very encouraged with commercial interest in the CDT. This is the source of most of the manpower contributing code to the CDT. According to my latest count, I should expect an additional seven committers over the next year, doubling our current size. This will go hugely towards allowing us to do some great things.
The best of the week came on Friday. As everyone else was meandering their way home, the CDT contributors decided to stick around and have a full day of meetings. There we closed off on 3.1 plans and took a good look at CDT 4.0 due out summer 2007. For me, anyway, it was like starting to see my dreams for the CDT come true. In addition to our plans for core model additions to help the parser deal better with build configurations, we now have plans for templates for project creation and beyond, an internal builder for MBS removing the need for make (this may actually land in 3.1.x), and JNI debugging, our uber holy grail.
With all that good news including the great new features for CDT 4.0 and the influx of new contributors, I am absolutely thrilled. It'll be a big challenge to make sure we managed the growth and make sure we don't stumble all over each other, but it's a challenge that I relish in and one that may just lead us to some sort of "uberness".
Thursday, March 23, 2006
Eclipse CDT: Free forever
I'm sitting in the Eclipse vs. Visual Studio talk and the guy mentioned that Visual Studio has a free version. Really? So I went to look and I found this:
Express Quick Facts
Download Size:35-70 MB per Express Edition
Price:Visual Studio Express Editions—Free for 1 year
Well they are slowly getting it.
I still would love to see better support for Windows development in Eclipse, especially C++ (obviously) and even C#, for the student/hobbyist. Hopefully someone in the community with the time and resources can step up and help us get there.
Express Quick Facts
Download Size:35-70 MB per Express Edition
Price:Visual Studio Express Editions—Free for 1 year
Well they are slowly getting it.
I still would love to see better support for Windows development in Eclipse, especially C++ (obviously) and even C#, for the student/hobbyist. Hopefully someone in the community with the time and resources can step up and help us get there.
OSes are for Wussies
I was sitting with Chris R from TI in the target management talk and Martin O from Wind River was talking about RTOSes and target management. Chris leaned over to me and said "OSes are for wussies". We both laughed. Certain in TI's case with DSPs, they have no need for RTOSes since their customers are generally writing tight control loops that run forever.
I have always though TI's use of the CDT as one of the coolest applications of the CDT. And Chris is never shy to bring us crazy OS people back to earth and back to the the iron that drives all software applications and where this industry really all began.
You look at the presentations this week at EclipseCon, you can really see the breadth of problem domain that people are using Eclipse for. You've got everything from critical deisel injection systems to services oriented architecture for web applications to application lifecycle management to management systems for NASA missions.
Sitting in meetings with my fellow Eclipsers and you don't get the feel of the significance of this all. But move out to the 10,000 foot view and you can easily get overwelmed at how prolific Eclipse is becoming in the software development industry. I am certainly proud to be able to put my little part into it and to be a part of this great community.
I have always though TI's use of the CDT as one of the coolest applications of the CDT. And Chris is never shy to bring us crazy OS people back to earth and back to the the iron that drives all software applications and where this industry really all began.
You look at the presentations this week at EclipseCon, you can really see the breadth of problem domain that people are using Eclipse for. You've got everything from critical deisel injection systems to services oriented architecture for web applications to application lifecycle management to management systems for NASA missions.
Sitting in meetings with my fellow Eclipsers and you don't get the feel of the significance of this all. But move out to the 10,000 foot view and you can easily get overwelmed at how prolific Eclipse is becoming in the software development industry. I am certainly proud to be able to put my little part into it and to be a part of this great community.
Embedded Wednesday
What a whirlwind day today at EclipseCon. It started with my presentation on the CDT. I gave an overview of the CDT and talked about how I set up the CDT to work with Firefox source code. I don't really work on Firefox but its a great test for scalability for the CDT. It was well attended and I had some great questions as well. As usual, they focused a lot on the indexer and I had a lot of great suggestions on how people want to reuse prebuilt indexes and to share such indexes with other members of a team. All great ideas that we will hopefully get to in upcoming releases.
We then had two really good presentations from the guys working on the Device Software project and it looks like they are working on some really cool stuff to help bring together a lot of the tools that hardcore embedded developers use and are creating a community around it that embedded tool vendors can all work together and reap the benefits of the collaboration.
One of the short talks (which are really short BTW) someone from Nokia presented how they created managed build and debugger integrations with Scratchbox which makes it easy to use cross compilers for embedded targets. They have contributed their work to the Laika project. One complaint they had was about the lack of documentation on the debugger integration. I'll have to ask them if they'd like to contribute their experience :).
I've met a lot of people down here and everyone is excited about the CDT. We have some pretty cool things we are starting to look at for CDT 4.0 for next year that will fulfill a lot of the vision we've had. More on that as we talk more about it at the Friday contributors conference.
As part of that I also got some good news about more people coming to work on the CDT. I'll let their presence become known on the cdt-dev list as they wish. From the numbers, the CDT is on a big upswing in popularity and as the community grows, we will all benefit from eachother's great work, which is what this open source business is all about.
One of the presenters just hit me with a T-shirt. I better listen know...
We then had two really good presentations from the guys working on the Device Software project and it looks like they are working on some really cool stuff to help bring together a lot of the tools that hardcore embedded developers use and are creating a community around it that embedded tool vendors can all work together and reap the benefits of the collaboration.
One of the short talks (which are really short BTW) someone from Nokia presented how they created managed build and debugger integrations with Scratchbox which makes it easy to use cross compilers for embedded targets. They have contributed their work to the Laika project. One complaint they had was about the lack of documentation on the debugger integration. I'll have to ask them if they'd like to contribute their experience :).
I've met a lot of people down here and everyone is excited about the CDT. We have some pretty cool things we are starting to look at for CDT 4.0 for next year that will fulfill a lot of the vision we've had. More on that as we talk more about it at the Friday contributors conference.
As part of that I also got some good news about more people coming to work on the CDT. I'll let their presence become known on the cdt-dev list as they wish. From the numbers, the CDT is on a big upswing in popularity and as the community grows, we will all benefit from eachother's great work, which is what this open source business is all about.
One of the presenters just hit me with a T-shirt. I better listen know...
Tuesday, March 21, 2006
First Day At EclipseCon
Well, I made it in at around 1 p.m. on Monday to EclipseCon. After getting set up with my hotel room and finding out where the bar was, I've managed to run into and talk with a lot of the CDT community that are gathered here. It's going to be a great week of getting the good word out about the CDT and it's ever growing momentum.
The highlight of the day was the Community Awards ceremony (not the game show :) where Alain Magloire from QNX won the Top Committer award for his work on the CDT. Aside from the sheer volume of code he has submitted to the CDT, Alain has always been very helpful with people out in the community. He certainly helped our team back at Rational when we were starting out writing the parser and integrating it with the CModel. We owe a lot to Alain's committment to building a great CDT and it was great to see him rewarded for it.
More from the show as the week goes...
The highlight of the day was the Community Awards ceremony (not the game show :) where Alain Magloire from QNX won the Top Committer award for his work on the CDT. Aside from the sheer volume of code he has submitted to the CDT, Alain has always been very helpful with people out in the community. He certainly helped our team back at Rational when we were starting out writing the parser and integrating it with the CModel. We owe a lot to Alain's committment to building a great CDT and it was great to see him rewarded for it.
More from the show as the week goes...
Wednesday, March 01, 2006
Eclipse 3.2 M5,eh?
I'm sure you've all noticed the newest milestone release for Eclipse 3.2 M5a. I'm not sure everyone knows why the Eclipse PMC had to go through the drastic measure of respinning a milestone release a few days after it was released. It is an important lesson, though, that all Eclipse plug-in developers, and probably any developer working with an evolving platform, need to think about
It all started with Bug 128866 raised by the EMF guys when they noticed that their Jet nature didn't work anymore on M5. I also noticed it with one of our internal QNX plug-ins. The problem was that we used a dot in the extension id for our natures. For years, as both of our plug-ins originated with Eclipse 1.0, this never manifested itself in any ill behavior. However, as Jeff McAffer correctly pointed out, it has always been documented that dots weren't allowed in extension ids. Unfortunately, the Eclipse platform has turned a blind eye to these invalid ids, until M5, of course.
The platform developers came up with a clever design to allow extension ids to have namespaces that were different than the plug-in id, which has been the default. You do this by introducing a plug-in id that, you guessed it, has dots in it to reflect that you are specifying the fully qualified id for the extension. It would have worked, if there hadn't have been plug-ins like EMF's and others that broke the rules.
I commend the Eclipse platform team for doing the right thing and respinning M5 to allow both the old and new schemes to work (thanks to plug-in version tags). It had to have been a tough decision, but it really shows that they place a high value on doing the right thing over the optically pleasing thing, especially when it really wasn't their fault.
But it does point out that backwards compatibility is a hard thing to maintain. It is never a simple matter of taking your old plug-ins and having them always work on new platforms. And it's not only the APIs but the expected behavior from the platform that can break compatibility. Plug-in developers need to be vigilant and try out their plug-ins on every platform version they want to support. It is also a good idea to try them out early so that if a problem is found it can be dealt with before it becomes too difficult to change. I'm glad that I've been doing that.
It all started with Bug 128866 raised by the EMF guys when they noticed that their Jet nature didn't work anymore on M5. I also noticed it with one of our internal QNX plug-ins. The problem was that we used a dot in the extension id for our natures. For years, as both of our plug-ins originated with Eclipse 1.0, this never manifested itself in any ill behavior. However, as Jeff McAffer correctly pointed out, it has always been documented that dots weren't allowed in extension ids. Unfortunately, the Eclipse platform has turned a blind eye to these invalid ids, until M5, of course.
The platform developers came up with a clever design to allow extension ids to have namespaces that were different than the plug-in id, which has been the default. You do this by introducing a plug-in id that, you guessed it, has dots in it to reflect that you are specifying the fully qualified id for the extension. It would have worked, if there hadn't have been plug-ins like EMF's and others that broke the rules.
I commend the Eclipse platform team for doing the right thing and respinning M5 to allow both the old and new schemes to work (thanks to plug-in version tags). It had to have been a tough decision, but it really shows that they place a high value on doing the right thing over the optically pleasing thing, especially when it really wasn't their fault.
But it does point out that backwards compatibility is a hard thing to maintain. It is never a simple matter of taking your old plug-ins and having them always work on new platforms. And it's not only the APIs but the expected behavior from the platform that can break compatibility. Plug-in developers need to be vigilant and try out their plug-ins on every platform version they want to support. It is also a good idea to try them out early so that if a problem is found it can be dealt with before it becomes too difficult to change. I'm glad that I've been doing that.
Tuesday, February 28, 2006
Another Amazing Xgl Demo
I hope the folks at freedesktop.org don't mind all the traffic that davidr is causing, but anyone interested in the future of the Linux desktop have got to see this.
I have to admit that a lot of what he shows is eye candy, but to me the idea is to make the things on the desktop seem more real. This could ease the paradigm shift that happens between the real world and your computer screen, thus hopefully making people more productive. I'd have to try it out for real to be more sure and I can't wait! I just hope I don't need a Cray and a quad SLI to get the same effects shown in the demo :).
Demo video here.
So what is the CDT angle on all this? Well, one of the earliest uses we saw for the CDT was as a core development environment for Linux C/C++ apps. If something like Xgl can cause the demand for Linux to grow, we should see more Linux developers using the CDT, probably including former Windows developers who will be expecting a Visual Studio equivalent.
I have to admit that a lot of what he shows is eye candy, but to me the idea is to make the things on the desktop seem more real. This could ease the paradigm shift that happens between the real world and your computer screen, thus hopefully making people more productive. I'd have to try it out for real to be more sure and I can't wait! I just hope I don't need a Cray and a quad SLI to get the same effects shown in the demo :).
Demo video here.
So what is the CDT angle on all this? Well, one of the earliest uses we saw for the CDT was as a core development environment for Linux C/C++ apps. If something like Xgl can cause the demand for Linux to grow, we should see more Linux developers using the CDT, probably including former Windows developers who will be expecting a Visual Studio equivalent.
Wednesday, February 15, 2006
A Cool Eclipse CDT for Embedded Tutorial
I often hear the remark that the CDT isn't good for embedded development. I always find that odd since the majority of the contributors and commercial consumers of the CDT are embedded tools vendors and the CDT actually sprouted out from one such tool. Mind you there are a few things that the commercial vendors add to make things like board bring up and target management easier but these aren't huge additions.
But having been in the tools business for over a decade now, I find it much easier to sell such ideas if there is a grassroots movement that is driven by real users' needs. That's when I was thrilled when Wayne Beaton passed on a proposed Eclipse article based on a turorial on that very subject. The tutorial is written by James Lynch who has given me permission to pass it on to you. You can see the tutorial here. The objective of it is to show that you can do embedded development on an inexpensive environment for people who want to play and learn about the embedded world. Mission accomplied I'd say!
The tutorial walks the reader through how to set up their Eclipse environment and other tools including a special embedded version of the CDT that our friend Øyvind at Zylin Consulting has put together. He then shows how to code up an small image that strobes an LED on the board and how to build the image, download it using JTAG and debug it over a serial port. It's a very cool illustration of our point that "Eclipse is not just for Java".
Now, I'll need to take a look at the changes that Øyvind has made in his version of the CDT and see why we couldn't make them available in the base CDT. That would make it even easier for everyone who wants to try it out.
But having been in the tools business for over a decade now, I find it much easier to sell such ideas if there is a grassroots movement that is driven by real users' needs. That's when I was thrilled when Wayne Beaton passed on a proposed Eclipse article based on a turorial on that very subject. The tutorial is written by James Lynch who has given me permission to pass it on to you. You can see the tutorial here. The objective of it is to show that you can do embedded development on an inexpensive environment for people who want to play and learn about the embedded world. Mission accomplied I'd say!
The tutorial walks the reader through how to set up their Eclipse environment and other tools including a special embedded version of the CDT that our friend Øyvind at Zylin Consulting has put together. He then shows how to code up an small image that strobes an LED on the board and how to build the image, download it using JTAG and debug it over a serial port. It's a very cool illustration of our point that "Eclipse is not just for Java".
Now, I'll need to take a look at the changes that Øyvind has made in his version of the CDT and see why we couldn't make them available in the base CDT. That would make it even easier for everyone who wants to try it out.
Wednesday, February 08, 2006
Xgl - Desktop Linux's Savior?
I've followed the Linux on the Desktop thing for quite a while. At one point I had one of the distributions installed on my laptop and swore that there was nothing that I needed out of Windows that Linux didn't provide for me. And for the most part that was true, except for my corporate e-mail client, which I ended up running in a vmware session.
I trotted along with that for a while, but after a couple of months, I went back to Windows in frustration. Despite the promise of Desktop Linux, it just felt sluggish and blurry when compared to my Windows boxen. When working with reams of code in Eclipse, the desktop experience is critical to my productivity. And unfortunately, I'm just more productive in Windows that I was in Linux, which is too bad since I really prefer Linux for software development. I just seems to give me more control over my execution environment.
And then one day a Mac G5 landed in my office. There wasn't much installed on it so I didn't have much use for it, but the desktop environment sure looked cool. After a little investigation I found out that at the base of it all was OpenGL. The promise of using OpenGL, or 3D acceleration in general, for desktop environments had really peaked my interest. With the pending arrival of Microsoft Vista, I think we'll soon realize how clunky the ole' 2D desktops really are.
So if Mac OS X can do a 3D desktop on a *nix base, why can't Linux. That's when a few google searches brought me to the Xgl project going on in and around X.org. Xgl is an implementation of an X server on OpenGL, assuming I understand the documentation correctly. The progress on Xgl has been slow and I kind of lost track of it's progress until an article appeared on ZDNet the other day. I'm still not sure it's moving at a pace where we'll see it common place anytime soon, but with the backing of Novell, who hired the developer of Xgl, my hope has returned, at least a little bit.
I love Linux for software development and, if I had the right desktop experience and I had access to all the apps I needed to be super productive in my job, I'd switch again in an instant. Here's hoping that the Linux community sees the potential of Xgl and works on finishing it and bringing it into my favorite Linux distribution sometime soon.
I trotted along with that for a while, but after a couple of months, I went back to Windows in frustration. Despite the promise of Desktop Linux, it just felt sluggish and blurry when compared to my Windows boxen. When working with reams of code in Eclipse, the desktop experience is critical to my productivity. And unfortunately, I'm just more productive in Windows that I was in Linux, which is too bad since I really prefer Linux for software development. I just seems to give me more control over my execution environment.
And then one day a Mac G5 landed in my office. There wasn't much installed on it so I didn't have much use for it, but the desktop environment sure looked cool. After a little investigation I found out that at the base of it all was OpenGL. The promise of using OpenGL, or 3D acceleration in general, for desktop environments had really peaked my interest. With the pending arrival of Microsoft Vista, I think we'll soon realize how clunky the ole' 2D desktops really are.
So if Mac OS X can do a 3D desktop on a *nix base, why can't Linux. That's when a few google searches brought me to the Xgl project going on in and around X.org. Xgl is an implementation of an X server on OpenGL, assuming I understand the documentation correctly. The progress on Xgl has been slow and I kind of lost track of it's progress until an article appeared on ZDNet the other day. I'm still not sure it's moving at a pace where we'll see it common place anytime soon, but with the backing of Novell, who hired the developer of Xgl, my hope has returned, at least a little bit.
I love Linux for software development and, if I had the right desktop experience and I had access to all the apps I needed to be super productive in my job, I'd switch again in an instant. Here's hoping that the Linux community sees the potential of Xgl and works on finishing it and bringing it into my favorite Linux distribution sometime soon.
Update: Here's the news release from Novell. Includes some cool movies showing off a demo of Xgl's advanced capabilities.
Thursday, February 02, 2006
SystemC - two worlds collide
I used to sit across the cubicle wall from an ASIC designer back in the mid 90's. He was pretty friendly and was very interested in the future of software engineering, especially software modeling. I guess that makes sense since, as an ASIC designer, modeling hardware was second nature and he figured it should be the same for software.
That got me interested in what they were using to model hardware. He was using Verilog, one of the big two hardware description languages, VHDL being the other. I was starting to use ObjecTime, a graphical software modeling tool that I ended up helping build, and he found it very odd that we were moving into graphical modeling where the hardware guys were abandoning it for textual modeling.
Looking back now, I'm thinking he may have been on to something. I still think visual modeling has a long way to go before it becomes mainstream with every day developers, and even longer for modeling behavior. Maybe we're suckers for punishment and prefer to deal with reams of text, or maybe the tools aren't up to snuff yet for visual modeling (and I'm still holding out hope that GMF will get us much closer).
That's when I ran across SystemC yesterday, I had a famous Ward Cunningham "a-ha moment". Here's a system description language that software guys would love. It uses the power of C++'s type system and a small run-time to model the concurrency and timing of real-world systems. What a great mix of the two worlds with hardware and software guys working on the same code. I am just starting to scratch the surface of the potential of SystemC, but it's one of those technologies that I end up losing sleep over wondering about the possibilities. I'll write more on it once I do a bit more research and I'd love to hear peoples' opinions on it.
However, the important thing I am taking from SystemC has nothing to do with systems modeling. At the back of my mind is a new programming paradigm that was sparked when I first looked at UML action semantics. Hardware is inherently a huge collection of concurrent processes, which BTW is also a key feature that SystemC emulates. This concurrency is the reason why many algorithms are much faster to implement in hardware. Why can't software be that way? And with the new revolution of multi-core processing, will our current von Neumann paradigm scale to hundreds of concurrent threads? Maybe there's something we can take away from SystemC that we can use to build massively concurrent programs in C++. I sense another "a-ha moment" coming, or at least another few more late nights...
That got me interested in what they were using to model hardware. He was using Verilog, one of the big two hardware description languages, VHDL being the other. I was starting to use ObjecTime, a graphical software modeling tool that I ended up helping build, and he found it very odd that we were moving into graphical modeling where the hardware guys were abandoning it for textual modeling.
Looking back now, I'm thinking he may have been on to something. I still think visual modeling has a long way to go before it becomes mainstream with every day developers, and even longer for modeling behavior. Maybe we're suckers for punishment and prefer to deal with reams of text, or maybe the tools aren't up to snuff yet for visual modeling (and I'm still holding out hope that GMF will get us much closer).
That's when I ran across SystemC yesterday, I had a famous Ward Cunningham "a-ha moment". Here's a system description language that software guys would love. It uses the power of C++'s type system and a small run-time to model the concurrency and timing of real-world systems. What a great mix of the two worlds with hardware and software guys working on the same code. I am just starting to scratch the surface of the potential of SystemC, but it's one of those technologies that I end up losing sleep over wondering about the possibilities. I'll write more on it once I do a bit more research and I'd love to hear peoples' opinions on it.
However, the important thing I am taking from SystemC has nothing to do with systems modeling. At the back of my mind is a new programming paradigm that was sparked when I first looked at UML action semantics. Hardware is inherently a huge collection of concurrent processes, which BTW is also a key feature that SystemC emulates. This concurrency is the reason why many algorithms are much faster to implement in hardware. Why can't software be that way? And with the new revolution of multi-core processing, will our current von Neumann paradigm scale to hundreds of concurrent threads? Maybe there's something we can take away from SystemC that we can use to build massively concurrent programs in C++. I sense another "a-ha moment" coming, or at least another few more late nights...
Subscribe to:
Posts (Atom)