I’m having a hard time getting into writing my paper for the upcoming Embedded Systems Conference. So I figured I’d spend some time writing here where I seem to never have writer’s block, at least once I find a topic to talk about and a second to do it.
But it’s a sign of the time of year. EclipseCon is just over two weeks away and then this year the Embedded Systems Conference and the Eclipse PluginFest for Mobile/Embedded are happening in the same week in April. Time to get prepared.
The PluginFest is a special event that we started last year. It was a pretty interesting time. Part of it was the thrill of spending some time in London, England (which I hear is nicer than London, Ontario, Canada but I’ve never been to the latter :). But I think it was mainly the chance to get together with Eclipse people again. We have a great community that have some really interesting and passionate individuals that make these events a must attend.
The PluginFest is a bit different than your average Eclipse event, in that you are encouraged to talk about your commercial product and work with other commercial vendors as we prove that the concept of plug-in truly does enable the interoperability between these products that we promise.
And a key component of the interoperability story is the Eclipse platform projects that everyone works to extend. These projects, which include the CDT and DSDP projects, become a bit of a focus as well. I talked to a number of people last year who had questions and ideas for me and the CDT. And I hear there’s a keen interested in having project members present again this year.
But that left me a little concerned. EclipseCon is actually a month earlier than the PluginFest this year. And in many ways EclipseCon is meant to be the venue for people working on projects to gather and discuss and ask. For some reason, though, we’ve always had trouble getting a strong program and attendance from the embedded community for EclipseCon.
It really shows that there is still a lot of work to be done to boost that community. Which is odd, since they are a community that I think desperately needs Eclipse technology to work for them. But then maybe that’s one reason why. It doesn’t necessarily work for them.
It’s been a quiet campaign, I guess, at least relative to other elections that are going on right now. Thanks to Ed Merks who we can always expect to stir up the pot 🙂 We did end up have a really healthy debate over the way the Committer reps are elected. One thing we’re not short of at Eclipse is passionate contributors and that’s good for everyone concerned.
I encourage all the committers to take the time to vote. It’s a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you’re needs.
I have no idea how I’m going to fare since my campaign budget didn’t allow for any polling ;), but I’m glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I’m not sure we’ll get CNN to cover the results, but it’ll be fun to see how it all unfolds.
I was going to leave a comment on Ed Merks blog entry on “One Committer, One Vote?”, but I found I filled up the space. That probably means I should do it in my own blog.
For those who haven’t read Ed’s blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.
But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.
Now, it doesn’t shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I’m not sure I have much more of a chance of winning than they do. And that’s good for Eclipse all round.
One of the things that we deal with on most software projects that continue on for a few years is turnover. People come and go. I’m not sure it’s more prevalent with the software industry than others, but it is painful. As managers we spend a lot of effort making sure transition plans are put in place when it happens so that the asset that is the developer’s knowledge isn’t lost.
Unfortunately, we haven’t done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don’t really have a manager/employee relationship with them, it doesn’t really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I’m not sure they consider the possibility that they may get pulled off the project and they don’t spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it’s open source, their employers don’t give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn’t consider it prudent to enforce that documentation be provided. But we’re definitely paying for it now as we have a pretty big bulk of undocumented code that we’re trying to fix bugs in.
So the lesson of the day is to code like you won’t be there tomorrow. You can create the best system ever, and people will appreciate it while you’re there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they’ll be wishing you could come back.
One of the issues I have to deal with when building Eclipse-based software is the need to test on a number of different platforms. Yeah, “Write Once, Run Everywhere”, whatever. To build a proper IDE and especially the new Installer stuff I’m working on, you need to access the native platform. There’s no getting away from it. And with that, you need to deal with all the “special” behaviors that these platforms offer you.
And when you’re dealing with many platforms, it’s gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I’ve mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I’d try alternatives.
One I found that worked pretty good was VirtualBox built by German company innotek. It’s got a weird license. It’s “Free for personal use”. It has an open source aspect to it but it’s a subset of the whole thing that’s free for personal use so it’s pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.
So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 – innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!
I’m not sure how to interpret Sun’s motives or what will happen to VirtualBox once it’s in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.
As I march into the exciting world of Virtual Instruments and VST and using the CDT build something I think is really cool, I keep running into the question: what toolchain should I be using for Windows development. Without a debugger, what’s the point of using the Visual C++ compiler. My gut tells me that it’s probably got a better optimizer than the old 3.4 that MinGW has at the moment, and that will be key to building a high performance plug-in for digital audio workstations.
At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?
I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven’t really seen much progress. But maybe I’m just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.
So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn’t I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I’m going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.
In my mind that would be huge. With gcc 4.3 with it’s strong optimizer along with other goodies like OpenMP, we’ll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.
I guess if you look through the history of this blog, I’ve complained the odd time about how frustrating it can be to work in the Eclipse environment. Now don’t get me wrong, the frustration is incredibly minor compared to they success I’ve had in helping create a successful C/C++ IDE in the CDT. We’ve been able to put together a solution that has been very well received by the community and is having good commercial success as well. It’s all good, well at least for the most part.
But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I’ve decided to throw my hat into the ring. It’s not an easy decision. I wonder how successful I’ll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it’ll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.
So what are the kind of things I’m talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I’ve seen a lot of frustration but I think the solutions are available and don’t require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what’s going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I’d be interested in finding ways to ensuring that these guidelines are respected.
Of course I have other things that I’ve mentioned in this blog before. I still am saddened that we can’t have complete IDE solutions hosted and branded as Eclipse distributions. I’d love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn’t the only solution here.
And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.
I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.
I’ve really started to get into this software synthesizer thing with VST albeit the older 2.4 version since most digital audio workstations don’t support the new one (they could learn a lesson from Eclipse about keeping a community happy with API stability). There is a pretty good community sharing ideas and tips and examples. And it’s a pretty low overhead activity that has a better chance of turning into a hobby than some of my other grand schemes. Most free software synths seem to be build by individuals (versus my desire to explore game development – ever see the credits at the end of a game?).
So I’ve started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I’ve got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I’m using the CDT, of course, with the Microsoft Visual C++ build integration I’m working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.
At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I’ve had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That’s fine for simple things, but I found myself missing a real debugger integration as I’ve started to get interested in the more complex data structures I need to deal with.
Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I’d love to see gcc 4.x for MinGW and I’d love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn’t a bigger community working on better gnu tools for Windows development.