This year, Akademy is being held together with other Free Software conferences, all rolled up into one. The umbrella we all live under is QtCon, and it will bring KDAB‘s Qt Training Day, the Qt Contributor Summit, Akademy, as well as the FSFE Summit and VideoLan Dev Days under one roof (well, multiple roofs; one umbrella). The call for papers is now available.
Because of this wide range of events at one time, there is unprecedented opportunity for presenting your work to a broad audience. I’ll be there; maybe “Keeping Qt going on non-tier-1 operating systems” is a useful talk to give. I really want someone to submit an “Optimizing Qt scene graph through algebraic geometry” talk, too. And a “Biggest video wall in Amsterdam with Qt and VLC”. And “Estimating proprietary development through observation of Free Software development”. And .. gosh, the list goes on and on.
Deadline is may 15th!
I for one applaud the decision to put Akademy
-badges on the KDE community
I was afraid I was going to have to apply my awesome Kolourpaint skills again. Albert’s reminder
has caused me to figure out my reasons for attending Akademy this year. So my agenda is four-or-fivefold:
- attend the AGM of KDE e.V.
- talk to Paul Adams about measuring community health. Technical aspects of measurement aside, I have some serious methodological misgivings about what he’s measuring and how he’s presenting it. This will require several beer mats of exposition.
- see if there’s any other FreeBSD users about. Or, for that matter, OpenSolaris people or anything else non-Linux.
- talk to Lydia and Valorie and other folks with knowledge of techbase and community to see if I can contribute there. There’s a lot of stuff that is undergoing a complete rewrite — but has been undergoing that for a long time.
- hear from the FrogLogic folks how their test-tools have evolved. It was a long time ago that we had some ideas of doing KDE HIG checks on the EBN.
There is of course also an implied 6(a) meet new people in the KDE community and 6(b) drink beer with them.
Congratulations to the organizing team of the Berlin Desktop Summit (or Desktop Summit in Berlin). Lots of good stories of collaboration. (That’s collaboration that might not show up in any kind of measurements or indicators, though, if there’s no electronic record of interaction)
The weeks including Akademy were crunch time at work for me, trying to replace a home-grown Python ORM (with its own implementation of String, List and Number) with SQLAlchemy. As in any refactoring project after five years of development, it turns out that everything is connected to everything else. Every nice clean design diagram with three layers or decoupled components just hides hideous purple tentacles reaching into every interface.
So, yeah, Akademy week was busy, but not in the way it has been for the past few years for me.
Although my term on the board of KDE e.V. was to run another year, I found that I really didn’t have the time to put into it properly, and stepped down before the desktop summit. Lydia was elected, as well as Cornelius who was renewed in his mandate. Congratulations particularly to Lydia, who brings a good deal of community management and organization skills to the group.
My friend Armijn sent me this, and asked if I would pass it on. He adds as a word of warning “this is a post that can easily ruin your mood“.
Almost all free software developers I have met are always very enthusiastic about their programs and what to add and improve in the future. Very few of them think what happens afterwards. With this I don’t mean what happens after those additions and improvements (your answer would probably be “more additions and improvements”), but I mean when there is no future. When you’re no longer coding. When your uplink is permanently disconnected. When you’re dead.
Planning for the inevitable is not something we want to think about (thinking about your own mortality is not many people do for fun), but it is something we need to do, all of us. I was remembered about this by two recent events. One was when at gpl-violations.org we got a report about a violation in the Apple AppStore. Since I had already dealt with the same developer in the past (it was resolved very amicably) I decided to connect the reporter directly with the developer. The reporter got an unexpected surprise in the form of an e-mail from the developer’s father who said that his son had died half a year ago and he could not get himself to pull the app from the App Store, as a tribute to his son. Eventually we got sources when one of the developer’s friends (another engineer) was involved to lift the sources from the deceased developer’s laptop.
Another example was when a webmaster of a website that my dad regularly contributed to, died in a fire in his house. The website contained many years of research, at least 10 years, but possibly many more. Many people had contributed to this research, but the data was only available through the website. The database itself was hosted on baseportal.com which allows people to have a free database. How to get the data back, especially someone else’s data is completely unclear. At the moment people are trying to reach the heirs of the webmaster so they can salvage the data and make sure the webpage continues as a tribute to the original webmaster.
The common theme is that these people were very passionate about what they did. They truly loved their work and it work was appreciated by many. But when fate struck it turned out that they had not taken care of what would happen after they would pass away. I am very sure that they didn’t expect this to happen so soon, or never realized that this could be an issue. But in the digital world, with lapsing domain name registrations, databases and webspace being deleted because of unpaid bills, offline development trees and uninformed heirs this is becoming more and more of a risk.
So, what can you do prevent this from happening with your code and data? First, move your development as much online as possible. The KDE project has great infrastructure for this. Second, think about assigning your copyright to KDE e.V. with the FLA. If you don’t want to do this, make sure that your heirs know what you have been doing with free software and what they can and cannot do with the code. Show them that you care a lot about this.
Don’t let this story scare you too much. Keep coding, with passion, knowing that if you have taken the right measures your code will live on and will (hopefully) be used, reused and adapted by many people, even after you are no longer here.