15 August, 2008

innovation BOF

The innovation BOF went both worse and better than I expected. It turned out to be hard to go from the theoretical level to more practical implications. But the audience was great, they came up with some very useful ideas, which I'll go through in a minute.

But first about the questionare I've blogged about and which I would like the KDE contributors to fill in. It measures things which according to lots of scientific articles are important for innovation. This is mostly kind'a vague, think about concepts like 'formalization' which measures the extend to which the organization uses formal structure & rules to get things done or keep ppl in line. The idea is to see if there are area's KDE is doing bad in, and then figure out what we can do to improve. The full questionare takes approx. 30 min in dutch, and I've removed a bunch of questions, but I can't promise it'll take you less than 30 minutes. It has been translated, and most of you take it in another than your native language, which might make it take longer.

It is very important to fill in all questions. I know this feels targeted to commercial organizations, so you might have to think of a way how this applies to you. Please try to do so, because I can't use incomplete questionares. Here it is: questionare.

In the BOF I essentially went through the constructs, explaining what they did and meant. Some nice ideas came out of the resulting discussion. Here are the notes:

To increase input from users and improve our incremental innovation (bringing a more polished user interface):
- get a 'suggest improvement' menu item in the Help dialog. At first this should report a wish, but in time it should probably point to an ideastorm (Ubuntu's site, Dell's site) like page. We should try to make it as easy to add input as possible.
- basket had/has some very cool user-feedback-gathering tools, it would be great if someone would pick that up. It would be useful during alpha's and beta's go gather (statistical) input.

When it came to the importance of psychological safety, autonomy and involvement in decisionmaking:
- forcing usability on developers would hamper innovation as it's bad for psych safety. It is important to keep things very closely ingegrated - integrate usability in the 'normal' tutorials. The ideas about a new development model, 'always summer in trunk' and such are also smart in this regard.
- related would be the rewarding of innovative ideas. Maybe have an interesting-branche-of-the-week article.
- and to improve serendipity we should keep ideas which didn't work very well around - it does often happen that things which didn't work in a certain context are a huge success in another place.

The final idea which came up was to have 'innovation sessions' at akademy for certain innovations. We could discuss ways of improving the application in major or minor ways, brainstorm about issues etc.

Now I have to think of what needs to be done to capitalize on these ideas, make them happen. Stay tuned for another blog, and of course the analysis of the survey data.

All in all, it wasn't as great as it could be, but it did turn out to be useful. And I've learned something (still have to figure out what exactly).



  1. On encouraging innovation. Could moving to GIT revision-control help?

    Take this suggestion with a pinch of salt as I am not a real programmer and have never used a revision control system in my life.

    However all that I hear about it on the ol' internet is that it makes it much easier to try-out new ideas and makes it much easier particularly for non-core developers (ie those that in SVN would have commit-access) to get involved without compromising the stability.

    I'm sure this conversation has been had but from a personal point of view I'm interested what the reasons are for not using GIT are (since I have only heard positive things about it).

  2. Oh. Also dude, don't feel bad about the discussion not going well in your eyes. These are very difficult questions and I'm sure it's worth it just to get the collective and individual minds turning this over, good stuff will come of it.

  3. Hi Jos,

    Had a good Akademy this year?

    Regarding the Basket stuff, one KMess developer already started porting that to KDE 4:

    I like such feature a lot, and would like to see this in KDElibs. Since things are speeding up quite well, I'd rather post about our progress here instead of having multiple people working in parallel on it. ;)

    (most easiest way to contact us atm is by posting a message at http://www.kmess.org/board/ btw. I'm also on the kde-core-devel / kde-devel ML)

  4. Maninalift: the git migration is related to the always-summer-in-trunk thing I mentioned. The short: you're right.

    @Diederik: that's really great and interesting. This would be worth a blog... Maybe when I have time I will write about it, but first I have to recover from the car accident and get some other work done.


Say something smart and be polite please!