Here we go having a debate again on Planet Eclipse. I apologize to my readers who don't follow the Planet. But then you should. It's always great reading!
As a member the EclipseCon 2007 program committee, I had to take offense to Wassim's remarks about the "Contraversial" EclipseCon 2007. Now he has all rights to state his opinion and we should all respect it and take a good look at what's going on. If he's right, then it is something we need to take a look at and make sure it is corrected.
But I think his statements are a bit off the mark. Bjorn had a nice post that summed up a lot of how I felt about it and agree 100% with what he said there. I'd like to add a bit more from the C/C++ track perspective.
First of all, I submitted a proposal for a short tutorial to the C/C++ track that I supposedly control. I did so because, at the time, I didn't have any proposals and was afraid that the C/C++ community was going to miss out on the opportunity. After doing a little recruiting I was able to convince a few members of the community to put in much better proposals than mine and I plan on rejecting mine in favour of theirs.
Now, if I do run into the situation that I have too few proposals for the tracks that have been allocated, or they are too weak, I will propose to offer them up to the rest of the Eclipse community to make sure we get good quality content. My understanding from the other committee members is that they plan on doing the same.
You can't get much more open than actually showing the allocations that have been given to the various tracks. I was pleasantly surprised to see that we were being that open. I've never seen it before, and it does open us up for criticism so early in the process.
I guess what hasn't been made public is that these numbers aren't necessarily written in stone and that we already have mucked around a bit with them. And we have left the door open to do more of the same. As Bjorn mentioned, we are all focused on making the EclipseCon program the best it can be for the attendees, which will go a long way towards growing our community. And I think it's a great thing to be doing it in the open for others to comment on and help improve.
Monday, November 06, 2006
Friday, November 03, 2006
Microsoft Novell
I've been busy working on the CDT integration with the Windows SDK and, at the moment the Windows debug engine, to support C++ development using this SDK as a choice over cygwin/mingw for Windows development. As I've mentioned previously, I'm keen on getting Eclipse and the CDT in a state where it can be useful for Windows developers and open up a whole new community to this great thing we've got going with Eclipse.
Taking a break from debugging the debugger yesterday, I tripped over a Slashdot article that said there was going to be a press conference webcast at 5 p.m. EST announcing a partnership between Microsoft and Novell on Linux. After checking the calendar to mare sure it wasn't April 1, I tuned in. Watching the proceedings, I got that feeling I was watching history, like when Wayne Gretzky announced his retirement. Time will tell whether Microsoft entering the Linux/open source world will change anything, but today, it looks pretty significant.
What was clear was that it is more like Microsoft grudgingly admitting Linux is important with its customers, than Microsoft throwing in the towel. But I think that is an important admission that will change how the open source world views Microsoft and, more importantly, how the Microsoft world views open source and Linux in particular.
Which brings me back to my Windows SDK integration. One of the visions we had for the CDT in the early days, was for the CDT to be the cross platform development environment that eases the transition for Windows developers who want to start working on Linux apps. It was great in theory, but the demand didn't really materialize (and neither did the community). Time will tell whether this announcement changes that. But in the meantime, it has given me a little extra energy to try and make sure the Windows SDK integration happens for both C++ and C# (Mono may have been given a boost with this also) to at least make the path easier to follow.
Taking a break from debugging the debugger yesterday, I tripped over a Slashdot article that said there was going to be a press conference webcast at 5 p.m. EST announcing a partnership between Microsoft and Novell on Linux. After checking the calendar to mare sure it wasn't April 1, I tuned in. Watching the proceedings, I got that feeling I was watching history, like when Wayne Gretzky announced his retirement. Time will tell whether Microsoft entering the Linux/open source world will change anything, but today, it looks pretty significant.
What was clear was that it is more like Microsoft grudgingly admitting Linux is important with its customers, than Microsoft throwing in the towel. But I think that is an important admission that will change how the open source world views Microsoft and, more importantly, how the Microsoft world views open source and Linux in particular.
Which brings me back to my Windows SDK integration. One of the visions we had for the CDT in the early days, was for the CDT to be the cross platform development environment that eases the transition for Windows developers who want to start working on Linux apps. It was great in theory, but the demand didn't really materialize (and neither did the community). Time will tell whether this announcement changes that. But in the meantime, it has given me a little extra energy to try and make sure the Windows SDK integration happens for both C++ and C# (Mono may have been given a boost with this also) to at least make the path easier to follow.
Thursday, October 12, 2006
CDT at the Eclipse Summit Europe
I'm having a great time here at Eclipse Summit Europe. It's the first time I've been in Europe and it's a pretty darn cool place to be. Watching TV and walking around the area has made me really want to learn German, which is my heritage anyway. And the architecture in this area of Esslingen is unbelievably amazing throwback to early Germany. Someone mentioned that it's like something Disney would build.
Jet lag had kicked in hard just before my talk on the CDT DOM so I'll apologize to everyone who was there if it seemed disorganized. I was glad to be able to get the message out on how we are doing with the CDT and the cool things we are working on. The biggest feedback was the interest in the C#DT support I want to build on the CDT. I'm just trying to prove out CDT's multi-language capability but people are intrigued by the undertones of it all.
I also met a few people who were users of the CDT. Everyone gave me positive feedback on the performance improvements with the indexer. One group had even added a few UI features to make their lives easier and I encouraged them to contribute them back to the community, which the appeared happy to do. This is a general message I should remind everyone. If you have made little improvements to the CDT, feel free to contribute them. We're certainly interested in spending time looking at patches especially as it improves the user experience for all.
Given the liveliness of the discussions in the foyer where we had lunches and get togethers, I'd say Eclipse is live and well in Europe. Certainly looking at the list of people who attended the CDT summit, Europe is an important place that we need to focus on more and ensure the community can easily span the oceans, and time zones...
Jet lag had kicked in hard just before my talk on the CDT DOM so I'll apologize to everyone who was there if it seemed disorganized. I was glad to be able to get the message out on how we are doing with the CDT and the cool things we are working on. The biggest feedback was the interest in the C#DT support I want to build on the CDT. I'm just trying to prove out CDT's multi-language capability but people are intrigued by the undertones of it all.
I also met a few people who were users of the CDT. Everyone gave me positive feedback on the performance improvements with the indexer. One group had even added a few UI features to make their lives easier and I encouraged them to contribute them back to the community, which the appeared happy to do. This is a general message I should remind everyone. If you have made little improvements to the CDT, feel free to contribute them. We're certainly interested in spending time looking at patches especially as it improves the user experience for all.
Given the liveliness of the discussions in the foyer where we had lunches and get togethers, I'd say Eclipse is live and well in Europe. Certainly looking at the list of people who attended the CDT summit, Europe is an important place that we need to focus on more and ensure the community can easily span the oceans, and time zones...
Saturday, October 07, 2006
Qemu, my favorite tool of the week
I've been with QNX for over a year now and I continue to learn all I can about our Neutrino operating system, and development issues faced by embedded developers in general. If I'm going to focus on tools for embedded developers, I need to get inside their shoes and walk the talk.
I've worked with a couple of development boards and that was pretty cool, especially when lights started flashing and it started communicating out the serial and ethernet ports. But carrying around a board, even a little one, is a bit cumbersome and not very practical. I've been a long time fan of VMware and have used that. But, x86 is not where the excitement is at in the mobile embedded market, so I have been looking for something that was less desktop-y to use.
Recently I ran accross an article on using Qemu, an open source processor emulator that can emulate a number of different processors and peripheral devices, to run a Debian Linux ARM installation. It also claims that on faster machines, it can even be faster than the actual ARM processors it is emulating. This is exactly what I was looking for.
So I've started down a journey of writing a Neutrino BSP (Board Support Package) for Qemu, which emulates the ARM Versatile Platform Baseboard. I have the programmers guide for this board which is a pretty good help, but thanks to the fact that I have the source for the emulator, if I have any questions about how certain registers work, I can just look at the implementation in Qemu. The architecture is very clean so it makes these things very easy to find. It also includes a gdb remote interface that acts like a JTAG interface so I can step through my code.
With all these goodies, I think I'll have Neutrino up and running in this environment in no time. Very cool! There is a tutorial floating around by James Lynch on using the CDT with a tiny ARM-based board. I should write a similar tutorial on using Qemu's ARM emulation with the CDT and make sure these environments work well. It's a great learning tool if nothing else.
I've worked with a couple of development boards and that was pretty cool, especially when lights started flashing and it started communicating out the serial and ethernet ports. But carrying around a board, even a little one, is a bit cumbersome and not very practical. I've been a long time fan of VMware and have used that. But, x86 is not where the excitement is at in the mobile embedded market, so I have been looking for something that was less desktop-y to use.
Recently I ran accross an article on using Qemu, an open source processor emulator that can emulate a number of different processors and peripheral devices, to run a Debian Linux ARM installation. It also claims that on faster machines, it can even be faster than the actual ARM processors it is emulating. This is exactly what I was looking for.
So I've started down a journey of writing a Neutrino BSP (Board Support Package) for Qemu, which emulates the ARM Versatile Platform Baseboard. I have the programmers guide for this board which is a pretty good help, but thanks to the fact that I have the source for the emulator, if I have any questions about how certain registers work, I can just look at the implementation in Qemu. The architecture is very clean so it makes these things very easy to find. It also includes a gdb remote interface that acts like a JTAG interface so I can step through my code.
With all these goodies, I think I'll have Neutrino up and running in this environment in no time. Very cool! There is a tutorial floating around by James Lynch on using the CDT with a tiny ARM-based board. I should write a similar tutorial on using Qemu's ARM emulation with the CDT and make sure these environments work well. It's a great learning tool if nothing else.
Friday, October 06, 2006
Open Source, The Double Edge Sword
I know this has been talked about a lot in the open source industry, but I've personally started to see concrete examples of it. Commercial adoption of open source software is a double edge sword. One the one side, it is great to have the flexibility to be able to take open source solutions, adapt them to your particular problem domain, and add the value of those solutions to your product. On the other side, it is a lot of work to do that, and in a commercial setting, lot of work == big expense.
And, of course, you really have to watch the pointy end of the sword that could kill your project, and I think that pointy end is unrealistic expectations. But, I think the industry is really starting to get that open source != free. And, unfortunately, I think a lot of it comes from war wounds, but the lesson is getting learned.
This does, however, come back to the software as a service story I keep blabbing about. Now, you can either hire and train people to do the work, or you can contract out to a services company that (hopefully) already has the trained people to do the work for you (hopefully) cheaper. It was pretty interesting then when I noticed a little-advertised feature of the Eclipse.org web site, the Services section. It lists a few companies that are offering services to the Eclipse community. It is unfortunate that there are so few and very few with a non-Enterprise focus, but the opportunity is there for those who want to take it.
And, of course, you really have to watch the pointy end of the sword that could kill your project, and I think that pointy end is unrealistic expectations. But, I think the industry is really starting to get that open source != free. And, unfortunately, I think a lot of it comes from war wounds, but the lesson is getting learned.
This does, however, come back to the software as a service story I keep blabbing about. Now, you can either hire and train people to do the work, or you can contract out to a services company that (hopefully) already has the trained people to do the work for you (hopefully) cheaper. It was pretty interesting then when I noticed a little-advertised feature of the Eclipse.org web site, the Services section. It lists a few companies that are offering services to the Eclipse community. It is unfortunate that there are so few and very few with a non-Enterprise focus, but the opportunity is there for those who want to take it.
Tuesday, September 26, 2006
JDT/CDT, Can't we just get along?
So between putting the finishing touches on CDT 3.1.1, some QNX work items, and dealing with the various summits and stuff, I've started working a little on my CDT/Windows Debugger API integration. It didn't take too long before I got my workspace set up to work on it. I'm creating Java classes that will plug into the CDT's debug engine (or engines as the new Debug Services Framework comes together). I'm also creating C++ code to implement native methods that talk to the Windows APIs. I'm also about to figure out the right way to do callbacks from those APIs trough my C++ code up into the Java code.
I'm trying to follow as much as I can the SWT model by doing as little in the native code as possible and putting most of the logic in Java. As much as I prefer C++ to Java, I don't have a good answer to the question "How do you debug the debugger" so I'll be relying on the Java debugger and good ol' printfs to get me through.
But once you have a mix of CDT and JDT projects, the workflows aren't pretty. The first thing that hit me was when I was in the C/C++ Perspective and hit the New Class button to create a Java class. Uh, nope, that creates a C++ class. So I'm starting to find myself flipping back and forth between the Java and C/C++ perspectives to get the right navigator views and toolbar buttons at the right time. It's a pain and it would be nice if we had a "Code" perspective or something where we could write code without the context switching.
And then, there's the result of my work. When I do get the debugger integrated, I may just wish to debug my debugger or some other JNI application with it. The "Holy Grail" for us in CDT-land has always been to be able to step from Java code into C++ code and back and forth seamlessly.
We've talked about this since the first CDT get-together back in July 2002. I've tried to get it to work with some success but got sidetracked with other things. The guys at Intel presented a proposal on such an environment at our Spring summit, bit I haven't heard much about that since. I'm interested in hearing peoples' opinion on whether this is something they feel is important for Eclipse. And, of course, I'm interested in ideas on how we can build a community to help make this happen. If nothing, it will be a lot of work.
I'm trying to follow as much as I can the SWT model by doing as little in the native code as possible and putting most of the logic in Java. As much as I prefer C++ to Java, I don't have a good answer to the question "How do you debug the debugger" so I'll be relying on the Java debugger and good ol' printfs to get me through.
But once you have a mix of CDT and JDT projects, the workflows aren't pretty. The first thing that hit me was when I was in the C/C++ Perspective and hit the New Class button to create a Java class. Uh, nope, that creates a C++ class. So I'm starting to find myself flipping back and forth between the Java and C/C++ perspectives to get the right navigator views and toolbar buttons at the right time. It's a pain and it would be nice if we had a "Code" perspective or something where we could write code without the context switching.
And then, there's the result of my work. When I do get the debugger integrated, I may just wish to debug my debugger or some other JNI application with it. The "Holy Grail" for us in CDT-land has always been to be able to step from Java code into C++ code and back and forth seamlessly.
We've talked about this since the first CDT get-together back in July 2002. I've tried to get it to work with some success but got sidetracked with other things. The guys at Intel presented a proposal on such an environment at our Spring summit, bit I haven't heard much about that since. I'm interested in hearing peoples' opinion on whether this is something they feel is important for Eclipse. And, of course, I'm interested in ideas on how we can build a community to help make this happen. If nothing, it will be a lot of work.
Right Place, Right Time (part 2)
Having concluded that I haven't done anything really to help guarantee the CDT's success, I do have a few mantras that are hopefully contributing to a healthy community.
- Be open. This was actually pretty hard at first when it was only QNX and then only QNX and IBM/Rational when the only people who cared about what you were doing were sitting down the hall or across town. But with the CDT development community spread around the world, working in the open is critical. In the CDT we have healthy discussions in Bugzilla and on the cdt-dev list and are looking at ways to share ideas and work together more often and more fluidly.
- Equality. A lot of open source projects tend to be dominated by one or two organizations and unfortunately a lot of Eclipse projects are this way. In the CDT, no one dominates. No organization has more than around 5 developers and most are around 2. And there are over 10 organizations involved. We honor the veto committer voting system so we aim to get consensus before taking big steps and usually do.
- Spread the Word. At times I feel like I'm a part of our marketing team here at QNX, and I guess part of my role is that. You can hope people stumble onto your project and get interested, but the media has a role to play helping you spread the word. And with the number of online magazines and webinar services in business now, they are always looking for a new angle. Take advantage of it.
Monday, September 25, 2006
Right place, Right Time (part 1)
One thing I've been asked recently is to share why the CDT is successful in the Eclipse community. It's a really hard question for me to answer since I'm not sure I can trace anything I've done as a project lead to help with this success. That and I'm not sure whether it really is successful. I've been pretty happy with its popularity with over 340,000 downloads of CDT 3.0.2 and 35 developers attending last weeks CDT summit. I think we still have a long way to go to reach the quality levels of the JDT and VisualStudio, but now that we have so much attention on the CDT, we're trying to address that. So, I think the real question is - why is the CDT so popular, and what have we done as a project to help achieve that. My answer is in two parts so I'll make this a two part blog entry.
So the first part of my answer is this: "Dumb luck", or maybe slightly less self-deprecating, "Being at the right place at the right time". QNX started the CDT back in 2002 because we needed an IDE to help developers writing applications for our operating system be more productive. Now, we're not an IDE company and seeing what IBM had in store for building an open source community around Eclipse, we reckoned that would be the right way to go for the CDT as well. The hope was that lots of other non-IDE companies needed an IDE too and we could all share the development cost of it.
It was a gamble and it did take four years to reach this point, but in the end we were right. The reason the CDT is so popular is that there is a huge need in the non-Windows market for a universal IDE that vendors and users can easily leverage for their own needs. Given the huge popularity of Eclipse and with the CDT being the C/C++ solution for Eclipse, it just becomes natural that people gravitate to the CDT. That and the CDT promises to be a high quality, feature rich C/C++ development environment that you have had to pay money for in the past. Everyone like free stuff that's good.
So in the end, I don't think we've done anything in particular to help make the CDT as popular as it is other than simply having the right solution at the right time. I wish I can claim otherwise, but it is what it is. In the next part of this blog entry, though, I will try to list some of the things we've tried aimed at making sure the CDT is an open, welcoming community that will hopefully keep this momentum going. Having something good and free helps with consumption of your open source project, but it doesn't provide any guarantees that it'll attract developers to help you build and test it.
So the first part of my answer is this: "Dumb luck", or maybe slightly less self-deprecating, "Being at the right place at the right time". QNX started the CDT back in 2002 because we needed an IDE to help developers writing applications for our operating system be more productive. Now, we're not an IDE company and seeing what IBM had in store for building an open source community around Eclipse, we reckoned that would be the right way to go for the CDT as well. The hope was that lots of other non-IDE companies needed an IDE too and we could all share the development cost of it.
It was a gamble and it did take four years to reach this point, but in the end we were right. The reason the CDT is so popular is that there is a huge need in the non-Windows market for a universal IDE that vendors and users can easily leverage for their own needs. Given the huge popularity of Eclipse and with the CDT being the C/C++ solution for Eclipse, it just becomes natural that people gravitate to the CDT. That and the CDT promises to be a high quality, feature rich C/C++ development environment that you have had to pay money for in the past. Everyone like free stuff that's good.
So in the end, I don't think we've done anything in particular to help make the CDT as popular as it is other than simply having the right solution at the right time. I wish I can claim otherwise, but it is what it is. In the next part of this blog entry, though, I will try to list some of the things we've tried aimed at making sure the CDT is an open, welcoming community that will hopefully keep this momentum going. Having something good and free helps with consumption of your open source project, but it doesn't provide any guarantees that it'll attract developers to help you build and test it.
Friday, September 22, 2006
CDT Fall Summit Wrap-up
When I finalized the agenda for the Fall Summit this year, I didn't think there was any way we'd fill up 3 days. Thinking back to last year, we really ran out of things to talk about by noon on the third day. I also figured that it would be a great idea if we had some time to go through the code and work through some of the nitty gritty details with the gang huddled around a laptop. So I decided to set aside Thursday afternoon for that.
Well, at the end if it all, given the number of topics we had to chop out and the number of items where I had to say that we were running behind, we could have spent a whole week. Mind you our brains would have been mush. They were anyway after three days. It was great to see that we have a big development community that knows a lot about the CDT and want to make it even better. It also showed that we need to do this more often, maybe not travel, but find some way to share ideas and debate even virtually.
One of the best items we had, at least for me, was at the very end. I asked the group how we could improve how the CDT is run as a software project. The answer I got back was that we need to work hard on ensuring we have quality releases. In the past, we've been very accommodating to developers, accepting that they come and go and contribute what they can when they can. But that adhoc approach to project management isn't leading to high quality releases, especially at the x.x.0 releases. The team showed a strong desire to, well, be "managed" as a software development team, much like they are when working on their own commercial projects.
So that is now my number one challenge. We need to tighten down the processes, be more strict on quality, and start putting together guidelines that we need the developers to follow. We also need to ensure that our test coverage is managed and improved. Manage the CDT much like any software development project. To me the big challenge is that none of these developers have any contractual obligation to follow any of this. And we have developers from over 10 different organizations. This is open source and they are volunteers (or at least their organizations have volunteered them). So it is going to be a bit of a delicate balance to ensure we have the right mechanisms in place and that the developers honor them.
But at the end of the day, I think just having processes and guidelines will give the developers something to follow and they will probably feel naturally obliged to follow. And with the strength of the characters that we have working on the CDT, I'm sure a little peer pressure will help too. I am very excited about moving into this next stage in the maturing of the CDT project. If it all works, maybe I'll do an MBA thesis on it :).
Well, at the end if it all, given the number of topics we had to chop out and the number of items where I had to say that we were running behind, we could have spent a whole week. Mind you our brains would have been mush. They were anyway after three days. It was great to see that we have a big development community that knows a lot about the CDT and want to make it even better. It also showed that we need to do this more often, maybe not travel, but find some way to share ideas and debate even virtually.
One of the best items we had, at least for me, was at the very end. I asked the group how we could improve how the CDT is run as a software project. The answer I got back was that we need to work hard on ensuring we have quality releases. In the past, we've been very accommodating to developers, accepting that they come and go and contribute what they can when they can. But that adhoc approach to project management isn't leading to high quality releases, especially at the x.x.0 releases. The team showed a strong desire to, well, be "managed" as a software development team, much like they are when working on their own commercial projects.
So that is now my number one challenge. We need to tighten down the processes, be more strict on quality, and start putting together guidelines that we need the developers to follow. We also need to ensure that our test coverage is managed and improved. Manage the CDT much like any software development project. To me the big challenge is that none of these developers have any contractual obligation to follow any of this. And we have developers from over 10 different organizations. This is open source and they are volunteers (or at least their organizations have volunteered them). So it is going to be a bit of a delicate balance to ensure we have the right mechanisms in place and that the developers honor them.
But at the end of the day, I think just having processes and guidelines will give the developers something to follow and they will probably feel naturally obliged to follow. And with the strength of the characters that we have working on the CDT, I'm sure a little peer pressure will help too. I am very excited about moving into this next stage in the maturing of the CDT project. If it all works, maybe I'll do an MBA thesis on it :).
Wednesday, September 20, 2006
More Open Source Hardware
I've got Google Alerts notifying me when something comes up with Eclipse CDT and another one for Eclipse embedded. I'm starting to get a few of these a week, including two today. One came from Lattice Semiconductor. What was noteworthy in this case was they were also open sourcing the design for their 32-bit microcontroller. Now these guys are a lot smaller than Sun who open sourced the design for their Niagara 8-core Sparc chip. But I'm starting to wonder if there really is a trend happening here.
If this means we'll see more people customizing chip designs using hardware description languages and building the software that will run on them, then Eclipse is an obvious host for this kind of hardware/software codesign activity.
If this means we'll see more people customizing chip designs using hardware description languages and building the software that will run on them, then Eclipse is an obvious host for this kind of hardware/software codesign activity.
CDT Summit Day 1
Well we got off to a great start at the Summit today. The day went by real fast and we were all pretty burned out by the end of it so it must have been good :). One highlight for me was when I asked for hands on who was a committer. I got the 7 or so I was expecting. I then asked who had contributed patches. To my happy surprise, I got over 20. That explains why we have so many patches outstanding in bugzilla for the CDT. It is certainly one sign the CDT contributor community is healthy, but its also a sign that we have a lot of work ahead to keep up and to start nominating more committers.
We spend the day introducing eachother and then dug deep into the CDT DOM. I have to admit that one was really dry, and I was the one giving it. We then got an update from the Intel team on what they'd like to do with the build information in the new project wizard and the project properties. Looks like a big change that should hopefully smooth out some workflow issues that we have there. Another big day tomorrow as we review some of the new source navigation and indexing features and dig into debug.
Another thing I'm trying is Skypecast to broadcast the proceedings. You can check it out by following the link. It is definitely a technology preview and we had a hard time getting remote people hooked up to the sound system we have running without horrible echo and feedback. But the broadcast out sounds O.K. (as long as I mute the mic on my laptop, sorry Norbert!) I'm sure it would work better if everyone was working through headsets, instead of trying what we're doing with capturing the audio through a sound board. But it is an interesting way of communicating when working on open source projects.
We spend the day introducing eachother and then dug deep into the CDT DOM. I have to admit that one was really dry, and I was the one giving it. We then got an update from the Intel team on what they'd like to do with the build information in the new project wizard and the project properties. Looks like a big change that should hopefully smooth out some workflow issues that we have there. Another big day tomorrow as we review some of the new source navigation and indexing features and dig into debug.
Another thing I'm trying is Skypecast to broadcast the proceedings. You can check it out by following the link. It is definitely a technology preview and we had a hard time getting remote people hooked up to the sound system we have running without horrible echo and feedback. But the broadcast out sounds O.K. (as long as I mute the mic on my laptop, sorry Norbert!) I'm sure it would work better if everyone was working through headsets, instead of trying what we're doing with capturing the audio through a sound board. But it is an interesting way of communicating when working on open source projects.
Monday, September 18, 2006
CDT Summit Eve
The CDT Fall summit for this year starts tomorrow here at QNX headquarters and I'm getting both excited and nervous, as I guess I should. We've had a number of summits in the past starting all the way back with the first one in July 2002 when QNX brought the CDT as we know it to the world. That summit and pretty much everyone since then has had kind-a the same feel. Lots of people have been interested in what was going on, but few have had the resources to commit to helping out.
But you know, there's nothing wrong with that. It's a pretty difficult decision for corporations to commit resources to work on open source projects. It's difficult to track the return on their investment and there are a slough of legal issues that need to be addressed and tracked to make sure the IP walls are set up correctly, and I'm not just talking networking. I've learned to be patient, not get too down when hopes fail to materialize. In the end, simply using the CDT and distributing it in their products means that the CDT is getting good test coverage, which is just as important these days.
My feel for this one, though, is different. Maybe it's because I'm starting to be overly optimistic. We have around the same number of attendees registered as we did last year, and a lot of them are the same faces. However, this year most of the attendees have been contributors to the CDT. Some have become committers over the year and some will become committers shortly after the summit. We'll use this as an opportunity make sure we are talking to eachother and co-ordinating our work. We'll also use it as a team building exercise as I'm sure we'll find a few battles along the way. It sure helps when you know the person at the other end of the bugzilla entry when smoothing over issues.
Finally this year, it looks like our contributors summit will focus much less on recruiting contributors and much more on co-ordinating actual contributions. It's a much funner summit to run and hopefully a much funner summit to attend.
But you know, there's nothing wrong with that. It's a pretty difficult decision for corporations to commit resources to work on open source projects. It's difficult to track the return on their investment and there are a slough of legal issues that need to be addressed and tracked to make sure the IP walls are set up correctly, and I'm not just talking networking. I've learned to be patient, not get too down when hopes fail to materialize. In the end, simply using the CDT and distributing it in their products means that the CDT is getting good test coverage, which is just as important these days.
My feel for this one, though, is different. Maybe it's because I'm starting to be overly optimistic. We have around the same number of attendees registered as we did last year, and a lot of them are the same faces. However, this year most of the attendees have been contributors to the CDT. Some have become committers over the year and some will become committers shortly after the summit. We'll use this as an opportunity make sure we are talking to eachother and co-ordinating our work. We'll also use it as a team building exercise as I'm sure we'll find a few battles along the way. It sure helps when you know the person at the other end of the bugzilla entry when smoothing over issues.
Finally this year, it looks like our contributors summit will focus much less on recruiting contributors and much more on co-ordinating actual contributions. It's a much funner summit to run and hopefully a much funner summit to attend.
Friday, September 08, 2006
Open Source Hardware
I'm sure I've told this story before somewhere, but I used to sit across from an ASIC designer many years ago. This is when I first started using ObjecTime Developer for software modeling back in the early 90's, a couple of years before I joined the company. He was marveling at how we software designers had started using graphical tools, just as ASIC designers were abandoning similar tools for textual description languages. I'm not sure why they made that transition, but given the complexity of the chips they were designing, my bet is that the graphics didn't scale well for them and the tools back in the early 90's weren't very good - no Eclipse back then!
This guy was coding in a hardware description language called Verilog. I peaked over his shoulder one day and saw that it looked a lot like C code. I found that very interesting but it took many years before I sat down and took the time to learn a bit more about the language and what it could do (there wasn't much of an Internet back then either). It indeed was C-like and was structured a lot like C, and I'm sure suffers the same scalability issues that programming in C can sometimes cause. Thankfully, there is an Eclipse plug-in to help you write your own Verilog code.
Fast forward to the recent future and my interest in MultiCore processing, I found it quite interesting when Sun announced that they were open sourcing their Niagara line of processors. Diving deeper, I was able to find the Verilog code for their T1 chip published on www.opensparc.org. Other than being cool to look at and maybe interesting for students to learn CPU design with, I didn't really see the benefits of open sourcing a CPU design.
Then yesterday, I ran across an announcement from Simply RISC that their engineers had taken the open source T1 code and made a simple SPARC embedded processor out of it. Of course with the T1 source being GPLed, they have released the source for their CPU as well. Is this the start of something? I'm still a bit doubtful. Chip companies make most of their money on the designs they come up with, not necessarily the chips themselves. But it is an interesting phenomenum to watch out for.
This guy was coding in a hardware description language called Verilog. I peaked over his shoulder one day and saw that it looked a lot like C code. I found that very interesting but it took many years before I sat down and took the time to learn a bit more about the language and what it could do (there wasn't much of an Internet back then either). It indeed was C-like and was structured a lot like C, and I'm sure suffers the same scalability issues that programming in C can sometimes cause. Thankfully, there is an Eclipse plug-in to help you write your own Verilog code.
Fast forward to the recent future and my interest in MultiCore processing, I found it quite interesting when Sun announced that they were open sourcing their Niagara line of processors. Diving deeper, I was able to find the Verilog code for their T1 chip published on www.opensparc.org. Other than being cool to look at and maybe interesting for students to learn CPU design with, I didn't really see the benefits of open sourcing a CPU design.
Then yesterday, I ran across an announcement from Simply RISC that their engineers had taken the open source T1 code and made a simple SPARC embedded processor out of it. Of course with the T1 source being GPLed, they have released the source for their CPU as well. Is this the start of something? I'm still a bit doubtful. Chip companies make most of their money on the designs they come up with, not necessarily the chips themselves. But it is an interesting phenomenum to watch out for.
MultiCore: The True Promise of Eclipse
So, I needed a board to help try out some JTAG things (for those readers not involved with embedded development, a board is a little computer kind-a thing). We had just received an OMAP board which uses a TI chip that contains both an ARM general purpose processor as well as a TI DSP (digital signal processor). Of course, my focus was on the ARM processor that runs our operating system and it was pretty cool to getting it up and running with little effort.
But after a while, I started wondering what people use this board for. I've been away from embedded development for a few years and man have things changed while I was away. I soon discovered that the main use of this thing is for audio processing. There are some audio jacks as well as a connector to plug in an LCD screen. By programming some audio processing algorithms into the DSP, you could make a pretty cool multimedia device with this thing.
My curiosity then wondered over to how one would program the DSP. If I had a compiler with an integration with the CDT and a debugger that understood how to debug the DSP and that was also integrated with the CDT, then I'd then have a complete multi-core development solution where I could have regular software projects and DSP projects and work on them all at the same time.
It's a very interesting time in the embedded industry with the multi-core phonmenun. I think we'll see a lot of new processors come out that have specialized parts. What I hope to see, and I'm pretty sure it will happen, is different vendors working together integrating their Eclipse-based technologies and unify their development activities into a single workflow for the developer who sees these boards as a single target. That is the true promise of Eclipse!
But after a while, I started wondering what people use this board for. I've been away from embedded development for a few years and man have things changed while I was away. I soon discovered that the main use of this thing is for audio processing. There are some audio jacks as well as a connector to plug in an LCD screen. By programming some audio processing algorithms into the DSP, you could make a pretty cool multimedia device with this thing.
My curiosity then wondered over to how one would program the DSP. If I had a compiler with an integration with the CDT and a debugger that understood how to debug the DSP and that was also integrated with the CDT, then I'd then have a complete multi-core development solution where I could have regular software projects and DSP projects and work on them all at the same time.
It's a very interesting time in the embedded industry with the multi-core phonmenun. I think we'll see a lot of new processors come out that have specialized parts. What I hope to see, and I'm pretty sure it will happen, is different vendors working together integrating their Eclipse-based technologies and unify their development activities into a single workflow for the developer who sees these boards as a single target. That is the true promise of Eclipse!
Sunday, September 03, 2006
Did someone say doughnuts?
I just read Bjorn's note comparing doughnut stores to open source businesses. From what I hear that note probably made more an impact on Canadians that it did others. For some reason, we've rallied around the doughnut as our national past time and our waste-lines are paying the price!
At any rate, I totally agree with his assessment. My spin on it, you can make money by packaging up open source and selling priority support for it, and you can make money by taking open source and customizing it for a small vertical market. Certainly we at QNX are doing the second, taking Eclipse and customizing it to work well for developers writing applications for our operating system.
Another analogy I thought of also has to do with Tim Hortons. After Wendy's (the burger Wendy's) merged with Tim Hortons you started seeing a lot of Wendys and Timmy's co-located in the same restaurant. So the analogy could go that people love doughnuts. So when the come to Tim's and get their fix, they see the Wendy's there and decide to stay for lunch.
So what I've also seen vendors do is package Eclipse as a sort of loss leader to get people interested in their higher margin products. My recent blog on the JTAG vendor Ronetix is an example of that. And I think we'll see a lot more as well as Eclipse becomes ubiquitous (2.27 million users!). Vendors will find they have to play the Eclipse game just to keep up with the Jones.
At any rate, I totally agree with his assessment. My spin on it, you can make money by packaging up open source and selling priority support for it, and you can make money by taking open source and customizing it for a small vertical market. Certainly we at QNX are doing the second, taking Eclipse and customizing it to work well for developers writing applications for our operating system.
Another analogy I thought of also has to do with Tim Hortons. After Wendy's (the burger Wendy's) merged with Tim Hortons you started seeing a lot of Wendys and Timmy's co-located in the same restaurant. So the analogy could go that people love doughnuts. So when the come to Tim's and get their fix, they see the Wendy's there and decide to stay for lunch.
So what I've also seen vendors do is package Eclipse as a sort of loss leader to get people interested in their higher margin products. My recent blog on the JTAG vendor Ronetix is an example of that. And I think we'll see a lot more as well as Eclipse becomes ubiquitous (2.27 million users!). Vendors will find they have to play the Eclipse game just to keep up with the Jones.
Saturday, September 02, 2006
Windows SDK RC1
I've stated a few times now that although the CDT is highly used in the embedded and Linux/Unix markets, I don't think we've conquered the world until the CDT is seen as a valid alternative to Visual Studio for Windows development. Looking at the whole Eclipse ecosystem and all the components available for it, I just think it has a higher value proposition than Visual Studio. At the very least you get a cross platform development environment that you can theoretically build any application with, once all the pieces are there that is.
So I've been working a little on adapting the CDT for Windows development starting with support for Microsoft's C++ compiler. Over the last couple of years they've been shipping it for free, first as a separate toolkit, and now as part of the .Net 2.0 SDK. But, in order to get it working, you had to download a few pieces, including the Platform SDK, and if you wanted to do debugging outside of Visual Studio, the Debugging Tools for Windows. I felt it was pretty complicated to set up, especially for newbies, and of course these pieces aren't redistributable so we couldn't shrink wrap it for you.
But someone pointed me at the new Windows SDK which is part of the Vista program (which is why I was confused since I thought it was a Vista thing only, but it is not). This SDK has recently reached Release Candidate 1. As described in this MSDN TV program (these programs are pretty useful and something we should consider for Eclipse), this new SDK is really a combination of all the pieces you need to build Windows applications, both managed (i.e. .Net) and unmanaged (i.e. native).
What I found interesting was their focus on providing command line tool support for "people who like to work that way". Now, I don't know anyone developing Windows applications that like to work that way. So I read into it that they are really talking about 3rd party IDEs such as the CDT. With the tools provided by this SDK, it should be a pretty simple matter of integrating them as a tool chain just as we do with the gnu tools. Download the SDK, download the CDT and the Windows integration, and you are off and running.
At least that's my hope, which of course will only be successful if it receives community attention. But it sure would be a boost for Eclipse to be seen as the development environment for everyone, without prejudice.
So I've been working a little on adapting the CDT for Windows development starting with support for Microsoft's C++ compiler. Over the last couple of years they've been shipping it for free, first as a separate toolkit, and now as part of the .Net 2.0 SDK. But, in order to get it working, you had to download a few pieces, including the Platform SDK, and if you wanted to do debugging outside of Visual Studio, the Debugging Tools for Windows. I felt it was pretty complicated to set up, especially for newbies, and of course these pieces aren't redistributable so we couldn't shrink wrap it for you.
But someone pointed me at the new Windows SDK which is part of the Vista program (which is why I was confused since I thought it was a Vista thing only, but it is not). This SDK has recently reached Release Candidate 1. As described in this MSDN TV program (these programs are pretty useful and something we should consider for Eclipse), this new SDK is really a combination of all the pieces you need to build Windows applications, both managed (i.e. .Net) and unmanaged (i.e. native).
What I found interesting was their focus on providing command line tool support for "people who like to work that way". Now, I don't know anyone developing Windows applications that like to work that way. So I read into it that they are really talking about 3rd party IDEs such as the CDT. With the tools provided by this SDK, it should be a pretty simple matter of integrating them as a tool chain just as we do with the gnu tools. Download the SDK, download the CDT and the Windows integration, and you are off and running.
At least that's my hope, which of course will only be successful if it receives community attention. But it sure would be a boost for Eclipse to be seen as the development environment for everyone, without prejudice.
Friday, September 01, 2006
CDT everywhere
I continue to be surprised by how many vendors are redistributing the CDT with their products. Lately I've become interested in JTAG hardware debuggers and how to best hook them up to Eclipse for some real low level bit hacking debug workflows. This is something that probably deserves it's own blog entry and it's not really the theme of this story.
At any rate, I ran across a JTAG vendor called Ronetix who appears to build a pretty full featured device similar to the Abatron device I've been playing with lately. So quickly browsing Ronetix web site, I see that they have a Starter Kit that they sell. Low and behold it "Includes Eclipse IDE". Going to the product page for the starter kit I see they have a screenshot of Eclipse in action, and, yes, it is the CDT.
At some point I need to sit down and figure out what is driving the success of the CDT. It certainly fills a need that maybe isn't getting addressed by others, i.e., an IDE for non-Windows development that is extensible and ubiquitous (mind you I'm still keen on CDT for Windows development too). I'll have to ask the 34 developers that are currently registered for the upcoming CDT Contributors Summit why they find the CDT important enough to invest in. No matter the reason, it's been a fun ride and we're looking forward to a great year of collaboration toward CDT 4.0.
At any rate, I ran across a JTAG vendor called Ronetix who appears to build a pretty full featured device similar to the Abatron device I've been playing with lately. So quickly browsing Ronetix web site, I see that they have a Starter Kit that they sell. Low and behold it "Includes Eclipse IDE". Going to the product page for the starter kit I see they have a screenshot of Eclipse in action, and, yes, it is the CDT.
At some point I need to sit down and figure out what is driving the success of the CDT. It certainly fills a need that maybe isn't getting addressed by others, i.e., an IDE for non-Windows development that is extensible and ubiquitous (mind you I'm still keen on CDT for Windows development too). I'll have to ask the 34 developers that are currently registered for the upcoming CDT Contributors Summit why they find the CDT important enough to invest in. No matter the reason, it's been a fun ride and we're looking forward to a great year of collaboration toward CDT 4.0.
Tuesday, August 15, 2006
Greenphone, the open source phone
Everytime I look at the net these last few days, something pretty cool pops up. This time was an announcement from Trolltech, the Qt people, about a new product they plan on releasing in September called Greenphone. This is a GSM/GPRS phone built on an embedded Linux kernel with Trolltech's embedded version of Qt called Qtopia. It is really only sold as a development platform and comes with the necessary SDK.
Now, I think this is a bit different than the open source gaming device I talked about earlier. I don't think Trolltech wants to get into the phone business. In some ways, I think they are just curious about the kind of applications people will build for such a device. And, of course, in the end their goal is to sell more Qtopia licenses to commercial developers.
But I've always wondered what kind of applications make sense on such a small platform. Web browsing when the screen is only 240 pixels wide makes even less sence than browsing the web on a TV. I'll be watching along with Trolltech to see what people will come up with. And, as always, it'll be interesting to see how many people use the CDT to develop for this platform.
Now, I think this is a bit different than the open source gaming device I talked about earlier. I don't think Trolltech wants to get into the phone business. In some ways, I think they are just curious about the kind of applications people will build for such a device. And, of course, in the end their goal is to sell more Qtopia licenses to commercial developers.
But I've always wondered what kind of applications make sense on such a small platform. Web browsing when the screen is only 240 pixels wide makes even less sence than browsing the web on a TV. I'll be watching along with Trolltech to see what people will come up with. And, as always, it'll be interesting to see how many people use the CDT to develop for this platform.
Microsoft XNA Express, maybe they do get it...
Continuing on my vacation game development theme (and yes, I am spending a lot of time with my family and doing things around the house, it's not all geek time ;), Microsoft has just announced that they will be releasing an Express version of their XNA Game Studio for free for Windows development and only $99 for Xbox 360 development. This offering will build on top of their free Visual C# Express IDE and will include some tools for integrating content as well as their XNA Framework game-engine-type-thing. They are really pushing for game development in C# and the CLR, even for the Xbox 360.
As the guy in their XNA Overview video mentioned, the game developer market is pretty small relative to others and selling tools to this market isn't going to be a money maker. What's important to Microsoft is that they help developers as much as they can to get them building content for Microsoft's platforms. It doesn't really matter how much they charge for the tooling and frameworks since they will make their money on the platforms. And with good free offerings, they'll get the kids hooked making games for Microsoft platforms and that will carry that into their careers as professionals.
I am still of the opinion that Eclipse can be an even greater game development environment since it is truly multi-platform. There's no reason why we couldn't build a set of plug-ins that allow developers to target all of the consoles and all of the desktop platforms, including Microsoft's.
Actually there may be one reason, who's going to pay for it? Microsoft is busy devoting itself to Visual Studio, and I haven't seen much interest from the other vendors in contributing to such an open source project (although I know from bug reports and one quick discussion years ago that Sony Playstation group is or at least has used the CDT). It would take some sort of consortium to organize and pay for the project and get involvement from the various players. It could be done and it would be cool for Eclipse but I'm not sure that industry is ready for such co-opetition as much as the embedded industry is.
As the guy in their XNA Overview video mentioned, the game developer market is pretty small relative to others and selling tools to this market isn't going to be a money maker. What's important to Microsoft is that they help developers as much as they can to get them building content for Microsoft's platforms. It doesn't really matter how much they charge for the tooling and frameworks since they will make their money on the platforms. And with good free offerings, they'll get the kids hooked making games for Microsoft platforms and that will carry that into their careers as professionals.
I am still of the opinion that Eclipse can be an even greater game development environment since it is truly multi-platform. There's no reason why we couldn't build a set of plug-ins that allow developers to target all of the consoles and all of the desktop platforms, including Microsoft's.
Actually there may be one reason, who's going to pay for it? Microsoft is busy devoting itself to Visual Studio, and I haven't seen much interest from the other vendors in contributing to such an open source project (although I know from bug reports and one quick discussion years ago that Sony Playstation group is or at least has used the CDT). It would take some sort of consortium to organize and pay for the project and get involvement from the various players. It could be done and it would be cool for Eclipse but I'm not sure that industry is ready for such co-opetition as much as the embedded industry is.
Sunday, August 13, 2006
GP2X - The open source handheld gaming system
Well, I'm on holidays right now but I still like to keep in touch with what' s happening in the industry and still monitor a few Internet rag sites regularly, including my favorite, The Inquirer. Today, I saw in one of their Hardware Roundup postings a link to a review of the GP2X Personal Entertainment System which uses an ARM dual core processor that runs Linux. I've always been interested in game development, so finding a handheld gaming machine that ran Linux sent me off on a trail to find out more.
Well it turns out it's made in Korea by Gamepark Holdings as a follow up to a previous edition handheld which was actually made by another company called Gamepark. Apparently the engineers didn't like what the original company wanted to as a follow up so spun out and made an almost identical company to do it the way they wanted. Interesting inside story there, I'm sure.
Anyway, they advertise this machine as the "Open Source Gaming Device", which I find pretty cool and again fits into the model I've seen over and over again with open source development. The company sells the device (and it's pretty cheap at only about $200), and then fosters an open source community around writing software for it and manages an SDK of open source libraries to support them. They also use a number of the open source Linux apps to build up a suite of multi-media functions for video and audio for users to get started. I haven't seen any analysis about how successful they've been but the community forums seem to be pretty active.
I was a bit disappointed, of course, when I saw that the SDK didn't ship with Eclipse/CDT components, but I was happy to see someone in their community blogging about using the CDT in this environment. Of course, it's a natural fit with CDT's built-in support for gnu development, including cross-development for embedded operating systems such as Linux (and QNX Neutrino ;). I would be quite interested in helping anyone who would like to push to make the CDT a more formally "supported" development environment for this cool little box.
Well it turns out it's made in Korea by Gamepark Holdings as a follow up to a previous edition handheld which was actually made by another company called Gamepark. Apparently the engineers didn't like what the original company wanted to as a follow up so spun out and made an almost identical company to do it the way they wanted. Interesting inside story there, I'm sure.
Anyway, they advertise this machine as the "Open Source Gaming Device", which I find pretty cool and again fits into the model I've seen over and over again with open source development. The company sells the device (and it's pretty cheap at only about $200), and then fosters an open source community around writing software for it and manages an SDK of open source libraries to support them. They also use a number of the open source Linux apps to build up a suite of multi-media functions for video and audio for users to get started. I haven't seen any analysis about how successful they've been but the community forums seem to be pretty active.
I was a bit disappointed, of course, when I saw that the SDK didn't ship with Eclipse/CDT components, but I was happy to see someone in their community blogging about using the CDT in this environment. Of course, it's a natural fit with CDT's built-in support for gnu development, including cross-development for embedded operating systems such as Linux (and QNX Neutrino ;). I would be quite interested in helping anyone who would like to push to make the CDT a more formally "supported" development environment for this cool little box.
Subscribe to:
Posts (Atom)