I am back from Akademy and this edition was particularly interesting in my opinion. Somehow it looks like there was a common theme hidden in this conference... let's go through what I consider the most noticeable events of Akademy 2014.

Even before the official start of the conference, during the KDE e.V. general assembly we had something interesting happening. We had elections for three out of five positions in the board. During the questions to the candidates (thanks all for stepping up!), it was clear that the membership was looking for people aiming at a higher efficiency and then improved KDE e.V. organization. We will see if our new board will live up to those expectations. It sounds like a new cycle of radical improvements will start after a (needed) period of consolidation and stabilization.

Then, the first keynote by Sascha Meinrath was an excellent reminder that we should be more proactive on the political landscape. If we stay in reactive mode just producing software, we won't be able to prevent centralized infrastructure, opaque Internet of Things and the panoptic surveillance system. Only by aiming at a higher political involvement can we avoid the raise of a digital feudalism age.

After this keynote, during the three days of talks and workshops, a surprising amount of sessions were focused on quality in a form or another. I was obviously guilty there with my craftsmanship cycle but Albert too. Add to those the talks from the VDG, the workshop on profiling by Milian and the one on unit tests by Shantanu to easily figure out that there's quite a few people wishing to see our contributors aiming at higher quality.

Last but not least, Paul's talk on community metrics was likely the most important one to attend this year. If you didn't attend it: go and watch the video now! I'll wait... This talk is really a wake up call in my opinion. We lost something and we need to get it back. He pointed out a silent crisis going on in the community. We still have time to get back on the right track, but we got to find the root causes and act as soon as possible. What Paul proposes is to aim at a higher cohesion in the community again. That will require a better shared technical vision, a stronger focus on our mission toward our users and a stronger focus on getting better in our contributions.

By now it is clear that the common theme of Akademy 2014 was that we ought to generally aim higher. Overall, we are in a good position today. Unfortunately, that is also a very fragile one as the community metrics and the quality related talks highlighted.

We're likely at the crossroads now. The decisions we'll take in the coming weeks and months will lead us either to regress or to strive. In my opinion, we can only strive by improving in the areas mentioned above. In some way, that is very good news! We are mostly in control of those areas to improve. It means that success is reachable if we have enough collective willpower to do what's required to seize it.

Posted on 14 Sep 2014
Tags: KDE  Akademy  Craftsmanship  Community 

I meant to write a post about the upcoming Akademy for a while now. Since I submitted quite a few sessions (obviously requiring preparation) and I had to prepare for the KDE Frameworks BoF, I never quite found the time... until now! I'm all done! Actually I just have to pack my bags and hit the road at that point. It's probably the first Akademy where I'm ready four days before the first flight of my journey.

Anyway, Paul's post on what he plans to see inspired me to do something similar. Let's see how I'll navigate the tracks during Akademy.

Day 0: KDE e.V. General Assembly

The day before the fun begins for the community at large, the KDE e.V. membership gathers for its annual general assembly. It can be perceived as a day long boring meeting (I know some do), but it's clearly not like that. It is a very crucial event as KDE e.V. has important responsibilities in order to help the community. For instance such a body is necessary for Akademy itself to exist! It is also represented in the KDE-FreeQt foundation...

Clearly an organization not to be underestimated. This year assembly will be especially exciting as several positions are opening in the Board of Directors, which means elections... and candidates. We have quite a few this year which is a good sign of liveliness.

Day 1: Digital Feudalism, Tech and Community

Obviously I can't miss Sascha Meinrath's keynote. I had the opportunity to meet Sascha during FISL 15 earlier this year. He is probably one of the most interesting persons I met during the last couple of years! I discussed with him some of the points he'll likely touch in his keynote about Digital Feudalism. Definitely something people should attend as it is crucial for the years to come in the Free Software movement.

Then I will obviously attend the fast track session. To me we got a few which clearly stand out like GCompris transition to QtQuick, Everything Qt, A year with Akonadi and Using KF5 in commercial applications. This fast track will conclude my first morning.

The afternoon is then packed with quite a few interesting talks. Since I can't duplicate myself I won't be able to attend everything I'd like to... I urge application developers to attend Porting to KDE Frameworks 5 and Porting to QML.

That said... in the tradition of "do as I say not as I do", I'll attend something else instead... told you I had to make tough calls! I will run in the room 2 and stay there the whole afternoon.

I'll first attend War of Idioms by Ivan. The man knows his C++ standards and is definitely enthusiastic about some of the recent changes. So am I! I had the opportunity to use new idioms while working in projects with C++11 support, so I'm looking forward to learn new ones thanks to Ivan.

Then I'll attend A tale of ELFs and DWARFs by Volker. From the abstract it could sound as something very low level, maybe it is somewhat low level... but that is impacting everything we do when developing native code. Since that's what we mostly do in our community it's good for your toolbox to know linking and loading to be able to get out of troubles when needed. Definitely healthy, like eating your veggies at every meal.

After that I'll switch in community mode, looking forward to the Board of KDE e.V. session. Curious about the KDE e.V.? You know, the organization I mentioned above as crucial. Yes, that's what I thought: you should attend this session too!

Still in community mode I'll make sure to pay attention in the KDE in Asia session. I have some kind of fascination for what's going on there. We got people in those countries doing amazing things and organizing great events. We ought to learn and seek inspiration from them. That talk has quite a few lessons for us doing promo work in Europe I'm sure.

Day 2: Craftsmanship, Usability and Design

This one will be my big day... so obviously I can't attend everything I'd like again.

At least I will be listening to Cornelius' keynote. I'm curious about his take on the personal growth experience working in a community like KDE might bring. Like him, I joined for technology but stayed for the community. I also know we have different point of views on the finer details so that will be interesting to have a broader view in a different frame of reference like that.

Then I will be on stage during the fast track session to deliver my KDE Craftsmen talk. As I said, like Cornelius I see personal growth opportunities in the community, but I think we don't seize them as much as we could. I'll make the case of why that is and where we could look for inspiration.

Of my fellow fast trackers, I'm especially looking forward to A quick guide how you can save the world or why it is impossible to do usability (what a long title for a short talk!) by Björn Balazs. Another of those skilled people which inspired me in the past, looking forward to what he's up to.

After lunch, just like on day 1, I will stay in the same room the whole afternoon. Only this time it will be room 1...

First I'll pay a visit to Andrew Lake's Community Design and the KDE Visual Design Group. Being stuck in the lower stack so far I didn't get many opportunities to interact with the people in the Visual Design Group. They did a massive job so far so I'm eager to know more on how they got there!

Next, I'll stay for The Designer and its habits by Jens Reuterberg and Thomas Pfeiffer. Looks like I couldn't get enough with only one designer related talk, so let's go for two! More seriously, I'm convinced that we could do better with truly multidisciplinary teams, and that talk might just show a path to creating those.

After that I would have loved to attend Jonathan Riddell's talk titled Do you need to be brain damaged to care about desktop Linux?. Unfortunately I'll have to pass since it will clash with my own talks...

I will give my two sessions almost back to back apparently and that's perfectly logical. You might not guess it from the title but one is the continuation of the other. In Agile to the Rescue, I'll explore the reasons why we probably need to take inspiration of what's going on in the agile community and what we should borrow immediately. In Rebooting Zanshin, I will present the type of results you can obtain by applying the principles devised in the other talk. I will show some code and metrics gathered on the project.

Probably tired of my three talks, I'll gently end the day by attending David Faure Breaks The Law!? by Paul Adams. I expect this talk to be fun in the great Humongous tradition of the term... don't be fooled though! The form might be funny, but the man is also among the most knowledgeable people on community dynamics and management I know of. I'm curious about his findings. I also expect him to show ways in which we can improve dramatically.

Day 3: Workshops

I'll start the morning with my own workshop From QtWidgets Legacy to QtQuick and beyond. It will be two hours long and it will be all about live coding with participants input. Hopefully it should be interesting to many, if we're convinced about using tests we all have the same problem: but I already got a pile of untested code?? What can I do with that? We'll see an approach for exactly tackling that problem.

Then I will likely attend Profiling 101. I ended up profiling applications both for KDE projects and for customer projects. Still, Milian is really knowledgeable on the matter, so I'll see if I can learn some new tricks or improve old ones.

For the last workshop, I'm torn... but I think I will attend Put your code to the test! by Shantanu Tushar. This is so nice to feel less alone at banging the test drums! Also I expect to learn and share on the use of mocks and stubs as my thinking is still evolving on those.

And that's it?

Of course not! The great value of Akademy is outside the official sessions. Like any good conference, a lot is happening in the hallway and during social events. This unofficial track is where great ideas appear.

Also the rest of the week we will have BoF sessions. I plan to limit myself to only three this year: Frameworks, PIM and French Promo. This way it should free me enough time to make good progress on Zanshin. Lately Akademy has been more meetings than coding for me... This year I want my share of coding!

I'm Going to Akademy 2014

This post is part of a series about the KDE Manifesto

As mentionned in my previous post, I have been on a very needed hiatus from public communication. It also means that I delayed indefinitely my series about the KDE Manifesto. If you don't remember the first part, I advise you to read it again first. Now... Let's resume the story telling.

We've previously seen why we needed a tool to answer this question of "What is a KDE project?", in this part we'll see how we tackled the task which led to the KDE Manifesto.

Because of all the events and the questions without answers related in the previous part, some people finally noticed some actions were needed and that we couldn't ignore the symptoms any longer. At one point the discussion started in the KDE e.V. about trying to provide a definition of what is a "KDE project". Then in the KDE e.V. was created a small team which had the mandate to create that definition. I had the honor to be part of that team, and the other members were Cornelius Schumacher, Eike Hein, Ivan Čukić, and Sebastian Sauer. We should really be grateful to the work they put in that task (I know I am).

We started with the right first step in my opinion: collecting feedback from the community and from different projects to see how they perceive themselves and the community. But doing it this way had a downside, we ended up with way too much data, and got completely overwhelmed. That was clearly not easy, and everyone being busy as usual at some point the data got ignored, collecting dust in a dark corner of our hard drives. The team became completely dormant and no communication was going on anymore.

Until... one night... I don't really know why, I picked up everything and tried to map it on paper. I extracted criterias and definitions out of the pieces of text we received. After all, I used to do Knowledge Engineering, that couldn't be an impossible task! That's when I noticed why we felt overwhelmed and silently gave up on the task at hand. If you took all the criterias and considered them equals (which was our mindset all along), you could end up only with a tautological situation: "A KDE project is a project considering itself part of KDE or started by a known KDE contributor". Not a terribly useful outcome, but at least I then knew how to move forward.

I asked the membership of the KDE e.V. to change our mandate in order to move away from trying to define what a KDE Project is and instead determine which characteristics we want KDE Projects to share. It sounds similar but makes a huge difference, you're not working on a closed check list anymore. It made for a much more open space, and not all feedback could be treated equal anymore, there definitely was noise in there.

Once that change of scope got accepted, I summoned the original team again to set up a meeting at Akademy 2012 to work together on the data again. With the given mandate, it was likely not possible to nail it down in finite time remotely. Since not everyone could make it to Akademy, we had to reshuffle the team a bit to make the meeting happen.

And so the meeting finally happened at Akademy, after the KDE e.V. general assembly in presence of Alex Fiestas, Albert Astals Cid, Carl Symons, Cornelius Schumacher, Mirko Boehm, Pradeepto Bhattacharya and myself. We were looking at a very long and intense brainstorming session to go through all the notes which were collected the past months and try to make sense out of them... We all know how this kind of brainstorming sessions can quickly go out of control and be in the end fruitless. That's why I came with an experiment to propose.

Instead of debating the outcome, I proposed a very light process, in the form of a tuned "Prune the Product Tree" game. This game is part of a set named "Innovation Games" which are good for market studies, or emergence of answers to very broad questions like the one we were tackling.

The basic idea is that we went through all the feedback we got, and for each piece of information found, we tried to determine where on the tree it would fit:

  • On the floor if that was irrelevant, or mentionned as something we should avoid as a criterion in the future;
  • On the roots if that was something supporting the community, something the community couldn't function without;
  • On the trunk if that was something central to the community definition;
  • On the canope for anything less central, and derived from the rest, further away from the trunk as it was more refined by-product, in other words consequences from what was on the roots and the trunk.

And so, while playing that game (it's a serious game, but a game nonetheless so it has to be played!) we obtained the following tree:


That's when it struck me... We're not really creating a definition, we're creating a manifesto. On the roots and the trunk it was clearly on the values level, while on the canope you could see practical consequences of those values. I suggested the rest of the team to work on a document which would follow this form: the real manifesto talking only about the high level values, and then extra parts for the practical consequences of those values. This proposition was accepted by the whole team.

Before parting, we also decided to sanity check our result and get an idea of its impact on existing projects. We took a few sample projects and examined them through the tree we produced. Obviously sample projects which were already KDE projects would have to fit, and for sample projects which were not KDE projects we would need to easily identify the blockers for them to join. Reassured by this last check, we parted ways and the editing work started.

I ended up carrying that editing work. I took inspiration in the Agile Manifesto and the Software Craftsmanship Manifesto which went through this kind of exercise before us ("stand on the shoulders of giants" they say). While creating the different drafts, I proposed them to more and more different people, collecting feedback and amending as I go. That led us to the release of the KDE Manifesto in its current form. It is definitely not a document set in stone, I keep collecting feedback and I plan to push updates to the manifesto in the future. I expect the main page to be rather stable, but we'll probably see the rest of it change with time. It seems I turned into the de facto curator for the KDE Manifesto, it's something I try to approach humbly as to not betray the spirit of KDE.

And that concludes this genesis of the KDE Manifesto... it is definitely not the end of the process I mentionned in my previous post. We're really on the doorstep, this document is more or less our late constitution, it's up to the community to choose the path from here. I'm pretty sure it will be full of adventures for the years to come... That's why, even though I generally avoid to do that, in the last part I will try a small exercise in forecasting and see which changes it might bring to the community.