is back

Choose one

I first visited India in 2004 for what was then called “Linux Bangalore”. I had put in three talk proposals: a business-y one about the frictions encountered deploying open source in the enterprise, a social policy one about our experiences running and the Linux Australia organization, and a technical tutorial about rapid application development in GNOME (didn’t everyone give a Glade tutorial in those years?). I put in three talks because I didn’t really quite know what they were focusing on and (assuming that they’d want me at all) wanted to offer them some options.

Silly me. They chose all three. :)


And thus began my adventure with the conference that in subsequent years was renamed to “” and despite many evolutions, has remained one of the most fascinating and engaging conferences I’ve been able to attend.


Going to a country with a different culture can be confronting; I have not been better treated by any group of organizers than the outstanding way they took care of their speakers at that first conference.

One of the amazing things about the conference is that it has evolved. That’s not always easy; you cheer when it grows along a path you support, but then you are shocked when some of the people involved go and do something that seems incompatible with what you thought the conference was about. That’s pretty common with any endeavour, though it’s amazing how wrapped up we sometimes get about such things.

Burn out & back

The organizers have made the classic mistake of being good at what they do, and they’ve burned out a few times. But there’s no better indication that they’re open source people for-real: they can’t let it go. After a hiatus of a few years, the conference is back!

I have no idea whether I’ll be able to go this year or not; the conference is well known now and there are a lot more domestic speakers vying for slots. And that’s excellent; one of the driving motivations of the conference when it was first founded was to promote Linux and Open Source within India. Not just getting people to use it, but encouraging people to create open source technology too.

It’s some years later now, and I’m hoping a whole new generation of people can join the community at Whether you’re involved in Linux, contribute on an already established open source project; or (most importantly!) if you’ve been working away on your own and don’t realize there are like-minded people out there, I can think of nothing better to help you further your cause than spending some time with this amazing crowd. You don’t have to be a speaker; open source isn’t only about writing code, and like many community-run events it depends on its enthusiastic volunteers; if you’ve got some time and are interested, I’m sure they would appreciate your help this year.


The CfP is out.

Talking about getting involved

I’m giving a talk at tomorrow, Saturday, at 10am:

Presentation titled User To Hacker in 90 minutes

I realize that this is only of interest to people in Bangalore this week and reading, but here’s my abstract:

The essence of open source is not USING free software, but CREATING it. The purpose of this talk is to teach you how to contribute to open source projects.

Admittedly, getting involved isn’t as easy as it could be, but that’s often because you haven’t had an opportunity to learn how to go about participating in a project’s development.

This talk is aimed at people who probably already know something about Linux, already know how to program, and already believe how important free software is… but haven’t yet made the jump to being contributors themselves. And that’s LOTS of people. So, it’s time to become and open source hacker.

It’s easy to talk about “interacting with the community” and “filing bugs” and “submitting a patch”, but until you know how to do this, it can all be a bit daunting. So we are going to be do all these things, TOGETHER, on stage, LIVE. We’re going to file real bugs about real problems in real open source projects, and then we’re going to fix ‘em, right there on the screens in front of you.

How do you contribute? You have to check out source code, learn how to build open source software, run it, test it, and debug it… but it doesn’t stop there! Then comes creating and sending patches, receiving feedback from the upstream project, dealing with rejection, but finally when you’re successful exalting your success.

For the beginners in the audience we’ll be demonstrating what you do to submit to upstream, but we’re also going to show what the upstream people do when you make that contribution. So we’ll see the whole open source process, beginning to end.

Take joy in your work, do your work in the open, and open it to the world. Do that, and you ARE an open source contributor.

Actually, it’s not just me — my good friend Shreyas Srinivasan and I will be doing the demos jointly. So the best part will be watching the two of us making fools of ourselves on stage.

I hope you can make it!


P.S. 10 am means Ten O’Clock in the morning. People who are late don’t get any free chocolate chip cookies.

GNOME Mascot?

It’s the GNOME Project Day at!

Máirín Duffy talking about getting involved in art, marketing and branding in GNOME … question from the audience: we have the GNOME foot logo, but why doesn’t GNOME have a mascot?

I asked quickly in #gnome-hackers and James Henstridge suggested that the mascot was:

“whatever made the footprint”

It’s a giant invisible beast! :)


Do you have what it takes to be a volunteer at a conference?

Speaking of tireless volunteers:

The amazing thing about Open Source is that there are so many ways to be involved. Unlike any other area of human endeavour, you are not limited by race, gender, or the requirements of joining a profession. The only barrier to entry is that you participate.

Like most things, Open Source is about people. And a great way to meet other people is by getting involved at conferences. Technical conferences always need people to help out, and so it’s a great way to be able to spend time with the local community and with the speakers who have come from near and far. And just think of all the free T-Shirts you’ll collect. Geek nirvana, really.

Two really amazing conferences are coming up. If you’re anywhere in Asia, you should be making plans to get down to Bangalore for India’s greatest Linux & Free Software event, And whether you’re in Australia, New Zealand, or France you should be booking your flights to get to Melbourne for the eighth Both conferences are the wonderful experiences they are in no small part because of the energy and enthusiasm of the volunteers who help with everything from A/V to picking up speakers at the airport to helping get people registered to making sure a conference network is up and running [hackers get grumpy when they can’t get their email :)]. If you’ve got a little time, if you’re looking for a way to get involved, then consider signing up as a volunteer to help out.

The Call for Volunteers for is out, and time is running out to sign up, so act fast!

To make a difference you have to get involved

I promised Atul that I wouldn’t subvert his volunteers this year. Last time around, the person who was supposed to to be monitoring the time and telling me to wind up was so enthralled by what I was saying (and now he’s a major contributor to the project that I was talking about; go figure) that they completely forgot to tell me to sit down. See? Me going overtime isn’t always my fault. Honest!


The conference with attitude is back 2007 announced

It’s always difficult for a community based conference with a multitude of demands all pulling in different directions. The temptation is always to try and please everyone. There always seems to be people who want the focus to be on converting people to Linux (inevitably because they’re trying to sell something, and figure the conference is there to create new customers for them). These groups seem to object if the conference isn’t all about new users and explaining why Open Source is so great.

But here we are in 2007. There is no need to waste time preaching to the choir; the audience of such a conference already knows that Software Freedom is so important. And on the other hand, there very much is a need to grow the worldwide base of people contributing to Open Source. That doesn’t mean that the cause is won, but we need less people talking, and more people doing.

Thus it is admirable that in the case of India’s premier Linux, Open Source, and Free Software conference,, this year the team have chosen to refine and refocus their event to focus on encouraging contribution and facilitating development.

I think this is terrific.

Unsurprisingly, there was a bit of resistance from the usual suspects. But in reply to one such message, Atul Chitnis (my favourite Open Source rock star and the lead matador at replied with this:

We have to pick our battles, or we lose the war. The focus of this conference is development and contribution, not newbie orientation. And even if were to allow this, the rest of the conference would be a complete loss to them.

If someone comes to FOSS.IN, it is expected that s/he knows what s/he is coming for. There are four months to the event — plenty of time to attend LUG meets, surf the net, and learn the basics.

“Do your homework”.

The guy is a guru.

Longer talks, no tracks, and project days

Considerably at odds with the general trends in most conferences, they have chosen this year to considerably lengthen the talk slots, recognizing full well that there will be less speakers but allowing those presentations to evolve into large scale workshops — the goal being helping people get bootstrapped not with using Free Software, but creating it.

This will all be balanced by “project days”, modelled somewhat on the mini-confs that originated. The idea is to give individual communities an organized forum to concentrate on the doing. I’ll be at the GNOME one!

Conference Promotion

And once again, this team absolutely leads the pack. So much attitude:

banner ad with attitude

Awesome!, Bangalore. If you’re going to be in India this coming December, you need to be there.


Learning Linux?

I was amazed and indeed almost disappointed at the number of people that have approached me this week and asked “how to get started in Linux?”. I’m embarrassed to admit that I didn’t actually have a ready answer. Conference wise I tend to hang around with people who long ago found their way [to Unix and from there] to Linux, and so had not given a lot of thought to answering the baseline question of where to start!

Luckily I had another keynote to give on the next day of the conference, so I had time to get my shit together. I prempted the beginning of my second presentation to try and address the question. I told them this:

  1. Read a book about Linux
  2. Install Linux on your computer
  3. Talk to people, and ask for help
  4. Not necessarily in that order

Install Linux

I drew up a graphic to give an overview of the lay of the land distro-wise, throwing in a few other flavours of Unix as well:

A chart plotting the ease of installation of various Linux distros vs ease of upgrading them

[The trend line shown there is something that occurred to me a while ago. It seems for a long time there was a clear inverse relationship between how easy something is to install versus how easy it is to maintain and upgrade over time. Ubuntu, of course, breaks the mould by making Debian easy to install, but it still isn't as easy to maintain (from the standpoint of a power user) as a Gentoo system is. This graphic actually worked quite well as a backdrop to discussing the emergence of distros over time and the evolution of network aware dependency based packaging systems]

Read a book about it

And suggested a book for them to look up. The best one I could think of was Matthias Kalle Dalheimer and Matt Welsh’s Running Linux, now 5th edition, published by O’Reilly [one thing that's great about Bangalore is that there are like seventeen million bookstores all full to the brim with O'Reilly books].

Running Linux book cover

To the blogoverse I ask: what book would you recommend to someone to a young university student who has caught the fire of enthusiasm and wants to get started in open source?


Convincing students

I have a somewhat unusual challenge ahead of me next week: I have to convince a conference full of students that they should participate in and pursue open source. This will strike many readers as somewhat strange since an enormous number of the people contributing to the global free software phenomenon today are students. But from my many trips to India over the last few years I have come to understand that the university system there does not promote the sort of individual initiative that involvement in open source requires — but there are people trying to do something about it.

One such is the Linux User Group at the MS Ramaiah Institute of Technology in Bangalore, India. They run an annual conference about open source, called “Mukthi“. This is a fascinating group of people. For one thing, they run their own in-house Linux conference! For another, they manage to convince the entire computing faculty to cancel classes that week so that students can attend the conference. This is exceedingly cool.

I’ve been invited to open this year’s conference. This will be great fun; there are few things I like more than standing in front of a crowd encouraging them to go wild about open source.

But that in and of itself is not exactly a topic, of course. One of the things I try to do with speaking engagements is to get a sense from the organization of what sort of impression they want me to leave. “Is there a message you want conveyed to the audience? A tone that you want me to set for the rest of the event?” That sort of thing. (I will, of course, do whatever it is I want anyway, but it’s always nice to at least try to make your hosts happy)

This one will not be easy, though. When I talked back and forth with the organizers about what they wanted to hear, they said that what it really boiled down to was that they were all exasperated about one thing: “We’ve always got people telling is how great open source is. But what good is it, really?” That made us laugh, so, I turned that around and made trying to answer that the title of my talk.

Considering the role of students in the future of Open Source

An audience of really talented young computer scientists and engineers, all about to enter the workforce: tough crowd. The conventional proprietary path is well trodden and a safe bet in most local IT industries. But it is a global marketplace and the traditional route is about getting work out of you, not about empowering you to succeed. The key to their professional future will be their ability to succeed as individuals in the global economy. The magic of the open continuum is that it changes the game: the only barrier to entry is contribution, and for those willing to risk it, there is the chance to really make a difference, and in so doing not only do they lift themselves up, but too their companies, their communities and their nation.


Pair Sliding

Davyd Madeley and I gave a tutorial at this year about the basics of writing GTK and GNOME applications. That’s hardly an original topic, but we set out to do it working in three different programming languages simultaneously, and that made it really rad, of course!

A tutorial about writing GTK and GNOME programs from C, Java, or Python - take your pick

(Click through if you care to see the abstract for the talk)

So the obvious thesis for the tutorial was that it really doesn’t matter that much what language you choose to writing a GTK program in; in other words, pick something that you’re comfortable in and concentrate on getting your app built, but on the other hand once you’ve learned GTK, that knowledge will be pretty portable to other languages should you care to stretch a little and switch.

Of course, we had to figure out how to convey that message. The obvious thing would be to just do the same program three times, once in each language, but we figured that would be pretty boring and repetitive. So instead we decided to do one application, but start it in C, continue it in Java, and then complete it in Python. Whoa!

One thing that was cool (and really, the reason that I’m blogging), was how Davyd and I ended up preparing the slides. We’d been batting around these ideas for a while, but knew we’d need a day together to bang out the slides. So Davyd flew in to Sydney a bit early and we spent an afternoon doing what was, to all intents and purposes, pair programming. Only it was writing slides and doing images. So it was like, pair sliding. I’m a big believer in agile programming practices, but I’m always amazed when I see it work in a not-coding context. It was an awesome experience: we were doing images in Inkscape, one person driving, the other catching things and offering ideas and advice. The flow was unreal. For either one of us to do that one-at-a-time remotely would have taken forever and not come anywhere close to the same quality. Same with the presentation slides. The deck slid back and forth a bunch of times as someone would say, “nah, more like this” while the other person said “ok, sure, but try that“. Amazing.

Anyway, as it turned out, our tutorial ended up being less about language and a lot more about tying the essence of “graphical user interface programming the GTK way” together. We covered the basic concepts in C, and along the way fairly clearly pointed out that that much boiler plate coding by hand in C is kinda a pain in the ass because we were writing code, live, right there in front of people. Conventional wisdom about giving presentations would have it that that’s a pretty risqué thing to do, but it was a lot of fun and, I think, helped keep the pace of new material sane. With the foundation ideas covered, showing how they were implemented in (say) Java was not a big conceptual jump. Once we’d made the switch, we returned to discussing more GTK-isms, further driving home the point that language choice really isn’t the big question. Along the way I got to do some of that magic “java-gnome code madly appearing out of thin air in Eclipse” thing, which is always pretty impressive to see.

People seemed pretty happy with our presentation, and we’ve already have a few requests to give the tutorial again at other events, which definitely makes you feel good about yourself. Oh, for those who were there, slides are now up, as is the source code from the demo.

And to my partner-in-crime on this one: Davyd, thanks for your hard work!


First live demonstration of the new java-gnome bindings

I’m giving my second talk at this afternoon, Sunday, at 14:00 local. This time it’s a technical one:

Opening GTK to Java programmers: the past, present, and future of the java-gnome bindings project

(Click through if you care to see the abstract for the talk)

I’ve been working like mad for about 6 months to completely re-engineer the design of the java-gnome language bindings to GTK and GNOME. Memory management, proxying GObjects into Java, figuring out how to handle more generic GValues in property setting. But most importantly, how to create an architecture where we could generate the bulk of the bindings off of .defs metadata so we can share that with the pyGTK guys and make our bindings a comprehensive representation of GTK and GNOME without being the totally borked, hand written, leaky, and completely unmaintainable mess that the present java-gnome 2.x bindings are.

Along the way I’ve been validating the design with code not just code mock ups but a fully working prototype. The most challenging technical piece of late has been designing an new signal handling API. Not only was the API design tough, but the plumbing to make it work is completely voodoo — the GSignal marshaling APIs are not trivial. Couldn’t have got anywhere without the old 2.x code to use for inspiration, but man oh man it’s been a hard slog.

On Wednesday at 01:48, I finished the last piece of engineering to enable signal connection to work! And so, today, as I’m talking about architecture and working across boundaries between projects, I’m going to be unveiling the prototype and giving the new java-gnome 4.0 code its first live demonstration.

This is only the beginning. There’s a lot of work yet to come, and I am hopeful that we’ll get the funding we need to make it a reality. Java Libre!

I was talking about all this yesterday over coffee with one of my good friends Sirtaj Singh Kang, who happens to be one of the original KDE developers. After the whole discussion he said “did you know I wrote the old KDE Java bindings? They’re really rickety, and I want to redo them. Do you think I could use this too?”

Wow! Wouldn’t that be something?

Don’t worry. Cats and dogs are not sleeping together: I gather there is already some new Qt Java code floating around, so presumably whoever did that will be extending it to KDE, but no matter. The architecture I’ve developed seems really promising for the task of proxying any underlying native library which more or less follows OO idioms. So as I’m working, I’m keeping in mind that more than just GLib based systems might someday want to use it. Obviously, though, our new code is going to be optimized for the GNOME + GTK case, which is as it should be.


Keynote Abstract

I’m giving a talk at tomorrow, Friday, at 6pm:

Presentation titled On the Cutting Edge

I realize that this is only of interest to people in Bangalore this week and reading, but here’s my abstract:

There is a fundamental structural problem in the open source movement. Within a given project, things generally find a way to get done, but when a problem lies between two projects (be they peers, one dependent on the other, whatever) then things often remain unresolved…. This is actually the cutting edge area in the free software movement at the moment – trying to find a common ground for not just projects but constellations of projects and above them distros to collaborate.

Whilst contribution is the barrier to entry (ie, my talk last year), there is a bigger issue: the overall continued viability and success of the open source movement. And that will take us finding ways to cross the bridges between projects.

The question has a number of aspects. Although any problem involving humans interacting is ultimately a social one, we are nevertheless face a situation where our tools are holding us back. But don’t worry: in the grand tradition of free software gurus, I shall not let so-called “reality” get in my way as I describe the future Utopia that awaits us.

Why there are there 80,000 unfinished one man show projects on SourceForge? The “not-invented-here” syndrome means that so many of us keep re-inventing the wheel; and that’s so often because we think its easier for us to start work on something new than to contribute to an existing project. We all know there are lots of reasons for this, but a big part of the truth is that contributing is hard. That’s what we have to change.

So this talk will look at what getting in the way of projects co-operating with each other, and take a wild romp through the amazing and vibrant activity taking place in the area of tools to support us. The present state of affairs is not encouraging: there is a proliferation of incompatible project hosting and bug tracking systems. Inefficient communications mediums that help us to rant at each other but don’t help us to reach decisions. The contentious struggle to develop a next generation source revision control system rages on. Even the hallowed release cycle of GNOME is up for examination: is it developing quality software or preventing people from easily contributing?

The times, they are a changing, however. Of particular interest is the version control debate. Working closely with the proponents of a number of the latest entries in distributed version control land, I’m going to talk about why this has been such a ripe area of activity, but focus on something that one of the bzr developers just noted to me: “We spend so much time chasing the Distributed Version Control System grail because that’s what everyone thinks we should be doing – but it’s not clear whether that’s actually the problem that needs addressing: when someone approaches me and says ‘but I just want to share my branch’ are we really helping them?”

Source code is just part of the equation; another huge factor is getting that code to build. The solution here has long been automake + configure + Make + libtool but the they way they approach the problem has long been primitive. There has been some dramatically new developments lately in this area focused on helping code from different projects work together. It’s going to take all of us to get it to succeed, but if we can cross the divide, then we will have made a major step towards working together.

Last year I said the barrier to entry is contribution. This year we are going to talk about the criterion for success: ensuring that the barrier to other people contributing to your project is low. If we can remove the impediments to collaboration then together we can really make free and open source software the road that into the future. Apotheosis rising.

I hope you can make it!