So, let's begin. Hello everyone, thank you for coming. My name is Will Stevenson, I'm a member of the KDE team at OpenSUSE, and I'd like to talk to you about how we're

changing our development model to make it more friendly and more open, more accessible to the grand community and get your input and hopefully motivate you to join us. We're a small, friendly community, we're made up of a mixture of long-term KDE contributors

and veteran users and a few new faces, and we think that 2009 is a real exciting year here on the free desktop. There's a lot of stuff going on, it's a great time to get involved. And when you do contribute, there are a lot of things that are going to be good for you and good for the community, so here's some reasons. When I was writing this talk,

I sat down and I thought, why do I actually do free software? Why do I contribute? To speak from experience. Well, it's software that I can change to exactly my taste, I can make it do just what I want, if I put the time into it, and it's going to be interesting and useful for me to use. It's software that won't just fall to pieces,

that won't expire, that won't stop working when I upgrade my operating system, because it's free software, it can be maintained by anyone who wants to work with it. And it's software that's easy to communicate with the developers. You can go out there,

you can find these people, you can work together with them, get their feedback on your ideas, and that makes it all a pleasant experience to work with. You don't find you're talking to a brick wall, you're sending support emails that never get answered, and you build

a relationship with the software. As a result, you get all these people working together and you get software that meets everyone's needs. Then by interacting with all these people, you're out there, you're meeting people from all over the world, you're improving your skills, you have a chance to share your expertise, and pass that on to other people

around the world. And the end result, and this is what really does it for me personally, is that we together create a common good, a body of work which is useful and out there

in the world for anyone to take, to use for their purposes, to make better. And that really inspires me. And it's not just something that ends up going as a small plus on someone's share price. When I use my software that I've helped write, or software that I've reported a bug on, and I've seen it fixed in the next release of OpenSUSE, it just

gives me a buzz. It makes me feel like I've got something I can do in the world that makes the world a better place. And frankly, it's a little ego boost. So contribution has loads of benefits. You improve your skills, you get your name known, you get in touch

with a lot of people from around the world. You improve your skills. In a down economy, it's actually a great time for open source. Open source is great for people, say, who are leaving university, who are looking for a job or anything. You can polish those skills,

make it a visible curriculum vitae that is a real benefit to you when you're looking for a job. And it just makes your life easier. Using the software, it just becomes fun because you know it's tweaked exactly how you want it. And also, I'd like to show you

how participation is, in fact, essential. If we look at the OpenSUSE model, say, five years ago, we had a bunch of hackers and enthusiasts making software for people like them, for

hackers and enthusiasts. And that worked great. It was just tickety-boo. Every six months or every nine months, we put out a new box with a new fancy geometric shape on it, everyone updated, and it went. But nowadays, things are a little bit different. Sure, we have more hackers than enthusiasts. But we also have moms. They're there, they're

reading their family recipe websites, they're keeping in touch with their friends from school, they're participating online communities, they're uploading their kid photo albums to Flickr and all the other photo websites. You've got the power users. These are the

guys who maybe aren't developers and such, but they're the guys who really know how to take an operating system and tweak it exactly how they like it. And they're maybe coming to Linux from Windows. We've got the students. These are guys who are smart people, but they really want to get the latest videos and things on YouTube. They

want to use all the social networking websites. They've got a very online experience. All these groups are using software completely differently. And we've got the suits there, the enterprise users. They're seeing the OpenSUSE as a base for doing powerful

enterprise software. And back in the day, we had 150 guys in their 30s in Nuremberg in Germany who knew exactly what they wanted. They wanted a really good busy box, a black box or a rat poison, an X console, RCI and a few other bits and pieces. But in

order to make a piece of software that really meets the needs of all these different disparate groups, we need as much participation from all these different groups as possible. So this is what growing the community is all about. It's reaching out. So how many people do we have from each of the different groups? Do we have some students here? We've

one student here, okay. We've definitely got some hackers and enthusiasts. I know quite a few of you. Have we got any moms? No moms. It's Sunday afternoon, so they're probably doing something with the kids. I know we've got a few enterprise people too. I know

you guys. So if any of this touches a nerve, if this means something to you, think about this model and think about how you can make the pool of people who work with OpenSUSE who participate and give back to it just a little bit larger. Here's another metaphor.

Free software is the highway, it's the motorway that creates all these benefits that we want to, that I spoke about in the first slides, that we want to create in the world. Make software useful. Participation is the engine. That's the means by which we drive it forward. And contributing into that engine is what keeps that engine turning

over, what keeps new improvements coming out there. And also it's a question of democratic participation. If we only have a small core of people who have their own particular interests who are contributing, but we have the software which is used by all these people, it's not going to be very democratic. It's going to be going in one particular direction.

So in order to keep this democratic process going, we need to keep on looking at and expanding the participant groups. But anyway, you came here to hear about KDE, I guess. So this is what a little diagram I drew to show how we've started to introduce KDE and KDE4 on SUSE. So at the bottom we've got the different versions of OpenSUSE.

On the timeline you've also got the versions of KDE that went with those versions. And two and a half years ago we were purely KDE3. KDE4 was something that was just barely

on our horizon, we were just starting to hack it. And as time has gone by we've increased the mix of KDE4 components and started to take out a few KDE3 things where we think the KDE4 components have been ready to replace them. And this is something that as a community has been very important to us to communicate what we're doing, because people are very attached to their software. I've talked

already about how there are so many ways that you can make a personal investment in your software, and that means people really like it. So we didn't want to do anything which was going to take away what people had already put into the creative system that they wanted. And this was something that created a lot of difficulties for us, because

at the time when KDE 4.0 was released, which was about here, a lot of people got into a mode of thinking, well, this is very polished, it's very good, it's just

like a commercial product. In fact, something which I'm just going to be able to take and run with, and it's going to do everything KDE3 did with. And for good or for bad, that perception somehow got spread around. What we're trying to do at SUSE when we've talked to our users is keep it very clear that we're not going to force anyone like a certain guy called Dennis Torvalds to give up his KDE3 too soon.

So in 10.3, we had a preview of a couple of KDE games and KDE Edu packages on a KDE3 desktop, still had the KDE3 equivalents. On 11.0, you had KDE 4.0.4, which was put

out there as a developer preview for everyone to try and use and to give us feedback on. Still the full KDE3 desktop. When we come to 11.1 now, we've got 4.1 on there with a lot of tweaks from KDE 4.2 backported. And we started to take out a few KDE3 things

which are completely replaced by their KDE4 equivalents. For example, ktorrent. It's already leaps and bounds ahead of the KDE3 version. This is where we are now. Looking forward to 11.2, we're going to have an almost fully KDE4 system, hopefully based on KDE4.3

point something. And the KDE3 components are going to take a much less prominent role. They're still going to be available in the build service and everything, and still have live CDs and things available for people who want to use them. As you can see, for the last couple of years, we've actually been maintaining two KDE versions.

There's a lot of work and a lot of things that need to be done. And this is how we actually do it. You're probably all familiar with the open source development model, but you've got upstream projects. For example, our KDE3 in the middle of this diagram. We've got distributions around them. They're taking the software and putting it together into a coherent whole. And then you've got all these users who are taking this and using

it. And this process is the one that we want you to get involved in, because you're people who come to FOSDEM. You know you have technical expertise. You know what you want. You know how free software works. Also, your users, you know you actually have a

stake using software, and you know what works for it. So by joining in, you can add your information gathering abilities and your skills to create something which is useful for a lot of other people. And here's some examples. Icons on the desktop. In KDE 4.1, we had a very incomplete implementation. At 4.0,

we had very incomplete icons implementation. So you could put icons on desktop. It didn't work as well as it did in KDE3. People got very upset by that. And even more so when we tried to introduce the KDE 4.1 folder view, which is, we think, a much better way of organizing those icons. But a lot of users, and especially these were the long-term

mailing list people, told us that they really liked their icons, and they really panicked a little bit when they thought they were going to have a desktop which was like a Mac desktop, completely empty. But we have our regular meetings. We listen to people.

We came up with an accessible alternative, which was the packaging, the, you know, folder view containment. And we made that accessible then by making it one click away when you do a default install of 11.1 from the greeter that comes up. Then we have the

cashew toolbox buttons. Does everyone know what the cashew is here? Does anyone not know what the cashew is here? Okay, I'll demonstrate the cashew to you. So here we have a normal desktop. It's got my wife on it. In fact, I'll show you

the icons as desktop. So this is a folder view. This is the replacement for icons on the desktop, because you can change the folder views that are on different desktops. Let's get rid of that one. But if you really want your icons back, you can

just choose your, ah. Ah. That's a lot of stuff there. And this is a Kd4.1 desktop. Does anyone want to tell me what I've done wrong here? Yep, no. No, all

the mess is because I have an old psycho cat of Kd4.2 on this disk, which is getting picked up. Ah. Couldn't happen at a better time. So yeah, this is what happens when

you switch from one version of Kd to another and you have development versions installed. So to distract you while that rebuilds itself, we have our, have this thing on the desktop

called the Cashew, which is a desktop toolbox which allows you to zoom in and out your desktop background and switch between different versions of your desktop background and manipulate

the desktop so you can have, for example, you could have icons on one desktop. You could have sidebar panels on another desktop. You could have, on a desktop which is for work, you could have a, um, icons which are coming, say, from a FTP site or a SMB server,

whereas on your home one, you have some things on your local disk. On your university one, you have something related to particular courses. Let me see if I can demonstrate that now. So here we have the Cashew. This is a really going to be, maybe in a six

months time, Kd4.3 comes out, an incredibly cool feature because as well as just having your virtual desktops, you can also have kind of virtual desktop furniture, so different sets of icons on each desktop. So there we go. We zoom out, we've got a different

panel. We can then zoom in on this one and you can see the picture widget that I've got in the background is completely different, just as an example. Add some widgets and a folder view. Change the location of the desktop and there you see we've got

some different projects on this view. Flip onto another desktop. We're already stuck. So you can see this is a feature which came from upstream and wasn't completely finished,

which for us as the people who talk to the end users, who make something that everyone has to be able to use, is not something that we want to put our users through. We don't want to give something where you can say, oh, well, what is this crazy checkerboard stuff? As we all know, it's raw plasma, but it's not particularly useful or particularly

pretty. So what we did was we took out the folder view. Because plasma is very pluggable, it's very customisable, we wrote a simplified plugin which removes that cashew, that toolbox, and takes away that ability to go into this unfinished work. We got a lot of our

users to try that out. It worked. We made it the standard containment on KDE 4 for our OpenSUSE 11.1. And that's another angle which is quite interesting when you're becoming part of the team. You then find yourself talking to the end users who don't

do anything at all, and also to upstream. And it can get really hairy, because upstream are passionate people who are putting in a lot of work into making their features work exactly as they want. But sometimes it just doesn't meet users' needs, and then you've got a bit of conflict there. So if you want to hone your project management skills and your product management skills, it's a good thing to do. And then we wrote

this plain desktop plugin, which is the one that I was showing you there, which is desktop settings, and plain desktop, no cashew. Take it all the way back, folder view,

get rid of the other widgets I added, and there you've got icons, desktop, exactly like in KDE 3. And that's something that we haven't had a single bug report about since

OpenSUSE 11 was released two months ago. So we're pretty happy that in this case, having an open, transparent development model has helped. And then we've got hardware adaptation problems. It's kind of obvious. We've got KWin composite effects here, and

this is really asking for trouble, but yeah, there you go. It even works on both displays. Switching desktops. And we chose to deploy that by default in OpenSUSE 11.1. But in order to do that, we needed a lot of testing, because there are so many different combinations

of drivers. And having that testing, having these active people in the community really let us make that work. And then we had to choose how many plugins, how many different effects to enable. We went down, we talked to people, we found a set of plugins which was neither so much eye candy that you think, I need to be 14 years old to enjoy this,

but also a set of plugins which are actually quite useful and support you in your daily work. So for example, a slight dimming of inactive windows enables you to focus on the window which you're actually working on. Some transparency effects. Nothing in

your face, but it works. Network management, something that we're working on for 11.2. Same problem, you've got a lot of different drivers, a lot of different configurations, a lot of different networking cards with different support, and it all needs testing. And it's something that even the most peripherally involved user can come and help

us out with. Just give us that feedback. We've got a debug page there that shows how to give us exactly the feedback that we need to fix the bug, and usually we can have a bug fixed in half an hour or something if I'm awake at that time. So there's a few things that help making being a community member work. Spread the word,

pass it on. There's a great audience here, but I'm not speaking to the whole world, and I hope that you could go out and do that for me. When using something, if it works well, tell us what works. It's nice to hear about it, and it's good to know that it's working for you because it might be working for us and we don't know if it's

working for everyone else. Conversely, if something's going wrong, don't just get used to it. Don't get hardened by things going wrong and you think, oh, well, that's obvious. It's going to get fixed next release. It may only be happening on your desktop or it may only be happening on your motherboard, but it may not be the one that we've got. We may not know about it. So it's always better to report too much than too little.

And then also, as you start reporting problems, learn how to work with the developers, how to actually give them the information they need. You'll find that bugs get closed much faster and it's really satisfying. For example, I was on Linux Weekly News last week and a guy was telling me, hey, there's this shortcut from Windows that I really,

really miss in KDE 4, and it's Alt and Tab as your standard window switcher. And then there's Alt and Escape, which sends the window to the back. It's kind of going backwards through the windows. And he told me exactly what it was. He gave me a reference

to the Wikipedia article and we got that fixed in days, not in days, in hours, sorry. And while you're doing it, have fun while you're doing it. Don't feel that you have to do this. Don't get so bogged into it that you put aside doing things that are

fun, because you won't stick it. Do it when it's fun. When it's not, play Space Invaders. I don't care. Do whatever. And here's a few things that you can do to contribute. We have a mailing list. Active mailing list, good technical resource, OpenSUSE, kd.org, I'll show you the link at the end. Come to the meetings every Wednesday, every second

week at 1800 European time, 1700 UTC, and we have a biweekly meeting. And there's always a very friendly town hall type atmosphere. People can come raise their problems.

Lots of in-house developers go to that. Test our packages. We have a lot of repositories where you can always get the freshest kd4, so we've got 4.1 stable where we're testing security releases, 4.2 factory where the next product is being released, and we even have a 4.3 which is basically kd4 trunk. You can really get to the bleeding edge

with that. Come along, meet us, learn to package the software. If you're writing a little plasmoid or applet, you might be writing something in JavaScript or a little

bit of Python. We'll show you how to package it and get it out there. You can put it in a repo and you can tell your friends, hey, one click, click on that link, and you get my software, and it's good fun. And you can submit your changes up to us. We'll take everything. Jump forward a bit there. We have bug days. Someone who's

reporting a lot of bugs and really getting into the process, come to those bug days and you can just help us triage the bugs and get a few bugs out of the system. And then share your experiences. We've got blogs, planetsuza.org, regular contributors are welcome to syndicate their blog there. Translators is your language. Because we're

doing custom work, we've got some stuff that isn't getting translated upstream, and we have a system for getting those translations back into OpenSUSE. And if you're a specialist, any of these things, educators, writers, hardware freaks, sysadmins, we need these interest groups to get your specialist feedback. You can become a domain expert in this

area and really become a figure in the group. And finally, say you don't want to contribute. That's fine. We're still on your side and we've got your interests, best interests

at heart, and we want to make your experience with OpenSUSE as good as possible. We can't do everything for you, but we are very well connected in the Open Source community, so we can go out there and we can pass on your information, make sure that your bug reports get better and better and go out there and reach the ears that they need to reach to get things fixed. So these are the concrete things that we're working

on at the moment. 11.2 is coming up in probably six months or a little bit longer this time. We want to set our goals and priorities now, and that means we have things to work on. So we need to really pick on a few focus areas, things that are really important to us, and we'd like to know what you think is important and what your friends think

is important. So come along to those meetings and tell us what's going on. We want, on 11.2, we're going to have Kd4 as the Kd desktop that you get from the installer, which means that any regressions which are left versus Kd3, we need to know about them now so we can get them fixed. And as I said, there's lots of ways we can join

us and help out, and just take responsibility for certain areas, so maybe making sure that our Amarok packages are always really good. And then if you're a Kd3 guy and no one's ever going to take Kd3 away from you, it's Open Source software. It's there for you to use. It's still in the build repositories. You can take that and you can make live CDs,

you can have one-click installs, you can make customized Open Source Kd3. We'd love to have somebody who'd take over that. Okay, so that's all from me. You can start your participation now by telling me what else needs change or any other questions that

come to mind. Mike, just give it a minute to warm up. Okay, my first degree was in psychology, and I'm going to give a physical example first. The United States Army made a jet with the parachute on the seat, and they kept getting

people that parachuted out of the plane without a parachute. And they thought, something must be wrong. Well, the engineers had perfectly placed an eject button just past the point where they had to open their seat belt. So they open their seat belt and they

press the eject button, and of course, they're out without a parachute. Well, physical things like that are pretty obvious how stupid it is. But I've given up trying, I've written dozens of bug reports about psychological factors. And without fail, I get back, well, it works for me.

You know, I can do it, and several other Linux gurus get on and say, yeah, yeah, it's all just right. Leave that stupid idiot alone that works with common people. So how do we get

over that kind of problem? It's definitely a tough one. Just hold on for a second. You might want to say something else. One way around that is that we've got the, just point away from me. Thanks. Great. One thing we've got, we've got a voting system, which means

that if a bug is really showing up, we'll see not just one bug report, but we'll see a lot of votes on it. And we're not going to go closing for bug reports where we've got four people or two people saying that it's all a problem. Then we'll always take that seriously. I don't think that works very well because it's for the people that already know how to use the software rather than the masses of people that

don't know how to use the software. I think the other thing is really to become an advocate within the community. You've got psychology training, you're a communicator. Then you can go out there and talk to people, get other people's perspectives on this bug, show them the bug, and then communicate it to us in a way that actually

shows it to us. So, make some connections. You know, as a psychologist, people have very subjective views on software, and it's very easy for developers to get into a rut

where they only use the software in one way. And that's lethal because you're in that rut, you're never actually going, leaving that rut and going over the bumpy bits which don't get so much traffic. But those may be unknown to you and unknown to me because I've been using KDE for like ten years now, the most frequently travelled paths for people. So, it takes a little bit of persistence sometimes to look at a

problem from a different angle and formulate the problem in a way that will make us see it. But when we do see it, if it's genuine, we won't throw it out. Any more for

In terms of, when you do find a problem, and it's with a KDE package, where is the dividing line between reporting it through the SUSE channels or going directly to KDE channels?

It's not a firm line. It depends very much on the severity of the bug, and whether, but the primary thing is whether it's in something that we've done. So, for example, the sysinfo ioslave, if you click on my computer, we wrote that originally, it's now used everywhere else, but we want to hear about bugs there first. Network manager,

the applet that I've just been writing, stick it in the bug, I'll see it straight away. But on the other hand, if it's a severe bug, we don't want to put our software out there and let everyone run into it. So, example off the top of my head,

migration of email distribution lists from KDE3 to KDE4. It's broken by design in KDE4. The guy who wrote it has a particular view, so it doesn't show up, but it's not for the basic default user, it's broken. So I'm fixing that, and I'm putting out a migration tool which will copy people's stuff across.

Okay, so I have a specific problem, and if you want me to take this offline, fair enough. I find KMAIL in KDE4 horrendously slow in comparison to KDE3. I don't know if that's a configuration, if it's the way it was compiled, or it's a bug in the KDE code. So for that particular problem, at what point?

In terms of KML slowness, I attack on KML a little bit, I've got some small patches in there, but I'm not the expert. But I do have very good communications with the KML maintainer, so something that's there, I will probably close upstream with a reference to the upstream bug, and then pursue it upstream and integrate the

changes in our packages. If you want to go upstream straight away, that's fine, do that as well. If you go through me, it might get a bit more oomph if I put my name on the cc saying, yes, this is a problem. Okay.

So even if you've got any specific, other specific problems that are bugging you, was that on 4.1 or on 4.2? Is that when you're listing email headers, when you

switch to a new folder, it takes a while for the emails to appear in the header list? Just even downloading email. I've used distributed IMAP and I have 10,000 or 12,000 emails on my system, but I'm not downloading that many emails, it might only be 10 or 15, but KML hangs for seconds.

Okay. Now, I haven't seen that one myself, I know about header listing, but report it and we'll take it upstream. Thomas? I actually know that, but that's open in Brazil, it's registered in Brazil as IMAP slave being incredibly slow on Q4 or KU4.

I don't know what the status is, but it's known. Yeah, it's always the troll tech people who have big bad KML problems, and shout the loudest about it, isn't it? I can say a name. He's a troll, everybody knows him, but...

So yeah, look us up online or search for the bug yourself and see yourself onto it, and you can stick my name on it on the CLC list as well and I'll make sure it goes

into OpenSUSE. We're not so relevant to 4.2, but we are doing a big 4.1 update with all the things that went into sled 4.1 for OpenSUSE 11.1. Well, if there's no other questions, then I can hug the microphone for another two

seconds. KDE 4.2, I see, was released with QT45. Or there's RPMs in a repository released on pulling these things. I presume once packages are out there like that, that effectively means you guys are

working on it and it generally works. How do we know what the status is of such a repository? Go online and ask questions. Good question. If it's referred to from the KDE 4 page on the wiki, then it says what degree of confidence we have in it. Otherwise there's no guarantees.

For example, we're building 4.2 versus QT45. Mainly that is for us it's QA verification that QT45 can actually build everything, and we have discovered significant problems that, say, TrialTech weren't aware of using that. If you are using the repositories, you should be on the mailing list,

on the OpenSUSE KDE mailing list at least, and it also doesn't hurt to make sure you read our blogs. A lot of people have burnt fingers from that repository because they all went, weeee!

I have a new feature request. In fact, I have it since 2005 or something. Nobody wants to do it, so I just propose it everywhere I go and somebody asks for new features. I use contact and I use wikis, so I want the diary finally being able to be used as a wiki client,

where I can choose the syntax of the wiki. I know the synchronization of that stuff is quite hard. Okay, let's forget about synchronization. Imagine I want just a straight blank page and I want to write on it offline and being able to open it and synchronize it and create it online.

The diary on contact doesn't make pretty much any sense. It will once you can look for that information, but since it's ticked on the calendar,

once the days pass, you lose it. So at least with wikis you can still, it's information which is pretty much outdated and you can share it. Yeah, it's a nice idea. I think that will probably happen in the KDE 4.3 timeframe with Akanadi

because that means you have that separation between the content of your application and where it's stored much more strongly than we have now. And I'm not aware of a wiki client specifically for KDE, but we are seeing a lot of growth in access libraries for online services, so blog things, remember the milk. So I could imagine that there might be

the components to make something like that fairly soon. Good idea. I did look into doing that myself a little while ago, but one of the big troublesome aspects of it is complicated syntax of,

for example, media wiki. Supporting templates would be very hard, and those kind of features. Thanks, Stephen. OK, well, thanks for everyone for coming. If you've got any more questions, find me. Oh, question. No, stay put.

Well, I started using Ubuntu for one reason. It had 07, 04, and I could know when it was done.

09, 10, I mean 08, 10, I'd know when it was done. I don't know why everybody doesn't adopt just, you know, some little thing, 09, and we all,

in fact, you don't even need this. Until 20, you know, everybody knows hexadecimal, and so the next year will be A, and the year after that will be B. You know, and you can keep on going down to 2035 with, you know,

2035 will be a Z. And you can do the month right after that. December is going to be C.

And you can do the dates all the way down to 31, which is going to be V. And then after that you can put 1.3 or 0.8 or whatever you want to do. No, because so many times I see something on the internet

about some great package, I look up and it's been dead for five years. If I at least had something like this before it, I wouldn't even look up to see, you know, what the current status is once I saw that it was this. Thanks, that's an interesting suggestion.

The good thing about the build service is it gives you the chance to take all those ready-packaged software, you know, not even knowing RPM packaging, and you could make a customized distribution which added, say, a suffix containing this information. Give it a go, it might be a winner.

Thanks everyone.