Monthly Archives: November 2009

Diversity is not the only answer

Dave Carver started it and Pascal fed the fire. If you missed it, there are confusing and highly inaccurate statistics captured by the Eclipse Foundation that measure diversity in the Eclipse projects. Stats or not, there are a lot of projects where it’s clear, there is one vendor paying a very disproportionate number of comitters that work on the project. And it’s not always IBM.

But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?

A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I’ve done and career limiting decisions I’ve made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.

I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.

Linux Distros, The Great Melting Pot

I’ve been talking a deeper look at Fedora lately as Fedora 12 was just released and I was checking out all the MinGW cross-development packages available there. While I was there I looked across all the packages included in the “Everything” folder. I even gave eclipse-cdt a try and was impressed to see 6.0.0 there (although 6.0.1 would have been more impressive ;)). It’s also impressive to see so many of the Eclipse projects represented there. And just looking at the breadth of open source content, almost every open source project I’ve looked at is included, including the bullet physics engine, OGRE and Irrlicht game engines, blender the 3D modeling tool, clutter and mutter and even an early preview of the new Gnome Shell.

It’s an incredibly rich set of libraries and tools, and it’s got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it’s best effort to kill performance, I’m thinking again of going back. Windows 7 is pretty and I’m very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.

The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I’ve mentioned this before, but the projects really do operate as silos, even Photran and CDT and we’ve tried hard not to do that, it’s just too easy.

But it takes a group of people with the vision and the gumption to drive that vision home. I’d like the Eclipse Architecture Council to be that but as with all things Eclipse, it’s really up to committers and the vendors that pay them to make this happen. Here’s hoping someone does.

Chrome OS, it is what it is

I guess I got caught up in all the hype over Chrome OS. It’s an idea I’ve bounced around for years as I mucked around learning about embedded Linux. Replace the standard Linux desktop UI with only a browser and throw it on a mobile device. With everything on the web these days, or at least a minimal amount to do something useful, why not?

But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.

So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it’s proper name, is.

¬†You log in with your Google account and, bang, you’re in the Chrome browser looking at your Google stuff.
But it is what it is. There’s no application menu, no app market, or anything like that. Everything you do is over the web. I did notice an extensions mechanism, and maybe that’s how you take advantage of the native environment, maybe not.
When I had thought of a Web OS, this summer, my thoughts turned to the Eclipse Run-Time and using that in conjunction with the browser to have local apps written for the Eclipse platform. I would also think you’d want to launch 3D and multimedia content full screen, or something. But that’s not what Chromium OS is. It’s web or bust.
So while Chromium OS is interesting, I’m way less excited about it. I think the door is still open for a netbook Linux platform that combines local native apps with the Web experience. Moblin is certainly making strides there for the consumer space. And I’ve been trying out the GNOME Shell which offers an experience much like Windows 7 for the power users. This story isn’t finished yet.

Visual Programming for Multi-Processing

I spent a little time on the weekend taking a deeper look at the Unreal Development Kit (www.udk.com), and I continue to be shocked that they are giving out all this great technology to you and me to play with. And it really blew me away when I saw their Materials editor. There’s a tutorial here, http://udn.epicgames.com/Three/MaterialsTutorial.html.

Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you’re ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.

This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I’ve been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.

To see it in two places now, I’d love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out…

Openness Shades of Grey

Motorola’s newest phones are hitting the streets and promise Android goodness thanks to the latest Android release 2.0. Now if you think of Android as an open souce platform, you may have run over to the Android Open Source Project and tried to download the 2.0 source to see how they made it.

Uh, no. Android isn’t that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they’d drop the open and project and just call it Android Source.

The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.

Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That’s certainly what drives us on the CDT to be as open as we can.

The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they’ve opened up as they realized they couldn’t do it on their own any longer. So you change to maintain success.

I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they’d like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone’s code for better 3D support.

It’s all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.

Unreal Development Kit

Wow. Unreal Development Kit. Free. Or at least free for free content. I’ve always wondered how developers create content for the big game engines, id and Unreal. And now I know and I have it installed on my laptop. For free. Can you tell I’m beside myself here. Check it out: http://www.udk.com.

At any rate, Epic has released their development kit for free. It’s a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you’ll need to pay for a license as you should).

Looking back at the archives, my second blog entry after saying “Hi”, was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.

And playing with the UDK, I don’t see any technical reason why such tools couldn’t be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.

That was my dream for Eclipse back in 2005, and it’s still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream…