 So, let's begin. Hello everyone, thank you for coming. My name is Will Stevenson, I'm a member of the KDE team at OpenSuzur, 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 the 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 OpenSUSE. OpenSUSE is great for people, say, who are leaving university, who are looking for a job or anything. You can polish those skills, make 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, well, say OpenSUSE, it's actually just SUSE of five years ago. It 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-boot. Every six months or every nine months we put down 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 and enthusiasts. We also have moms. They're reading their family recipe websites. They're keeping in touch with their friends from school. They're participating in online communities. They're uploading their kid photo albums to Flickr and all the other photo websites. You've got the power users. There are 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 may be coming to Linux from Windows. We've got the students. These 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 open souser 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 ex-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 community is all about. It's reaching out. So how many people do you have from each of the different groups? Do you have some students here? We've one student here, OK? We've definitely got some hackers and enthusiasts because 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 open souser who participate and give back to it just a little bit larger. Here's another metaphor. Free software is the highway, it's 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. It makes 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 to 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 a little diagram I drew to show that we've started to introduce KDE and KDE4 on SUSE. So at the bottom we've got the different versions of Open SUSE. 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 horizons. We were just starting to hack it. And as time's 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 KDE4.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.0 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 KDE2 packages on a KDE3 desktop still had the KDE3 equivalents. On 11.0 you had KDE4.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 KDE4.2 back ported. And we started to take out a few KDE3 things, which are completely replaced by their KDE4 equivalents. For example, KTons, 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.0 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 if people want to use them. But as you can see, for the last couple of years, Ratchet been maintaining two KDE versions, so a lot of work and a lot of things 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, at 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 your people who come to foster them, 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 it 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 are some examples. Icons on the desktop. In KDE 4.1, we had a very incomplete implementation of 4.0. We had a very incomplete icons implementation. So you could put icons on the desktop, it didn't work as well as it did in KDE3. People got very upset by that, and they even more so when we tried to introduce the KDE 4.1 folder view, which is we think a much better way of organising those icons. But a lot of users, and especially these were the long-term mailing list people, told us that they really like 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 packaging the 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 desktops. 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... There's a lot of stuff there. And this is a KDE 4.1 desktop. So, you don't want to tell me what I've done wrong here? Yep, no. No, all the mess is because I have an old psycho card of KDE 4.2 on this disk, which is getting picked up. Couldn't happen at a better time. So, yeah, this is what happens when you switch from one version of KDE to another and you have development versions installed. So, to distract you while that rebuilds itself, we 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 icons which are coming, say, from an FTP site or SMB server, whereas on your home one you have something on your local disk, a 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 six months time when KDE 4.3 comes out, an incredibly cool feature, because, as well as just having your virtual desktops, you can also have 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, a folder view, change the location of the desktop, and you've all got my different projects on this view, flip on to another desktop, and we're already stuck. So, as 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, 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 minute, it's very customizable, we wrote a simplified plugin which removes that cashew, that toolbox, and takes away that ability to go into this unfinished work. And we got a lot of our users to try that out. It worked, we made it the standard containment on KD4 for our OpenSuzer 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 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 that I added, and then you've got icons to desktop exactly like in KD3. And that's something that we haven't had a single bug report about since OpenSoot 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, say, KWIN composite effects here, and this is really asking for trouble, but yeah, there you go. It even works on the other, on-burst displays, switching desktops. And we chose to deploy that by default in OpenSoot 11.1, but in order to do that, we needed a lot of testing, because there's so many different combinations of drivers, and having that testing, having these active people in the community really let us get that, 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 you're 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, something's going wrong. 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. It's always better to report too much than too little. Also, as you start reporting problems, learn how to work with the developers, how to actually give them the information they need, and you'll find that bugs get closed much faster and it's really satisfying. 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 Windows switcher. And then there's Alt and Escape, which sends the Windows to the back. It's kind of going backwards through the Windows and he told me exactly what he was. He gave me a reference to the Wikipedia article and we got that fixed in days, in hours, sorry. And then 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 doing on 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, open to use a KD dog. I'll show you the link at the end. Come to the meetings every Wednesday, every second week at 1800 European times, 1700 UTC. We have a bi-weekly meeting and there's always a very friendly town hall type atmosphere. People can come and 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 the security releases. 4.2 factory where the next product is being released. And we even have a 4.3, which is based on 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, even if you're writing something in Java script 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. It's good fun. And you can submit your changes up to us. We'll take everything. Jump to forward a bit there. We have Bugadays. If you're someone who's reporting something in Java script or if you're someone who's reporting a lot of bugs and really getting into the process, come to those Bugadays 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, planetSousa.org, regular contributors are welcome to syndicate their blog there. Translate is your language. We have, 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 OpenSousa. And if you're a specialist, any of these things, educators, writers, hardware freaks, sys admins, 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, we want to make your experience with OpenSousa as good as possible. We can't do everything for you but we are very well connected in the OpenSousa 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 they need to reach to get things fixed. So these are the concrete things that we're working on the moment. 11.2 is coming up in probably six months or a little bit longer time. But they'll 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 you said, there's lots of ways to 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 customised open source. Only installs KD3. We'd love to have somebody who would take over that. Now by telling me what else I need to change or any other questions that come to mind. Thanks. 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, I'm going to get 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 opened their seat belt and they pressed 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. 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 it 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 bug reports where we've got four people 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 the other people's perspectives on this bug, show them a bug and then communicate it to us in a way that actually shows it to us. So, make some connections. It's, 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 leaving that rut and going over the bumpy bits where you just 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 10 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 any more? In terms of when you do find a problem and it's with a KDE package like where is the dividing line between reporting it through the Susie 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 like, do you know the sys info Ioslave if you click on my computer I mean we wrote that originally. It's now kind of 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 Vell bug so 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 then let everyone run into it so example of tough my head migration of email distribution lists to from KDE 3 to KDE 4 it's broken by designing KDE 4 the guy who wrote it has a particular view 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 stuff across OK so I have a specific problem and if you want me to take this offline fair enough but I find K-mail in KDE 4 horrendously slow in comparison to KDE 3 now 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 points? In terms of K-mail I hack on K-mail a little bit I've got some small patch in there but I'm not the expert but I do have very good communications with the K-mail maintenance 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 umf if I put my name on the CC saying yes this is a problem OK so even if you've got any specific other specific problems that are bugging you was that on 4.1 or on 4.2? 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 or 12,000 emails on my system but I'm not downloading that many emails it can only be 10 or 15 but K-mail hangs for seconds OK Now I haven't seen it on myself I don't have a header listing but report it and we'll take it upstream Thomas? I actually know that That's open in Barcelona It's registered in Barcelona as IMAP slave being incredibly slow on Q4 or K-Evo I don't know the statuses but it's known It's always the troll tech people who have big bad K-mail problems and shout the loudest about it, isn't it? I can say a name Is it troll? Do we have any emails on another level? 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 and see the list as well and I'll make sure it goes into OpenSuser We're not so relevant 4.2 but we are doing a big 4.1 update with all the things that went into Sled Well if there's no other questions then I can hug the microphone for another 2 seconds KD 4.2 I see it was released with QT45 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 happy enough with it that it generally works or How do we know what the status is of such a repository? If it's referred to from the KD4 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 vs QT45 Mainly that is for us it's a QA verification that QT45 can actually build everything and you have discovered significant problems that say TrollTec weren't aware of using that If you are using the repositories you should be on the mailing list on the open to the KD 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 it's like 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 a wiki I know the synchronisation of that stuff is quite hard but ok let's forget about synchronisation imagine I want just a straight blank page and I want to write on it offline and being able to open it and synchronise and create it online so the diary on contact doesn't make pretty much any sense well it will once it 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 it's in information which is pretty much updated and you can share it it's a nice idea I think that will probably happen in the KDE 4.3 timeframe 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 but thank you, 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 you know those kind of features thanks Steve ok well thanks for everyone for coming if you've got any more questions oh question well I started using the boontoo for one reason it had 0704 and I could know when it was done I know 910 I mean 0810 I know when it was done I don't know why everybody doesn't adopt just you know some little thing oh 9 and we all in fact you don't even need this until 20th everybody knows hexadecimal and so the next year will be A and the year after that will be B and you can keep on going down to 2035 2035 will be a Z and you can do the month right after that December 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 because so many times I see something on the internet about some great package and I look up and it's been dead for 5 years if I at least had something like this before 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 package software not even knowing RPM packaging and you could make a customized distribution which added to say a suffix containing this information give it a go it might be a winner Thanks everyone