FOSDEM 2014

2014-02-03 14:53
By now FOSDEM turned into some kind of tradition in our family: Since 2007 every year in February we are travelling to that one comfy B&B in Brussels for a weekend - not to take a closer look at the city but to attend (together with thousands of other geeks and open source hackers) one of the biggest conferences on all things open source.

I love the conference concept for scaling: As it happens on a university campus they only have a limited number of huge rooms, but a fairly large number of mid-sized and small rooms. They use the venue to their advantage: Only the main tracks are organised by the official conference organisers. All other rooms are each filled with a community (usually a handful of people doing the heavy lifting of inviting speakers, putting a cfp out etc.) provided track. As a result even though they attract well over 5000 attendees it's only the most popular topics (e.g. Elasticsearch, GPL license discussions, configuration management, JDK specifics, kdbus, discussions on the relevancy of distribution packaging) tend to fill rooms completely.

When stuck with full rooms there's always some other talk on that probably is similarly interesting. In addition there is a huge exhibition area to visit where you can talk to the core developers behind the individual open source projects (and buy stuff like T-Shirts, grab a few flyers, stickers etc.). In addition there's so many people to talk to you usually won't get to see too many presentations anyway. In addition as of this year the crazy people of the FOSDEM (formerly Debian-only) video team managed to get (on a best effort, "hopefully the technician doesn't sleep in after that many beers yesterday" basis) all 445 talks video-taped with the goal of putting these online Monday after the conference.

On top I had the huge advantage of being able to simply follow to the talks my husband would go to if all of the stuff I am interested in is full: That would give me insight to completely different topics but also make it extremely easy for me to identify the good speakers and interesting presentations based on his experience avoiding the "if I'm unfamiliar with the topic and area I usually bump into the boring, badly given talks" problem.

I spent most of Saturday in a few talks on software patents, Daniel Naber's Language Tool, the Jolla BoF, the FLA. The rest of the time I caught up with the FSFE (thanks again for the bringing the onesies!), Debian, Open Office, Lucene and Elasticsearch people. The day ended at the Jolla community dinner - with a waitress that was completely overwhelmed by the number of geeks wanting food, beer and soft drinks.

Sunday I started with Chris Kühl's talk on Memory Tuning Android for Low Memory Devices. After that I helped at the Elasticsearch booth - FOSDEM definitely is an incredibly busy event. But given their target audience also is an interesting mix of people to talk to: Some had no idea about how text search works but came over because they had heard about Wikipedia using the project for search and wanted to know more. Some had a very clear idea of how they could benefit from Lucene for their NLP projects and wanted to know more on how that fits with Elasticsearch. Others were switching from Solr Cloud and needed some advise on how the systems compare for their particular use case. Others again were using Elasticsearch to analyse log files in a distributed fashion and needed advise on how to implement some feature. There was this one guy from Debian I've known ever since helping at the FSFE booth at Chemnitzer Linuxtage back in 2008 I believe who wanted to know more about Elasticsearch because one of his fellow package maintainers had been volunteered to work on the Elasticsearch RFP (#660826 if you are interested in reading more).

Overall (as every year) a really pleasant experience. What was in particular interesting this year was to meet people I knew only from completely other contexts (CCC events, system administrators, core Apache httpd people). Seems like FOSDEM is not only growing bigger but also more diverse.

The only kind of feedback I would provide is to split some dev rooms by finer grained topics to parallelise and scale even better (the Java, NoSQL and configuration management ones come to my mind first but there probably are others as well - of course again this depends on room availability and actual community members volunteering to submit a dev room related to their project in particular).

I'm glad I'm travelling home by train like last year - not only does that give me time to code and write the blog post you are reading just now, it's also comfortable to get rid of the usual sleep deprivation :)

On being aggressively public

2014-02-01 19:06
If it didn't happen on the mailing list it didn't happen at all.
... with all it's implications this seems to be the hardest lesson for newcomers to the Apache way of development to learn.

In the minimal sense it means that any decision a project takes has to be taken publicly, preferably in some archived, searchable medium. In a wider sense it's usually interpreted as:

  • ... don't ask people getting started questions privately by mail, rather go to the user mailing list.
  • ... don't coordinate and take decisions in video conferences, rather take the final decision on the dev mailing list.
  • ... don't ask people privately on IM, rather go to the user mailing list.


There are even canned answers that can get sent out to those asking privately.

This concept seems to be very hard to grasp for people: As a student, developers tend to be afraid to ask "stupid questions" - it's easy to say that "there are no stupid questions, only stupid answers" - truly feeling this to be true can be hard though in particular for people who are just beginning.

However (assuming the question hasn't been answered before or the answer wasn't easy to find with a search engine of your choice) asking these questions is a valuable contribution: Chances are, there are a couple other people who would have the same question - and are too shy to ask. Chances are even bigger that those developing the project would never think of documenting the answer anywhere simply because they do not see it as a question due to their background and knowledge.

For researchers in particular on their way to getting a PhD. the problem usually is the habit of publishing facts only after they are checked, cleaned and well presentable. When it comes to developing software what this approach boils down to developing a huge amount of code hidden from others. The disadvantages are clear: You get no feedback on whether or not there would be simpler/faster approaches to solving parts of your problem. Developers of the upstream project won't take the needs for this extension into account when rewriting current modules or adding new code. As a result general advise is to share and discuss your ideas before even starting to code.

Even for seasoned software engineers this approach tends to be a problem when not used to it: In a corporate environment feedback on code often is perceived as humiliating. As much as we preach that a developer isn't their code so feedback on coding issues is not to be taken seriously it still takes a lot of getting used to when suddenly people give that feedback - and give it in the open for everyone to see.

Also often decisions are taken privately before communicating publicly in corporations. As a result having heated design discussions tends to feel like a major marketing problem. Instead what is achieved is making the decision process publicly visible to others so they can follow the arguments without repeating them over and over. It also means that others can chime in and help out if they are affected (after all the second mantra is that those who do the work are the ones who ultimately take the decisions).

Again another reason could be for people new to the project or new to some role in the project that asking trivial questions looks intimidating. Again - even if you've contributed to a project for years noone expects you to know anything. If any piece isn't documented in sufficient depth asking the question provides a track record for others to later refer to. It also means you tend to get your answer faster because there are more people who can answer your question. Oh - and if you don't get an answer chances are, everyone else is in the dark as well but was just not asking.

One final word: One fear many people seem to share when asking is to make their own knowledge gaps and flaws public - not only to peers but also to current or future superiors. There's three parts to the advise that I tend to give: Everyone once started small. If your potential future manager or team mates don't understand this, than learning and making mistakes obviously aren't welcome in the environment that you are aspiring to join - is it really worth joining such an environment? Even so you start small, if you continue to contribute on a regular basis the amount of information that you produce online will grow. Guess how much time people spend on evaluating CVs - it's very unlikely they will read and follow each discussion that you contributed to. And as a third point - do assume that by default everything you do online will be visible and searchable forever. However chances are that ten or fifteen years from now what you are writing today will no longer be accessible: Services go away, projects and their infrastructure die, discussion media change - anyone still remember using NNTP on a regular basis?

As an exercise to the reader: Before writing this post I spend a couple of hours trying to dig up the mails I had sent I believe in 2000 to the I think KURT and RTLinux discussion lists in order to prepare some presentation about the state of realtime Linux back at university. I search the web, search the archives I could find, searched my own backups from back then - but couldn't find anything. If you do find some trace of that, I owe you a beer next time we meet at FOSDEM ;)

Don't dream it, be it

2013-12-24 12:07
After two years in a row of receiving 120 submissions for Berlin Buzzwords from the usual crowd - young, white, male, caucasian - only this year we decided we needed to work towards increasing diversity.One piece in the puzzle was to get in touch with several Berlin local "tech for non-tech" people groups. In a content exchange kind of setting I was asked to do an interview as some kind of role model.

In addition to a serious lack of time back then I felt the typical way these interviews go would do no good - even anyone who's in IT already learning I co-founded Apache Mahout, am a member of the Apache Software foundation, have co-founded Berlin Buzzwords (after running quite a few successful meetups around related topics in Berlin), am married to a Linux kernel developer tends to shy away (unless the person I'm talking to happens to be into OSS development themselves thus knowing that despite quite some work this also means having lots of fun).

However the invitation did get me started thinking about what kind of advise I would share with the next generation of hackers. Over time though I realised that what was most helpful for me doesn't only apply to those who want to become successful in IT. On first sight it sounds like an extremely easy to follow advise:



Once upon a time after coming back from the Kindergarden provided by my mom's employer I spent part of an afternoon in front of a computer in an office close the hers. The game was trivial: Direct a little Snake through a maze, collect items, avoid biting yourself or the walls.

Years in primary school I got to play with the computer of one of my relatives. Ever since beating their highscore I wanted a computer for myself. When I finally got a first computer on my own I used to play lots of games together with a good friend of mine - until the game supply for my Amiga 500 dried out. Back then I made a decision: To work towards simply coding my own games. Ever since I followed this tiny little dream - by now for almost twenty years.

Even despite the fact I got all support I could wish for from parents, teachers and university professors seen from the outside it may have seemed like not always being easy as pie: More often than not it meant being different - instead of being part of the "I don't know what I want to do after school" it meant being part of that small group of people who know what they are working for. Instead of being part of that large "I hate technology and I'm utterly bad at math" it meant being part of that tiny group of people who love math and who have fun dealing with any new technology.

Instead of being at one of those great parties for New Year's Eve it meant filling in the details of a project proposal a few hours before midnight. Instead of being home at 6p.m. it meant going to meetups more often than not. Instead of being home during weekends it meant flying to California for a conference on a weekend on my private budget. Despite getting 2.5 days a week from March to June to work on Berlin Buzzwords from my employer for the first two years and having lots of help and knowledge over at newthinking who did the heavy lifting of taking on the financial risk, managing registrations, booking the venue and handling speaker travel support it still meant lots of additional mornings, evenings and weekends spent on making the event fly (and an inbox that never went silent - neither at noon nor at midnight - hint: any mail you send to info@berlinbuzzwords ends up not only in an anonymous mailing list - every organiser including Simon Willnauer, Daniela Bentrup and myself will receive your mail and make sure it gets dealt with).

There are a couple of reasons I kept doing this kind of stuff. But I guess the most influential reason is simply that it also is a whole lot of fun for me.

There were several fellow students at school who didn't have the courage to follow their dreams from the very start: There's the girl who was teased into studying biology by her parents - only years later she had the courage to go for professional gardening. There's this guy who didn't know exactly what to do and followed many of his friends to study mechanical engineering. Months later he pivoted towards social sciences and politics, today working on a PhD. thesis on economics in German hospitals. There's the girl who successfully passed her math degree but really also wanted to follow her musical passion - in the end she went to study music in addition to become a math and music teacher.

It takes determination and courage to follow your dreams - especially if that means following a different path than what your parents had on their mind for you or following a path that doesn't quite fit into the cliché of what society has in mind for you*. However in my statistically absolutely non-significant, completely biased and personal opinion it's worth every effort.

* Sorry for as long as it is special to love repairing cars for a girl and to love working in child day care for a boy I don't believe in society not influencing career decisions.

AFERO GPL Panel discussion - FOSDEM 04

2013-02-16 20:41
The panel started with a bit of history of the AGPL: Born in the age of growing ASP (application service provider) businesses AGPL tried to fix the hosting loop whole in GPL in the early 2000s. More than ten years later it turns out the license hasn't quite caught traction: On the one hand the license does have a few wording issues. In addition it is still rather young and used by few so there is less trust compared to GPL or ASL to last when put on trial. However there's another reason for low adoption:

Those that are being targeted with the license – people developing web services – tend to prefer permissive licenses over copyleft ones (see Django, Rails for example). People are still in the postion of trying to gain strong positions when opening up their infrastructure. As a result there is a general preference for permissive licenses. Also there are many more people working on open source not as their hobby project but as their general day job. As a result the number of people backing projects that are infrastructure only, company driven and trying to establish de-facto standards through the availability of free software is growing.

Depressing for the founders of AGPL are businesses using the AGPL to try and trick corporations into using their software as open source and later go after them with additional clauses in their terms and conditions to enforce subscription based services.

Mozilla legal issues - FOSDEM 03

2013-02-15 22:39
In the next talk Gervase Markham talked about his experience working for Mozilla on legal and license questions. First the speaker summarized what kind of requests he gets most:

  • There are lots of technical support requests.
  • Next on the top list is the question for whether or not shipping Mozilla with a set of modifications is ok.
  • Next is an internal question, namely: Can I use this code?
  • Related to that is the “We have a release in two weeks, can we ship with this code?”
  • Another task is finding code that was used but is not ok.
  • Yet another one is getting code licensed or re-licensed.
  • Maintaining the about:license page is another task.
  • Dealing with ECCV/CCATS requests is another issue that comes up often.


However there are also bigger tasks: There was the goal of tri-licensing Mozilla. The only issue was the fact that they had accumulated enough individually copyrighted contributions to make that that task really tricky. In the end they wrote a tool to pull out all contributor names, send them mails asking for permission to tri-license. After little over three years they had responses from all but 30 contributors. As a result the “find this hacker” campaign was launched on /. and other news sites. In the end most could be found.

As another step towards easier licensing the MPL 2 replacing 1.1 was introduced – it fixes GPL/ASL license incompatibilities, notification and distribution requirements, the difference for initial developers and the use of conditional/Jacobson language.

There are still a few issues with source files lacking license headers (general advise that never has been tested in court is the concept of license bleeding: If there are files with and without license headers in one folder, most likely those w/o have the same license as those with. “aehem” ;)

There are lots of questions on license interpretation. This includes questions from people wanting to use Mozilla licensed software that wasn't even developed within the Mozilla foundation. Also there are lots of people who do not understand the concept of “free does not mean non-commercial use only”.

Sometimes there a license archeology task where people ask “hey, is that old code yours and is it under the Mozilla license?”

Another interesting case was a big, completely unknown blue company asking whether the hunspell module, having changed licenses so often (from BSD forked to GPL, changed to LGPL, to CC-Attr, to the tri license of Mozilla, including changed GPL stuff with the author's permission) really can be distributed by Mozilla under the MPL. After lots of digging through commit logs and change logs they could indeed verify that the code is completely clean.

Then there was the case of Firefox OS which was a fast development effort, involving copying lots of stuff from all over the internet just to get things running. A custom license scanner written to verify all bits and pieces was finally implemented and used to give clearance on release. It found dozens of distinct versions of the Mozilla and BSD licenses (mainly due to the fact that people are invited to add their own name to it when releaseing code). As a result there now is a discussion on OSI to discourage that behaviour to keep the number of individual license files to ship with the software down to a minimal number.

The speaker's general recommendation on releasing small software projects under a non-copyleft license was to use the CC-0 license, for larger stuff his recommendation was to go for the ASL due to its patent grant clauses. Even at Mozilla quite a few projects have switched over to Apache.
There also were a few license puzzlers:

  • OpenJDK asked for permission to use their root-store certificates. Unfortunately at the time of receiving them they had not been given any sort of contract under which they may use them. *ahem*
  • The case with search engine icons … really isn't … so much different.


There also tend to be some questions on the Firefox/Mozilla trademarks ranging from

  • “can I use your logo for purpose such'n'such”?
  • ”Do you have 'best viewed in...' button”? - Nope, as we generally appreciate developers writing web sites that comply with web standards instead of optimizing for one single browser only.
  • They did run into the subscription on download scam trap and could stop those sites due to trademark infringement.
  • Most of this falls under fair use – especially cases like Pearson asking for permission (with a two-page mail + pdf letter) to link to the mozilla web site...


In general when people ask for permission if they do not need to ask: Tell them so but give them permission anyway. This is in order to avoid an “always-ask-for-permission” culture, and really to keep the number of requests down to those that are really necessary. One thing that does need prior permission though is shipping Firefox with a bunch of plugins pre-installed as a complete package.

On Patents – Mozilla does not really have any and spends time (e.g. on OPUS) avoiding them. On a related note there sometimes even are IPO requests.

Trademarks and OSS - FOSDEM 02

2013-02-14 20:38
So the first talk I went to ended up being in the legal dev room on trademarks in open source projects. The speaker had a background mainly in US American trademark law and quite some background when it comes to open source licenses.

To start Pamela first showed a graphic detailing the various types of trademarks: In the pool of generic names there is a large group of trademarks that are in use but not registered. The amount of registered trademarks actually is rather small. The main goal of trademarks is to avoid confusing costumers. This is best seen when thinking about scammers trying to trick users into downloading users pre-build and packaged software from third party servers demanding a credit card number that is later charged based on a subscription service the user signed by clicking away the fine print on the download page. Canonical example seems to be e.g. the Firefox/Mozilla project that was effected by this kind of scam. But also other end-user software (think Libre/Open Office, Gimp) could well be targets. This kind of deceiving web pages usually can be taken down way faster with a cease and desist letter due to trademark infringement rather than due to the fraud they do.

So when selecting trademarks – what should a project look out for? One is the name should not be too generic as that would lead to a name that is not enforceable. It should not be too theme-y as the names that are themed usually are already taken. The time to research should be contrasted with the pain it will cost to rename the project in case of any difficulties.

There are few actual court decisions that relate to trademarks and OSS: In Germany it was decided that forking the ENIGMA project and putting it on set-op boxes but keeping the name was ok for as long as the core function would be kept and third party plugins would still work.

In the US there was a decision that keeping the name of re-furbished SparkPlugs is ok for as long as it is clearly marked what to expect when buying them (in this case re-furbished instead of newly made).

Another thing to keep in mind are trademarks are naked trademarks – those that were not enforced and have become too ubiquitous. In the US that would be the naked license trademarks, in Greece the recycling mark “Der Grüne Punkt” has become too ubiquitous to be treated as a trademark any more.

Trademark law already fails in multinational corporation setups with world wide subsidies. It gets even worse with world wide distributed open source projects. The question of who owns the mark, who is allowed to enforce it, who exercises control gets worse the more development is distributed. When new people take over trademarks there should be some clear paper transferral document to avoid confusion.

Trademarks only deal with avoiding usage confusion: Using the mark when talking about it is completely fine. Phrases like “I'm $mark compatible”, “I'm running on top of $mark” care completely ok. However make sure to use as little as possible – there is no right to also just use the logos, icons or design forms of the project you are talking about – unless you are talking about said logo of course.

So to conclude: respect referential use, you can't exercise full control but should avoid exercising too little control.

There is a missing consistent understanding of and behaviour towards trademarks in the open source community. Now is the time to shape the law according to what open source developers think they need.