Last week-end I attended FOSDEM for the 7th time. It's kinda strange to say and think - if someone tells me they've been going to this or that open-source conference for 7 years I tend to assume they're hardcore and totally know what they're doing. I go to hang out with cool folks and learn new things. This year's FOSDEM didn't disappoint in that regard!

As usual, the conference was packed and most rooms filled up quickly, but I was happily surprised to see it was still possible to squeeze in some of the more popular rooms regardless. I think many devrooms organisers are well aware of the frustration with not being able to get in and they did a great job at encouraging/demanding folks use all seats rather than leave spaces in the middle, which really helped (special kudos to the Legal devroom, which was in a smaller room in H). Also the main conference organisers appear quite good at trying to adjust the room size based on popularity year to year (e.g. the Mozilla room used to be utterly impossible to get into).

Some of the conference highlights from my perspective:

Identity Crisis: Are we who we say we are?

This was the first keynote on Saturday morning, which I think did a good job of bringing up many possible ambiguities hidden in the "we" we use when contributing to a project. One of the strengths of open-source is that we're quick to say "we" and include everyone, but sometimes it bears more thinking or clarification of who we actually mean with "we" - sometimes two "we" can describe different subgroups of contributors even in the same sentence. Taking the time to think explicitly about who we mean, and avoid unintended conflicts of interests is important.


Fog of War - The GNOME Trademark Battle

The story of what was happening in the background during the Gnome battle for their trademark with Groupon last year, told by a Gnome board member and the lawyer that helped them on the case. Interesting insights thanks to the lawyer's perspective particularly, who also took a guess at what possibly happened in the Groupon lawyers' mind during their risk analysis and the consequences (e.g. "Groupon was dealing with an animal they'd never seen before." A charitable org not willing to be silenced or take a big donation.) Not a kind reflection on Groupon.


Why Samba moved to GPLv3: Why we moved, what we gained, what we lost.

Emboldened by having managed to get a seat in the Legal devroom, I decided to also stick around for the next talk. I hadn't attended a talk on GPLv3 in a few years and I wasn't to be disappointed. It was a very honest and funny talk - I knew of Jeremy Allison aka the Samba guy, but I didn't know he was such an entertaining speaker. Overall Samba seems very happy with the move to GPLv3, it simplified a lot of things for them especially in terms of copyright managenent (some companies are just nasty), and most of the contributors and users they initially lost ended up returning (multiple closed-source vendors being bought out and leaving their customers in the cold likely helped). They felt really let down that the FSF didn't force their own projects to move as well (though I understand that is not the case anymore) and of course the Linux kernel being GPLv2-only is hurtful too. The speaker is convinced that all the scary stuff around GPLv3 is FUD and everyone should switch to using GPLv3+ right now if they don't have to link to v2 stuff. An audience member did raise an issue/unclear point with the v3 licence, for when a company rents a device to a customer (that the user doesn't actually own and thus perhaps? shouldn't be allowed to modify).


Participation metrics at Mozilla: A story of systems and data

For projects that depend so heavily on volunteer contributions as Mozilla does, understanding who the community is made of and where/when people are being lost or leave is really important. The speaker started by showing us some of the ways they tried and failed to measure participation and what they ended up with. They defined what "participation" means by formalising paths a contributor might take across their systems (e.g. file a bug, comment on a bug, translate a string, etc) and they extract and map the data they have to these paths. This enables them to also deduplicate contributor information: for instance it's not because you have 100 translators and 300 developers that you have 400 contributors, people can do more than one thing, and it also lets them identify more clearly whether someone is leaving the project altogether or simply moving to another area. Very interesting stuff!

This is work in progress but their current results and reports are available at Are we a million yet.


Maintaining & growing a technical community: Mozilla Developer Network

The other Mozilla talk I attended explored the meaning of community and the motivations behind why people start contributing, why they continue to contribute and how to help folks feel involved and want to contribute. The speaker made some really good points, one that really stuck with me being that contributors ≠ community. It's really important to connect contributors to your community or they will not stick around! The example she used was getting people to contribute at hackathons-like events, but then disappear - as someone who's run such events that certainly rang true, simply showing folks they can make a positive impact easily is not enough to make them come back or feel part of the community.


Retooling Fedora: A Retrospective on Fedora 21 (and looking to 22)

I knew Fedora had been changing their model since the past release but I hadn't been following closely. This clarified the goals and the why, and I was very impressed with the beginning of the talk where the speaker (Matthew Miller, the current Fedora Project Leader) took a really hard look at where distributions are today and why they appear to be becoming less relevant - for instance looking at the contrast between the number of open-source projects available on platforms like Github compared to what is actually packaged in the distro. People used to care about getting their software into the major distributions but it doesn't seem to matter as much nowadays. In that light the "ring" graph showed toward the end, explaining that perhaps the apps at the outer layer don't need as strict and stringent criterias for inclusion than the more core OS components, totally makes sense and the future looks interesting.



I continue to be hugely impressed by how much Mozilla cares about improving the experience for new and existing contributors (impressed but not surprised! Their "Get Involved" page remains excellent, letting you get in touch with real people while showing at one glance all the different ways you can help, and having a mentored bugs process for new contributors is an awesome step-up from simply tagging easy bugs. Keep rocking and showing us all how it's done Mozilla!)

Videos of the talks should be available in time on the FOSDEM website.

Leave a comment

FOSDEM 2010: Gnome talks Bug triaging, Plugin framework, A new kind of IDE

There were quite a few talks about Gnome, I'm going to highlight here 3 of them.

Gnome foot

Gnome Bugsquad

The first talk was about bug triaging in Gnome. I can't believe there are only 5 active bug triagers in the project (as in, people fully focused on cleaning up the bug database). Tobias Mueller, the happy and dynamic speaker, made a good job explaining why this is such an important task, as the bug tracker is basically a window to the world. This is what people will be confronted with when they try to interact with the project, and having unanswered bugs lingering around doesn't give a very good impression.

In itself, bug triaging is a great entry point into the project because it doesn't require in-depth knowledge and it brings you closer to the community as you get to know the developers by name, so it's a good way to get involved, learn more about Gnome and help out.

The way triaging work:

  • There are bugs. People find them and complain about them in the bug tracker.
  • We need to understand and get all the necessary information for the developer to be able to fix it.
  • So the status of the bug needs to be kept accurate (more on that later)
  • And bug triagers can identify severe issues, such as bugs that come back often or many times so we can inform the adequate people.

I love that quote: "Bug triaging is about making people happy." We want our users to be happy, Gnome is about the people in the end!

Some other happy mottos:

"Be nice, be friendly, be happy."

"Answer early, answer often."

There are several ways to get in touch, through IRC, the mailing list, they're trying to hold bug days but currently lack the manpower to do so. They have a triage guide that is apparently so awesome even the KDE guys use it! :D Here's a link, I have to carve out time to read it.

After showing us some tools to find duplicate bugs and what sort of information to ask for, Toby walked us through the different statuses and how to use them, like what to do if you can't get information from the bug reporter after 6 weeks (the assumption is that this is not a problem anymore so resolve the bug), or if you're triaging a bug from more than 2 releases ago (resolve it as obsolete). Some statuses are reserved for the module maintainers. It's all summarised in a shiny diagram available on the wiki. When you start out you actually can't modify the status yourself, so you should add a comment explaining why you think the status should be updated and someone with the Power on #bugs will change it for you. Quickly enough, once you've shown you understand how this works, you can ask for the ability to change statuses yourself.

The final statement was that they need people and it's a good way to start if you want to get involved, it's not too hard for beginners and it doesn't cost too much time or requires that much knowledge. And you get to know the people and projects.

To get started:

  1. Create a Bugzilla account,
  2. Read the wiki,
  3. Ask questions on IRC,
  4. Get started. You can't do anything yet, so write it in the comments,
  5. If it all makes sense ask for access to do it yourself.

At the end, he asked who he convinced, I think he should have asked who would consider contributing to bug triaging, that's less commitment while still showing interest :) I joined the ML while he was speaking but I didn't raise my hand when he asked, because my way of doing things is to lurk for a while and then see if/how I can fit something in my schedule, rather than making promises I will break. We'll see how that one goes! I'd love to get more involved with Gnome.

Adding plugins to your Gnome apps

Steve Frécinaux talked to us about libpeas, a framework being developed to make plugin development within Gnome applications easier and more consistent across applications.

Plate of peas

Building a plug-in API is very, very hard, and having dissimilar APIs makes it harder -- that is, if you write a plugin for Nautilus, you will have to relearn from scratch to build a plugin for gedit. There's a heavily duplicated code base as well, as most projects seem to have taken the gedit plugin framework as a basis, but it's all slightly different because of bug fixes and fitting their own special needs that are not transmitted upstream.

Libpeas aims to fix all this. Plugins are good because they enable the main codebase to remain simple and clean while allowing for lots of additional functionality.

The goals are:

  • Ease of use: the framework should be minimalist with little boilerplate code
  • Extensible: different applications have different needs, not every project is like gedit
  • Lightweigth: it should only load what you use, e.g. not load python if it's not needed by any plugin

Plugins can be written in C, Python, or Javascript.

A plugin is what you install, which can consist of one or more extension. An extension is the implementation of an extension point (hooks). So plugins can register extensions with several extensions points within the application.

The speaker walked us through the different principles of plugins vs extensions, and finally showed us the steps to follow to make your applicable extensible and create hooks.

I can't find a page for the project on the Gnome wiki though, which is not cool :/

Gnome Development Tools: High-Level Debugging and the Misha Research IDE

To be honest I'm not sure this was particularly Gnome-specific, although it WAS written using Gtk tools :) Nick Papoylias introduced us to a new genre of IDE, based on the premise that debugging hasn't really evolved in the past 20 years when really, there are many ways it could be used besides stepping line-by-line through a program after encountering a problem. Debuggers can be integrated to different phases of the development life cycle, and there are many ideas that academia has put forward that are slow to be adopted, if at all (reverse debugging just made it into the latest gdb for instance).

He admitted that they didn't respect every Gnome UI guideline but as they were experimenting with a new approach to IDE and programming workflow, it made sense to experiment with a different UI as well to save space. The interface felt really busy but I'm not particularly worried about that, that's how IDE tend to be by nature.

They are adding new things to rethink the debugging workflow, that work together with the symbol debugger (gdb).

  • Syntax parser: Navigate code in terms of structures, loop iteration, functions -- not only line by line
  • Data visualisation
  • General purpose extension language: Python
  • Reverse debugging

It supports stepping through the syntactic structure while having a up-to-date data visualisation. This is a very nice way to see what is happening as we run through the code, he showed an example of variable insertion in a Binary Search Tree and it was amazing to see the tree be updated for every iteration of the loop. That'd be a much faster way to catch silly little bugs that tend to creep up as you develop (so you can catch them even before writing lengthy unit tests).

The presentation ended by showing us what the extension language could do and wow. Was that impressive. You can use Python functions to call your C code, for both simple and elaborate calls. The Python code directly calls C functions with no intervention from the developer. And through the debugging console we can visualise what's going on (e.g. the tree that is created through Python).

Additionally, if you create a in your project, you can attach callbacks buttons to the IDE. This is really cool. He had it call a plotting application to display random results in a graph and check the distribution or whatever. It was really impressive.

So Python can be used to make inter-language calls, import external libraries, add functionality to the IDE, and call C programs directly. Check out the project website.

Leave a comment

FOSDEM 2010: Saturday morning keynotes Welcome to FOSDEM, Promoting open-source methods in large companies, Evil on the Internet

I barely took any pictures at FOSDEM this year, so I'm going to steal (with credit!) pictures from various Flickr streams.

Saturday morning began with the customary welcome keynote, with a little twist for the FOSDEM dance (heh!). Wireless was up and running well before 12.00, which was a nice surprise.

FOSDEM dance
(Picture credit: itkovian, Creative Commons "Attribution-Non-Commercial-Share Alike 2.0 Generic", taken from Flickr)

Promoting open-source methods in large companies

The first keynote was on promoting open-source methods in large companies. Not using slides made it quite hard to follow, that made me realise how slide stacks help with understanding the structure of a talk, what was said when there is noise around, or just remember/understand where we're at after being distracted and having zoned out for a couple of minutes... (and let's be honest that's always going to happen!)

Brooks Davis described his journey getting open-source adopted internally. It was more in the sense of having people open-source their projects within the company than anything larger, although quite a lot of open-source projects were used to achieve that (Apache, PostgreSQL, trac...) He started from quite far since he had to sell people on the concept of version control itself to begin with! (I empathise with that, it's very hard to make devs who are not familiar with it  use version control tools to their full potential. For instance I keep having to remind my team that it's ok to delete a now-unused file or big chunk of code because we can find it again if we need to. Dead files and dead code just make maintenance more painful.) The policy they set out for their internal open-source repository was that ALL projects had to be ENTIRELY open-source (can't keep any section secret.)

The barriers to adoption were mostly driven by fear:

  • Fear of misuse: People need to trust their colleagues! (This is actually an interesting point. The speaker works with space-related software so I'm guessing there's quite a lot of IP and other trade secrets in their software. I wonder how they ensure and/or convince management that no employee would sell them out to the competition. I understand how the policy is tremendously useful to avoid duplication, foster collaboration between internal projects and just make sure part of the project doesn't disappear or get lost with a single developer. It's possible the speaker talked about this and I missed it though, the keynote should have been recorded... I guess this point includes "trust your employees" as well.)
  • Misplaced sense of ownership, with people believing "this is MY code" when actually, this is the COMPANY code!
  • Credit: Although the open-source community is quite good at it, within a company people tend not to be so good at giving credit where it's due (although they are learning, according to the speaker!)
  • Another concern was that "people will like it and then they will modify it and make it better," quite a confusing complaint

The positive points of this approach and policy are that:

  • anyone can access the code in the public repository, rather than have it exist on only the one guy's laptop, that has to be hunted down when someone wants to reuse the code or needs it for another project
  • there is a snowball effect once people start using the system

Along the way a few lessons were learnt and changes were made accordingly:

  • The "everything must be open and available" policy was relaxed a bit to accommodate for NDA, work by contractors, etc. A project must submit an application to justify such security requirements, to be reviewed and approved (many teams believe their project require such mechanism when really, it doesn't)
  • Moved from mod_python to wsgi (easier to manage)
  • Performance: They bought more RAM to handle the multiple Python instances (1/project), and thanks to WSGI have the project sleep when not accessed (they still have issues with the internal search crawler though, as it means every project page gets accessed within a few seconds!)

The barriers to adoption by development teams are:

  • Team isolation, each team kinda works in its own island
  • People don't know it exists
  • People think it's a heavy-weight project involving lots of paperwork (e.g. fill 6 forms to make a change)

There was a bit of talk on distributed version control. He finds it interesting but as his people are just getting used to the concept of centralised version control it might be a bit early. There is also the issue of backing up the projects, because the distributed nature of those tools could mean that people revert to only having a copy on their own machine. He's interested to see how people in open-source deal with this, and hopefully learn from it.

They are working on a few improvements to trac that they aim to contribute back (e.g. seeing tickets for multiple projects on the one screen.)

In the end I was a bit disappointed by the talk, because it focused so much on implementation (which is cool, I love hearing about this kind of stuff but I already had this with Ship It!. I know I want it.) when I was hoping for more strategies on how to help management and developers see the benefits of open-source. I'm interested in understanding how to get it adopted internally, how to bring change. Someone in the audience actually asked kind of a similar question, asking how he got management to pressure one particular internal project to use the new tools (mentioned during the talk.) I think the answer was along the lines of if the company spends a couple of millions a year on a project or another, they're interested in seeing it reused and easily available internally. Which doesn't really help us, but I guess if he has support from management to begin with it's just difficult to answer.

Evil on the Internet

The second morning keynote was about Evil on the Internet. The poor speaker, Richard Clayton, was severely booed at the beginning when the Windows screen showed up as people struggled to get Windows to play nice with the projector, but once he started with his talk it was most excellent because presented in such a funny way. Apparently the only thing bad guys have to do all day is design very nice and sleek looking websites, while trying to screw people over every possible way. To me the highlight of the talk was the job ad for Millenium Inc., a phishing company (though it doesn't present itself as such, for obvious reasons.) Their vacancies page advertises for a lot of positions, most them "not currently available" ...except for one. They are looking for a "payment processing assistant." Your job would consist of receiving payments from their clients onto your bank account, that you then take out and send on to Millenium through Western Union. Very nice. When the bank realises the money was moved onto your account through fraud it will take it away, and you'll be left with no recourse because Western Union will never ever refund any money you send using their services. There were many other examples, and there's more on his blog.

Leave a comment

Back from FOSDEM

FOSDEM is over, and all I can say right now is that I bought way too many tee-shirts (awesome :D and still not enough!). Got most of them in girl size which is great, albeit some of the sizings were a bit messed up (I had to buy a FSF shirt in size L. Granted I did buy it on the last day, perhaps the waffles are to blame ;)). I'll post my notes on some of the sessions in the coming days, really disappointed to have missed the ending keynote by GKH on writing your first kernel patch but I was concerned about missing my plane -- turns out I shouldn't have worried. Will be watching out for the video recording of that one!

Leave a comment


  I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting
/ \

Leave a comment