First of all, I would like to say that Clarista's talk was quite interesting to me. She touched on some of the topics that I'm also going to touch up on. But I'm coming from a completely different angle from Clarista in that I'm an actual nerd, if you like. I'm a geek. I've been involved in quite a few open source projects, very quite different projects.

I used to be a gentle developer for quite a few years. Left that back in 2006 or 2007, ended up starting my own Linux distribution called Exurbo, which is also a source-based distribution, much like Gentoo.

And most of the things I'm going to talk about today is based on my experiences with Exurbo. Not the technical details of how you write software and stuff like that, but how you actually grow a community, make sure that it's the right people joining your community,

and how to make efficient use of communities. Besides Exurbo, I'm also quite involved in doing a big open source conference next month in Copenhagen, Denmark. I'm a long-time Freenode IRC staffer, helping with setting up new servers,

helping people with lost passwords, and all kinds of stuff like that. So I have a lot of experience with communities from different angles. And this little friendly guy here is ZebraPik, Exurbo's mascot,

which is also meant as a bit of a community thing, because Exurbo as a Linux distribution is fairly heavy in the technical direction, in that we actually spend a ton of time

on quality assurance, testing stuff, and so on. So quite often the discussions could get very technical, and perhaps very dry, and they could also drag out for ages. So we need something fun and light-hearted, and ZebraPik is, well, not very serious. So that fits the role perfectly.

So the things I'm going to talk about is, first of all, what do I mean when I say effective community management? Because effective community management is what I'm going to talk

about. I want you to, as members of various open source projects, to get as much from the communities as you can. I want people to join the communities, get as much from the projects as they can, and I even want plain users that don't contribute to the projects to know how to approach projects when they have problems, they have bugs, and so on. Because

many of the same techniques can be used from all three sides of this equation. And then I'm going to talk about what you're actually getting from the community. I'm going into some numbers from the Xurbo project. How successful have I actually been with whatever it is I'm doing

with the Xurbo community? And yeah, finally, how can users manipulate open source developers? I've done this talk before about 18 months ago at a conference in the US, and back then I actually

had a second title slide called Social Engineering, because this is what it is about. You want to actually make people do something useful for you, and you want to make sure that you're doing something useful for them. So you want to make sure that all the social

interactions are going in the right direction. So it's a positive way of social engineering in many ways. So what you have to do, first of all, is you have to figure out what do I want from my community. There's a ton of things you might want from a community. If you talk to a lot

of open source developers, they are going to tell you that, yeah, I want a big community, and that's it. That's all they are going to say, which is a bit useless, because a big community with no direction just means a lot of random people going on with a lot of

random questions, a lot of random feature requests going in all kinds of different directions, and you're going to end up with a lot of chaos if you don't try to control this a bit.

So you need to think about your goals. It's your project, and you need a bit of help, because which open source project couldn't use a few more hands? But you need to figure out with yourself what kind of help is it that I'm looking for. You might look for translators of documentation. You might be looking for people who can help market your project better.

You might be looking for people that can write very technical patches for your project and so on. So you need to figure out exactly what kind of people is it that you're looking for, what do you want them to do, and also why you want them to do this. You need to make that very

clear to yourself before thinking about anything else. Then the second part of this is that you need to understand what people that are coming to your community and want to join

your community, what do they want from you? This is very, very important, possibly more important than what you want from them. And the reason it's so important is that if you don't give them something they can use and something that they are going to value,

they are going to contribute maybe one patch and then run away to the next project. So they are not staying contributors. And it turns out in many projects it's really, really easy giving them something worthwhile. But the fun thing is figuring out what it is they

want because many times if you ask new people coming to your project, okay, so what would you like to get from the project? They say, hey, I just want to contribute or I just want to make it a better project. And nobody actually knows what that means. So for an example,

most of the people coming to me is young people that just started at university. So the things I can give them is I can give them some experience writing code, writing documentation, testing software and so on. Experience that they can really use at the

university from a real world project with real world demands on them. They can also write this on their resume when they are looking for jobs. And many people do get jobs because of their

open source contributions. So I need to make sure that these people actually know that this is what you're getting from me. I'm going to help you with your patches and stuff. I'm going to help review the patches. I'm going to help push your patches. That's annoying.

So I make sure that I'm very explicit about telling people that this is what you get from me. And this actually helps people stay around for the project because I make sure that it's fun participating in the project. I make sure I can't give them any money. I don't have

any money to give. So I can't just pay people to contribute. But I make sure that they are getting some other kind of currency that they can use in other projects. I also make sure that they get some recognition because I remember being a new developer in the open

source world. And what happens when you're completely new, haven't worked on any project is that you make a lot of patches and nobody listens to you. And the reason they don't listen to you is that you don't really have any trust. You haven't shown all these developers that you can actually make good patches, patches that are useful, patches that don't need

500 corrections before they can go into the project, and so on. So I'm going to help these new people that's coming into my project. I'm going to help them get a few commits, get their name out there, so they can gain a bit of trust from other open source developers,

which in turn makes it a lot easier for them to contribute the next patches, even if they go to another project, they can still point at, hey, look at that Git server. There's five patches from me. They were accepted. This is word a lot to people, but new people or people new to open source doesn't really know this because nobody is

going to tell them this. And it's not something you read in Linux documentation or anything. It's knows by heart, but we're not very good at telling new people this. So please try to be

good about this. Make sure people know this because a lot of people really want to contribute to your projects. Yeah, and finally, if you can answer the questions about what your goals are

with the community, what you want from the community, and what the community wants from your project, it should in theory at least be fairly easy to come up with some idea where both parties can reach their goals. And yeah, in Xurbo's case, I want help with basically

everything because it's a fairly small project. We are not particularly good at writing documentations for non-technical users, for example. So if somebody asked me, hey,

can I help with documentation? I don't really know Xurbo. I don't really know that much about Linux. I'm going to say, yes, of course you can. I actually do need documentation for beginners and so on, and I'm going to help you with this. So I'm going to set out a few directions for this user and just let him do what it is he wants to do. And then he can come

back to me and say, hey, I wrote these five lines or whatever, and I take a look at them and see if they fit into the project and help him improve it a bit. And this is actually exactly what happened when the installation guide for Xurbo was written a few years back, and also our initial fact. What happened was I wanted some new people,

somebody outside the project, to contribute some user-level documentation because at that point we had absolutely no documentation pointed at users. So I wrote a blog post about this and said,

hey, I would love somebody to help contribute some user-oriented documentation for my project, and I'm going to help you. And the next day or something, I got an email from some guy that I'd never heard of saying, hey, I would kind of like to help writing an installation guide. That would be interesting, but I've never installed Xurbo. I don't really know the

project and so on, and he was very insecure in his first email. So I wrote back saying, yeah, not a problem, I'm going to help you write the installation manual and we'll figure it out. And after a few mails, he actually started writing this installation guide,

he started writing a fact, and after 20 emails back and forth, something like that, he had an installation guide for me, and he had a fact that I completely disagreed with. And that happens. It's all right. It's not a problem. The point here is not whether I agreed

with the fact or not. It's not the quality of the installation guide either. The point here is that I had a new member of my community, of the Xurbo community, that was very, very happy to contribute stuff. And he was contributing stuff, some important stuff, really. And

the second point is that before he contributed the installation guide and the fact, I didn't have an installation guide, I didn't have a fact. So of course what I did was I quickly pushed his stuff to the website, even though I disagreed with some of the parts and some of the parts wasn't at the quality I wanted. But he had now written this documentation,

so I wanted his name in the Git blog. And the point is that other new people, other people coming into the community could now start improving on these documents. So it was a way of giving him something back and giving him some respect, saying,

hey, you're good enough for the project. I want your name out there. You're going to be part of this project, just like all the existing developers. But it was also a way of getting some reasonably easy work to do for other new people, which is important. Because new people aren't

going to come into your project and you want to have some fairly easy jobs for them. It might just be fixing typos on the website or whatever. You want something that some people completely new to open source can actually do in a recent time frame without having to give up.

So I have a lot of small bugs in the Xurbo, bugs that really doesn't matter, bugs that have been there for six or eight months, like some typo on the website or whatever. I'm not going to fix these small bugs that doesn't matter to our users. And the reason is,

if I fixed all these bugs, partly I would be bored out of my skull doing this, because it's really, really boring work. If you already have 30,000 commits in the open source world behind you, you don't really want to fix typos that doesn't matter. You want some technical work that can challenge you a bit and where your resources are better spent.

So keep small bugs that doesn't matter to new people so they have something to work on. They are going to be very, very excited about this. Hey, I fixed the bug in Xurbo just like the real developers, right? And I got my name on the list among all the other developers.

So it's important to have some easy task for people to do. And they might spend an eternity doing it. A simple typo on the website, even though it's just cloning the git repository and fixing the typo with an editor and doing the commit and stuff, it's really, really easy for me. But it might take this new guy six hours,

even though I'm helping him and feeding the commands to him. And I might even end up actually telling him exactly what to do, exactly what to do in his editor and so on. So I'm doing all the work. I'm still going to let him get the credit for it, get the commit, because it doesn't matter to me if I get the commit or not.

It really doesn't matter, because I have so many commits. So there's this kind of social data in the open source community, where you start at the bottom, then you get a few commits. So you get a bit more respect from other open source developers. And as you get more and more commits,

work on more projects, you get more and more respect from other developers in the open source world. And it gets easier and easier getting commits into other projects, because now we're sort of knowing you. Even if you contact a completely new project, they can look you up and say, hey, this guy actually did a talk at FASTM or whatever it is. So they can quickly

see that I made a lot of contributions, so they should probably trust me. So I want to help these new people. Even if I'm doing the entire commit, basically, I want them to have the commit. It should be their name on the commit, because it matters a lot to them,

and it doesn't matter to me. I mean, if you have 10,000 commits or 10,001 commits, nobody cares. So make sure that new people get all the credit they can, even if you think it's not exactly deserved, because it helps them also come up with the next commit. They get a bit more

secure about the way things work and so on. And you need to make it clear what you expect from the community members, of course. And at least in the Xerbo project, we decided from

the beginning that everybody using Xerbo Linux should also be an active contributor or developer. So we don't really make a distinction in Xerbo. We do make it clear to new people that we do expect you to take part in the project in some way. It doesn't have to be patches.

It can be all kinds of things. It can't just be helping other users with problems they already know the solution to or something, but we do expect people to take part of the project,

which helps remove the difference that's often present between developers and users. Where developers are, hey, I'm a developer. I'm so awesome. And hey, you're a user, so I don't want to talk to you. It does help remove that barrier. And then it's important because you need to decide for yourself how much time do you want

to spend on the community because you can spend all your time on new community members and helping them and so on. And some people you will have to spend just 30 minutes helping before he's going to do some work on his own and others you can tell very quickly that you're

going to spend the next month doing nothing else but talking to this guy just to get him to be a member of your project. So you need to decide is this worded for you. And some users, some new people showing up in the Xherbo Linux channel, it's been very obvious to me that

Xherbo Linux wasn't for them because they weren't ready to participate in the project. All they wanted was spoon feeding. Some of them wanted me to read aloud man pages for them basically, and that's not what the Xherbo project is about at all.

So decide if it's worth your time and if it's not, find some other project that the user will be happy with. So I've sent a lot of users to Bunzel Linux for example which is completely different from Xherbo but which makes those users a lot happier because they wouldn't be happy with Xherbo and we probably wouldn't be happy having them around either because they would

be sucking up a lot of our time that we feel we can use better at least. And yeah, when you have a clear idea what you want from users and what they want from you,

you can definitely find some way of making these goals meet each other. And as I said, yeah, help people with criminal bug fixes and stuff. Make sure to credit people.

It's the only currency we really have in open source. I know there's a lot of people getting paid by IBM and stuff but for most of us we don't get paid by companies to work on open source. So the only real currency we have is credit in Gitlocks and so on. So make sure that people

get this credit otherwise they're going to run away from your project saying that was a waste of time. They didn't even want to thank me. And then listen to people's ideas. I sometimes have people come to me wanting to do some patch or I'm asking them to do some patch that I think this

is going to be an easy patch. You can do it. You don't really have any experience with open source development but you can do this. And then they start working on it and they come up with a patch where I think oh god no, not that patch. It's completely wrong and it's going to

destroy my project. So what I do in those cases is not tell them hey this is completely wrong and you're a moron for doing this patch. Of course not because that would be chasing people away. So what I'm doing instead is taking advantage of the fact that I have a lot of experience with the project. I'm even the founder of the project and they are new to the project. So

what I'm going to do is tell them hey that's an interesting way to solve this problem. I hadn't thought of that. My idea of how it could be solved is this and they are going to do it my way. Of course they are going to listen to the founder of the project and do it that way

even though I haven't told them their way was wrong. So they are going to do it the right way after all and they are not going to feel like I rejected their patch because I really didn't. And if they are going to insist on their patch unless it's something that breaks something really important I'm probably going to push it anyway and let somebody else

clean it up because then I have another guy participating in my project. And then I find it fairly important to be open about what you do. So the reason I'm doing this talk really is

telling people both so you can get some ideas of how you can manage communities but also so the people that are already members of the Xable community will know why I do the things I do, how it helps them, how it helps the project. I've been blogging about this. I've been

telling users directly in our IC channel that yeah I'm trying to manipulate you to do the stuff I want to and I'm doing it because of this and because of that. And they are very very happy about this approach. They are quite happy to know how the project is managed and many of them are quite

interested and they might have interesting ideas that you can use as well. So talk openly about it. It's open source. It's not supposed to be closed. It's not supposed to be any secret, right? And some numbers. Xable was announced in May 2008 and by that time I had been working on it

for I guess seven or eight months in private after leaving Gentoo Linux. The reason it was announced at that point wasn't that it was ready for users because

it really wasn't. And even though I was using Xable myself because I had to so I could continue development on it, I really really hated it at that point because at that point, because I wrote Xable from scratch completely, at that point I was basically able to boot into a bash shell. And that's it. So I could boot into a bash shell and then I

could reboot basically. So it wasn't ready for users at all. But there was some interesting ideas in Xable, some ideas that might interest other distribution developers at that point. And what happened was that one of my friends that knew about the project already, he was

organizing an open source conference and asked me, hey do you want to do a talk about it? So I was quite kind of forced into announcing the project at that point, which was kind of fun because the way I announced it was just on my private blog that

I don't know, 20 people read or something like that. And as I said, it was supposed to be taken as just a few ideas that other distribution developers might think about or something. So what happened was that an hour after announcing it on my blog, it hit the front page of

Slashdot and it hit the front page of the register and several other big IT news sites, which of course created a lot of backslash because I wasn't ready for this and nobody in the project at that point was ready for this. Our web server did survive because it was all static HTML basically telling people to fog off at that point, which was for their own best

because we were still, development was going very very fast at that point. We were changing major features of Exurb0 basically every day. Most of these changes, most of these major changes

required a complete reinstall of Exurb0. So imagine getting a lot of users saying, hey I want to use your distribution, sounds interesting right? We didn't have time for that so we kindly told people that you need to wait at least a year before even considering that because we're nowhere near that state. But it's fairly stable these days. We have most of the

packages that people expect. We have KDE and GNOME and all that stuff, all the desktop stuff. We have lots of server stuff and so on. And the community have been growing

to me at least at a fairly rapid pace because I don't want the community for Exurb0 to grow too quickly because then I can't control the direction it's going in. I like to talk to all the new people personally and make sure that they understand the philosophies and stuff behind

Exurb0 and how to contribute patches and what we expect from them and so on. So I haven't and just let it grow slowly. But for a long time we got at least five new contributors every month and these were staying contributors. They kept contributing to the project and very few

people have actually left the project even four years later. And compared to gentle Linux which

is probably the project closest to Exurb0, I think we're doing quite well. Gentoo might have talked but still they do have a lot more people in their IRC channel. Those people don't really contribute anything to the project. They do have more developers and

a ton of these developers make a patch every two months to avoid their rule that's saying that if you don't do that you get retired. So to keep the Gentoo org address they do some small commit. At least that's the way it seems to me. So it might be more like 125 actually active

developers on the Gentoo project which is still a lot. And I'm not saying that Gentoo is doing bad or anything like that. They're doing quite well just as well as many other big projects. I just think they could do a lot better and so could other projects.

And they don't seem to gain a lot of new developers either. One of the problems, one of the big problems of Gentoo is that if you contribute a patch, first of all it's going to stagnate on their boxzilla installation for eight months or something which is fairly typical

of big projects. And when you finally get your patch committed to their packages or whatever they are going to mention your name in a change log that nobody reads. It's not your name on the commit which is important because how are the open source projects going to find out

your contributions if your name isn't on any commits. Your name might be mentioned in a few change logs if the one committing the patch actually remembered to mention you there. So people don't get a lot in return from contributing to Gentoo which is

mostly because they use an antiquated source code management system called CVS. Don't use that because it's impossible with CVS and systems like that to actually get the right name on the patch when you make the commit. Use something more modern where you

can actually not just get a patch from somebody but get an actual commit from somebody and just push that commit. It's so easy these days to do that. And the third thing I want to cover is

if you're just a normal user, if you don't want to contribute or anything you want to be a user there's some piece of software that you want to use and you experience a problem. What do you do? Well most people might actually submit a bug report and then everybody ignores the

bug report, right? You probably all experience that or know of people who have experienced it. So what you need to do as a user is try to understand the people you're talking to, the developers that you actually want to help you fix whatever problem it is.

It might just be that you're misunderstanding how to use the software. It might be an actual bug or whatever but you want somebody on the other end to help you figure this out and fix the bug if needed and so on. If you actually know what drives the developers in the other end

you might be able to make it interesting to them. You might be able to actually make your problem interesting to the people in the other end. And you need to understand that open source developers like myself, most of the time we don't do this for money. So you can't pay me to fix some boring bug.

That's not going to work. I have another job paying me to do boring work. I don't want a second one. So I want to work on open source because it interests me and because it's fun and because I learn some stuff from it. So make your bug interesting to me. That's very important

and there's really no difference between open source developer and bike enthusiasts or whatever spending all their time during all the weekends in the garage doing stuff on their bikes and whatever. They have a hobby and they are very very interested in this and if you go to some

bike enthusiasts and say hey could you help wash my bike? They're going to tell you to fuck off because it's not interesting to them. If you come with some technical problem saying oh the gears don't work quite as well as I thought or I have this problem with the brakes or something. They're going to start talking about brakes and different kinds of brakes for

the next five hours because it's interesting to them. And it's the same way with open source developers. You need to make it interesting to them so they don't ignore your bug because they have five thousand bucks open already and their to-do list starts with the interesting box. That's how it works. So don't go tell open source developers

something like wireless networking is poor with your application. First of all it doesn't describe the problem at all. The developer at the other end don't know what you're trying to do or anything. You need a lot more information but it's also really really boring. Who cares if somebody I

don't know has poor wi-fi reception. I mean not my problem right? But you could instead submit a bug saying hey I love your application it's just what I need and I'm trying to use it in this specific configuration at the school or whatever. But sometimes I've experienced this

problem that I can't really explain where wi-fi connectivity suddenly drops and then it comes back a bit later or whatever. Am I doing something wrong or is it an actual problem? Now the developer at the other end might actually start thinking about this because

you've described it as a bit of a puzzle. And we like puzzles. Open source developers love puzzles. So if you can express it as a kind of puzzle or some other way make it interesting to me I'm going to look at your bug. No problem. I'm going to spend the hours looking at your bug. And if you manage to make it really interesting to me I might not

only fix the actual bug in the application I might give you some pointers about how to configure the application better. So you get even more from it not just fixed your bug but actually improve your usage of whatever application it is. And as an example of a really bad bug report this is an

actual example from years ago to the PHP project somebody couldn't actually get PHP running on his web server and he thought hey I'm going to tell the assholes that it doesn't work.

So he started out very well and it actually got worse and then he ended up saying thanks and fuck you sincerely. That bug actually got attention from the developers but not the attention he was looking for right. So he actually got an answer very very quickly

but nobody actually helped him and it's an amazing bug. You can google it if you want to. There's a lot more to it and it actually it did get a lot worse and he was shouting in caps and all kinds of shit there's like five paragraphs that I left out or something.

So it is an amazing bug and he even ends saying that hey I'm not going to use PHP I'm going to use this other product so yeah so why are you telling us this? And that's the response he got. So I wanted to send you a unicorn and a rainbow by way of

apology but realized you wouldn't be able to sign for it because your head is stuck so far inside your ass. See this is the typical response you get when you submit really really bad bug reports and you deserve it. That's the worst part of it and there's a lot of bug reports like this and there's a lot of bug reports like this coming from open source developers

which is beyond belief but they can be just as bad. An example of a really good kind of bug report is Conclivers a few years back. He returned to schedule development for the kernel and he created this new BFS scheduler that he thought was really really good. So he

writes to the Linux kernel mailing list, describes it in great details, backs it up with a few benchmarks that he's made on different systems and it looks really really nice and stuff and it performs a lot better than the existing schedulers. This is something that the Linux kernel mailing

list is highly interested in so he managed to make this really really interesting to them and tons of kernel developers started doing benchmarks and started criticizing his design and and so on. So for the next month or two or however long there was like 50 kernel developers

at least working on this project day and night. So that's how you want to do it, make it interesting to the people that you're actually contacting about it. Make sure your goals are clear and have some easy bugs or things to fix for new people.

There's a huge untapped potential in Trivialbox. Trivialbox, leave them alone because they are key to getting new contributors to your project. Of course if this boxlet

actually matters to users, please fix them. But a lot of Trivialbox really don't matter. So and make sure you have a few ground rules. An example we decided from the beginning that it needs to be really really really easy to contribute to the project. So for example our website, everybody can contribute to our

website. It's written in markdown, it's in a git repository, you just make a commit. You don't need to know HTML and CSS and all kinds of stuff like that. So we have a format that's very close to clear text so everybody can contribute to that for example. And then have some

good processes to control this. What we do in Xherbo is that we have on IRC we have a patch spot where you queue up patches so we don't forget patches, but also so that we can review

patches. And just as important, other random users can review patches as well and they do this. It's not just the core developers that actually have git push access, it's everybody reviewing patches. This works. And make sure that we only push stuff that really looks like it's supposed to work. Sometimes mistakes happen of course, but we base it on rules and not technical means.

So the rule is queue up your patch in the patch, but somebody looks at it, reviews it, helps you fix the patch and so on. And for the same reason we banned wikis from the beginning

because you lack the review process in wikis. Yeah you can review stuff that's already committed to the wiki, but we really want to review it before. And finally this is a page from our website. A lot of people didn't really understand what we expected from them.

And what the project expects from new people, from users, from community members is just as important as describing the other way around. So I simply wrote a page about this saying hey

this is what we expect from you. We expect you to take part of the development some way, doesn't have to be technical or anything, but please take part in the project. And there's a few other rules. And it turns out that people are really really happy about this. And it's cleared up a lot of misunderstandings. So don't be afraid of telling people what you expect from them.

They want to know. So that's it. Any questions? One last thing that I forgot to mention. Oh.

Thank you for the talk. Just a quick question. Do you have any problems with bike shedding

from your community? Sorry? Do you have any problems with bike shedding from your community? Because everyone can commit and everyone can review. No. No that actually works quite well. So people really want to contribute and they want to do commits and stuff. And we make it a rule

as far as possible that when somebody queues up a patch it needs to be reviewed quickly, which is in most cases we strive for. It's gotten worse as the project has grown unfortunately. But we do strive to review patches within say a day or so. So people get fairly quick feedback

on their patches unlike most other projects. So that works out fairly well. In the beginning everybody pretty much got feedback on their patches within 12 hours, which is compared to other

projects quite impressive. But we, as I said, we do make that a rule because people are going to run away again if they don't get any feedback from us. And it's particularly important because a question I sometimes get is how do you attract experienced developers to your project?

And the obvious answer is that I don't. I don't try to. I don't even try to attract experienced developers. If some experienced developer come to my project on their own and say hey this is an interesting project I want to participate that's fine. But I could spend two years chasing

some experienced guy because the reason he's experienced is that he's very busy working on other projects already. So I'm going after new inexperienced people and there's an interesting point to that, or several if you want. One is that the inexperienced people can take care of

all the trivial bugs that I don't really want to work on myself anyway. And the other point is that unlike experienced developers they don't have a lot of ideas of the direction the project is supposed to take. So I can tell them we're going in this direction you have to follow

this direction and they actually do that. Whereas experienced developers is probably going to tell me I have this awesome idea and then goes off in some completely random direction that I might not want to. How indispensable are you to the community? If you go away for like

six months will it grind to a halt or go on? How important are you yourself personally? I don't quite get it. Can you take a holiday from the project and what happens then? Yeah, right now I'm not very involved in the project because of other priorities like

organizing this conference in Copenhagen for example that takes all my time. But it turns out that the project continues just as well without me because I've spent quite a lot of time making sure that the other developers on the project knows the direction I want to. They know the philosophies of the project and so on.

They are well aware of where I want the project to go. They are well aware of why we should be looking at completely new people, why we should help them and so on. So if I go away from the project which could happen, I don't know, I don't want to but it

could happen. It's going to continue just as I left it. I'm quite certain of that and from the beginning I've even made it very clear to people that it's important that I can leave the project because someday I probably will leave the project as my priorities change.

So one of the things I've been telling people in the project from the beginning is that one of the wonderful things about a dictatorship which is in some ways me being the sole leader of the project is that to make big changes you only need to shoot one guy. It's very, very easy.

I mean just shoot me and I'm gone and somebody else can take over. And if people want to kick me off the project that's not a problem because I can just fork it or something, start another interesting project to me. It's fine really. Do you actually take the decisions on where the

project is going or is this a community-based process? Because as of now I'm thinking that you take all the decisions and my question is that right? Do you really have the right to take the decision because you're sharing your code as well as your thoughts? Why should you take the decisions?

I try not to take decisions. What happens is that I let other people take decisions because from the beginning I made sure that all the people closely involved with the project also closely shared my ideas of the project. So we don't really, we all agree on the direction

that it needs to take. Sometimes people are a bit unsure if I would think something is a good idea or not and then they ask me. But in general I'm quite happy with other people making large decisions for the project. But why is this no community process?

Why don't you make it a big community process? Because I personally think this should be more sort of a community process than taking, let's say five or six people take a decision. Do you want to reduce the bike shed somewhere else or what is the initial, what is the goal?

It is a community process in many ways because I don't really see that much difference between users and developers. They are all participating in the project and everybody can have good ideas. So if somebody that's not really a developer or anything has a great idea that we

should switch to another web server or whatever, I'm going to listen to it just as if it was somebody else. It doesn't matter to me. So community members can make big changes and sometimes they do. Not a problem. Thank you.