 First of all, thank you very much for coming to see my presentation called The Apache Way, Committed to Apache. Before I start, can I just do a quick survey? How many do we have any committers in the audience? Do we have any sort of non-coding contributors or doesn't matter if you're a committer or not? Any non-coding people? Is that one and a half? That's good. My presentation today is going to be about being involved in open source and also about enjoying what you do in open source and also recognising that not all the open source software is around code and coding and that there are non-coding contributions involved. Also maybe looking at why people contribute to open source because it seems a bit crazy really. Let me talk about my agenda today. I've split it into four sections. We've got an introduction where I've run through some definitions. I've got a section. The second section is a life at the facility. Welcome to our facility. The facility here is Apache Software Foundation. Then we're going to talk about reward life. We're going to do a summary of run through all the main points that we've talked through. Then I'll open it up for any questions and any comments. That's going to be the organisation of the talk today. Let me start. I'm going to start with some definitions because definitions are always good because they have a common understanding for people. A couple of definitions. Commitment. The use of legal means to send a person to a mental hospital in, say, an asylum or psychiatric ward. Anybody fit in that category? Another definition. A willingness to give your time and energy to something that you believe in. Your time and energy to something you believe in. You would give your time freely to create something that somebody else would use. Somebody that you don't know. You can be working with people you don't know. You'll do this for free and you'll do this quite happily. That sounds a bit strange, doesn't it? Maybe these two definitions are linked somehow. I don't know. Let's take a look at another couple of definitions. A committer. This is a term that you hear a lot in open source. I've taken a couple of definitions. One of the definitions I've taken is from Wikipedia and the other definition I've taken from the ASF site. I shortened it because there's some other things in there about having an Apache ID and all this sort of stuff. Anyway, let's take a look at them. A committer is an individual who's able to modify the source code of a particular piece of open source software. Being able to modify the source code. That's the Wikipedia definition. The Apache definition is a developer who was given right access to the code repository. Spot the link. Code. Committer's link to doing something and modify code. It also noticed that it doesn't actually mention anything about commitment. It just mentions the code. One of the things I'd like to mention here is that being a committer doesn't mean that it's a measure of your commitment. You don't have to be a committer to show any commitment. You don't have to be a committer. You can still be committed to do something. You can give your time willingly to do something and be committed. One of the things I touched on is is it all about the code? Is it only about the code? Because all the people that are involved in Apache, we willingly give our time, we willingly give our energy to do something. I do it, you do it and we do it. We think it's fine. We enjoy it. When we contribute to a project, is it only about the code? Apache, all Apache projects, are software-related ones. You tend to find that there is a big focus on the code because that's what it is about. It's about coding, generating releases. If you need to generate a release, you need to do all the work around generating that release. Fixing bugs, doing technical reviews, creating releases, coding. We mentioned that there were a few committers in this group. What do you think were the main factors of you being made a committer in your project? Do you think it was to do with your coding contributions? Justin is saying no. Localisation? OK, that's something for you. I would say that on software-oriented projects, coding does get quite a big influence because the focus is around generating release. In the corporate world, where you're generating software releases, you tend to have a team of people where you have developers, testers, business analysts, change management people, marketing people, etc. Because you're in a corporate situation, you have somebody that will specify the skills that are needed for a specific team. You have somebody that says, OK, we're generating something, so we actually need some testers. Make sure that when we're delivering this project, we have some testers available. Within Apache, it's not that straightforward because the community is quite a naturally organised one in the sense that the people that are interested just arrive. The people that just arrive may not be the full balance of what you need for your project. This is why it's interesting to see that we might be missing some of the areas where we need to deliver a project. To answer the question, is coding everything? No, coding isn't everything and I've mentioned a few of the things as well. Non-coding contributions exist and they are important. I think listening to some of the other talks on the track today, there's a lot of projects that are really looking for these non-coding contributions. So they're looking for people to help them with their user testing. They're looking for people to do some things on training, to do some things on marketing, on design, on documentation. One of the areas that I see that's quite interesting as well is around community management. What I mean by community management is around being a facilitator for the community. Where you have groups of people working on things, you may have the user group and also the development group, but also keeping the community informed about what's going on, letting them know what they can do, making sure that the information is out there for people to do things and they know what's happening. So there's a lot of tasks around non-coding that are really, really important. And I think that sometimes within Apache we struggle to fill these missing skills. So one of the things I would say is that as a project, your mailing list really is your doorway to the world and people are looking in at your project via your mailing list. People look at how you treat people, people look at how welcoming you are, and so looking at your mailing list and the way you welcome contributions and also the way you interact with each other is very, very important. So your user list, I would say, is an interesting place to look and to focus on if you're looking to try and gather contributions from non-coders because they will have a different perspective. They probably just need some interest to be able to contribute. So if your conversations on your lists are mainly development ones then there's nothing that people can add. If you have got some ideas or some requirements about what you want to do, then that actually opens a little gap or opens a door for people to say, ah, right, okay, they're looking for this skill, maybe I can help there. So this sort of thing. So I'm going to just talk a little bit about my history and referral. So my background is in generally sort of corporate projects. So I've worked on sort of international project teams where we have this organization of specialist skills. So the project sponsor comes along and we get a tester, get a marketer in person, we get a developer, we get all the full range of skills so it's not a problem. We make sure we have this and we also have quite a fixed direction in what we're doing. So this was something that, you know, a structured way, this is how I'm used to working. So I had never really had any experience in open source before. As far as I knew I hadn't used any open source project, wasn't really sort of bothered about it, didn't really understand it. And somebody came up to me one day and said, hey, you do sort of ERP stuff. Enterprise resource planning software. You do sort of ERP stuff. And I said, yeah, I do a little bit. And he said, well, okay, well, take a look at this. And I sort of said, yeah, okay, I'll have a look. And that project that they told me to look at was Apache OFPs. And I thought I went and had a look at the online demo because you can do that on the site. I logged in, played around. I thought, this is quite interesting. This looks like the sort of software that I've been implementing from corporate centre. Hold on. What is this doing here for free? Why are there people building software, spending their time and energy on software and giving it away for free? What's the catch? There must be some catch. Just trying to get people to download it and then later on they were going to charge for it. But no, it just seemed to be too good to be true. Why would people do this? And this was something that was really quite baffled me because I didn't understand the concept. I didn't understand the business model because to me it just didn't seem to make sense. It seemed a bit crazy. So I was sort of still quite interested in finding out what was happening and why people were doing this. So I decided to take a look at that ASF, take a look at the project. And I did that by looking at their mailing lists, the front door effectively. So I didn't sign up to the mailing list but I was just monitoring the mailing list. And I monitored the mailing lists for maybe about six months, six to eight months. Because this was something totally new to me. I've never seen mailing lists before. It was just a different concept. And I sort of thought, hold on, what's happening here? There are people that are really working together, doing stuff and it doesn't seem too bad. Maybe there's something I can do to help. Because I looked at the software and I thought, well, actually it seems very developer oriented and I had a bit of a functional background. I thought, all right, maybe I can help here. And I was monitoring the lists but I wasn't actually posting anything. One of the things that projects need to be aware of is that we know that they're public lists but there's a lot of people that are on those lists that are just watching. They're not interacting yet. They're deciding whether or not they will take the first step into the project or whether they will take a step back and decide, no, I'm not interested anymore. So the way that you interact on your public lists, when something goes well, when something doesn't go well, these are being watched by a lot of people, more than the people that are actually active on your lists. So you are effectively ambassadors to the world. And I thought, you know, this mailing list thing, it seems to work, I think. I need to write a bit. And all these people, and there was a lot of people on those lists and a lot of these people were non-native English speakers and they were all doing this in English. What? Why are they doing that? It's harder for them. So after six months, six to eight months, I decided, okay, right, I'll make my first post. I had built up enough confidence to make my first post so I made my first post and I started from there. But I made that first post. But I didn't understand or know about the Apache way. I didn't understand or know about community. I didn't understand or know about consensus. All I knew was there's a mailing list. I think I can help. I will post some stuff and that's all I did. So once I started posting to the lists, I was looking around to see whether or not, you know, how do we start doing stuff? Because, you know, it's who's in charge. I see the terms, you know, project management committee. And I thought, wow, this is, these are the project managers or these are the project sponsors that are pushing the project forward. That's why it's working so much. The committers, these guys are all the project managers that are working with the contributors to do all this stuff. But when I was actually in there, I started interacting with the community and posting and, well, what's next? Now, hold on, who's the boss? Hold on, but there is no boss. There isn't a corporate structure. There isn't a hierarchy of a team like you have in the corporate sense. Everybody is empowered to have a say in what happens. So there's no one in charge. But then everybody is in charge. And to me, that seemed like, well, how can anything get done? It's disorganised chaos. Nothing will ever get done, right? Wrong. One of the things that I found was that, you know, people didn't have an overall big project plan with time limits and descriptions of what deliverables they needed to do. People seemed to look at the project, look at the tasks and say, OK, this is something that needs doing. I'll do that. This is something I like doing. I'll do that. I've got an idea to do something. I'll do that. It seemed to be something that was quite natural and organic and how can that work? So it was empowering people to do what they enjoy, to do what they thought would help and to do what they thought needed doing. So it was empowering the community. And I thought, well, you know, what could I do? If I wanted to start using this model as a non-coder, what could I do? So what did I do? I thought, well, I can see that they're missing some areas around the functional side because it was some different applications and I will help doing some functional testing. Just to look at the business flows. I would look at some of the documentation and I will contribute that back. I would look at the Wiki. I would do this. I would do some testing. I would report things that are not working, et cetera. So I thought, well, I can do that. I've chosen something and I started to get very, very active on the list. And I found that people gave me access to various wikis, various confluent spaces, various... People I didn't know were trusting me to do things for the project. People that I'd never met, people that I only know from what they write, were trusting me. Why would they do that? And I was working and being quite active and I didn't realise that just doing that was actually earning me merit because I didn't understand the concept of merit. I didn't understand consensus. I didn't understand it. It was just in the project. And I realised that after a while that I was doing more and more. I was getting on more and more with the community and they were quite welcoming. They were plus one. Sharon's got an idea, plus one. I was quite independent in the sense that I could do what I wanted to do and enjoy it. And this concept of merit, and I think it's been brought up in quite a few of the presentations today, is around doing something that community values. And by showing that you're valuing non-coding contributions sends a real strong message to the rest of the community. So it's not only just code. I think it's easier to measure the code because there's patches, there's lines of code. You can look at the source code and see who's contributed to things. But other things that are non-coding, like documentation, like marketing, like testing, et cetera, they're not so quantifiable. So that could be an issue. But the key thing is that it's not just for code. So who has invisible friends? Well, I would say everybody has invisible friends. Anybody that is on the mailing list that is dealing with somebody that you have never, ever met, you sign on to a mailing list. How do you know that you're talking to such and such? Have you seen them? Have you met them? Do you know? No. You're trusting that this person that you're talking to is someone. And you know this person only by what they write. You know them by what they write. So it's a huge empowering thing in the sense that you're working with someone that has the same goals that's around the project, building some software that's going to be used by the community and by other people that we're going to give away. And you're doing it with people that you don't even know and they don't really know you, but they trust you. That is so empowering. And you find that you learn about people or you form an idea about people by the way they write and what they write. So you build your personality or a personality for them in your mind. So you do have invisible friends. I was involved with the Apache OFB as I think I started in 2008. I started my first post. And I didn't actually meet anybody in person from the community until 2014 at one of these Apache Cones, which is why Apache Cones is really quite important. And it was really amazing really because you saw the name and you thought, That's such a search. It was like meeting an old friend. It was like meeting an old family person. And even here this week I have seen the names of people that I have seen on the mailing list and I've never ever met them and I've seen them and greeted them like an old friend. And I think that is part of the Apache OFB. That's part of this community building that you realise is happening when you're on the mailing list and you're building a social network. The mailing list isn't only about talking about code and talking about what you're going to programme and what you're going to review. It's actually about social interaction. It's actually about collaboration. And this is the thing that builds the trust. This is the thing, working together towards a common goal. It is absolutely amazing. So the common room. So I call this a common room. So I mentioned before about the structure of the community and in the sense that we had, in a corporate sense, you have a hierarchy. So you have your project sponsor, senior management, you have your project team, you have your project manager, you have the people in the team and they have their deliverables that they set out to deliver. They have the project. They have a timeline. They have processes. They have the rules that they're going to do. And everything is very clear. Everything is quite laid out in form. And because you have that structure, that organised structure there and you have all the skills you need, it's not a problem. So in a community where people are free to come and go as they please, you find that in software development you tend to have a skewed distribution of developers because developers are the first people that tend to come into a project. They are the ones that are building the product. They are the ones that have the ideas about how they can do things. They are the ones that are creating the releases and making sure that the users can actually download and use this product. But from a usability side, the users may have some ideas, some input, some details that, you know, hey, we've used your software and it would be nice if or are we didn't like the look of that or are that process doesn't work too well? Because one of the things that I found being involved with Apache RFIs was that although the screens looked, had all the fields there for flows and whatever, but from a usability perspective I thought, well actually it might be nicer if it flowed this way because this seems to be more of a business flow, how a business person would use it. Or this would be more interesting, this use case would be more interesting this way because that's the standard way that people do this sort of thing. And that's the sort of input that could be quite interesting for a project because you have some ideas about how the people think it should work and then you have the information about how the users actually use it. And to bring those together is where you can add some value. And for Apache project that's where you can also bring in the people that may be not so developer oriented but more on the usability side and more on the areas where you are not so strong. So when I started looking at the community and the chaos and I thought it was informal chaos but it was fine and I found I had to adapt to working in a different way. And one of the things that I realised, one of the things that I expected actually was that there was this hierarchy, the same corporate hierarchy in Apache but there wasn't. And the titles of Committer and PMC member and ASF member was not like a promotion structure as you have in corporate, it was just a recognition of merit. And so the key thing that I found, I realised was it wasn't a hierarchy, it's a community. On the mailing list everybody is a contributor, everybody is a contributor. It's not that I'm a Committer and I'm telling you as a contributor you can't do that or I'm a PMC member and I'm telling you as a Committer you must do this. It's not that, it's not that. Everybody is a contributor. Everybody has a responsibility for the welfare of the community. Everybody has a common goal and that was the key. And this section is called escape attempts. So when you look at open source communities people leave. There are various reasons but people leave. The first reason I will talk about is the natural cycle because sometimes people will come on to a project and they naturally leave. For example I think they have students come on during Google Summer of Code or people join a project to implement some sort of functionality or they're an employer that's contributing to an open source project and they change job and they no longer contribute so they leave. So that's a very natural cycle. Other reasons that people leave is that it's not a good fit for them so maybe they are used to doing something in a particular way and they don't really want to adjust or if they do try and adjust it causes some frustration. I know that when I started with Apache the mailing list was a real big adjustment for me because I had not had that sort of interaction before but I chose to adjust. I said okay I think this is worth doing and I will do it so I adjusted to the mailing list. So this is if it's not a good fit for some people some people will want to leave. Another reason why people may want to leave open source or Apache community is around conflict where they don't get on or they have disagreements etc. And I think when you have a group of diverse people together you are guaranteed 100% guaranteed to get disagreements. There's no way around it. You'll know that everybody is not going to agree on everything. So the thing about it is that the way that you manage the disagreement will decide whether or not it becomes a battle on open warfare or a battle and if it becomes personal where people are afraid to step down from a point that they've made because they think it would reflect on their status. They think it would reflect on them personally very very badly and this is something that is really really, we need to be really really careful about if people are doing something that they have put a lot of emotion into then they can get defensive about something because they own it. They feel like this is my thing that I created and you don't understand it and I know that it's right and so it becomes an emotional thing. So we just need to be careful about this. The main thing to remember is that we want the community to endure. This is the key thing about Apache and communities, we want the community to endure into the future and I know that I may not be around in 10 years, 20 years, whatever but I would like my project or the projects that I'm involved in to be around. So therefore I need to work today to help to bring people into the project that will be there in 10 or 20 or whatever years or they will bring people in to be there in 10 or 20 years. So we want the project to exist into the future so we need to make sure that we continually look for caretakers, maintainers as a software. So I'm just going to talk quickly about some treatment plans. The two cases that I've highlighted here are around conflicts because I mentioned conflict in the previous slide. One of the things about conflict is that it's something that can escalate quite quickly and it can become quite negative sometimes if we don't resolve it and for me it's always been about trying to take the emotion out of it and trying to make sure that you understand the reasons for the conflict. If it's an idea about particular code, is it an idea about a strategy, is it an idea about being able to promote the project, what is the reasoning behind the conflict and we find that sometimes the conflict has become a conflict because it becomes personalised. If we look at the project as an entity and say right okay we're concerned with the welfare of the project we want to do the best, our very best for the project, what can we do that is the very best for the project and the question is are you doing what you're doing for you or are you doing what you're doing for the project, for the best of the project and this is where I think you can find some answers to conflict in the sense that people may need to step back and say well actually maybe I was doing that because I was too close to it, it was my personal idea and I feel that I need to defend something and maybe it wasn't in the best interest of the project and if you start from that common ground I think this is at least a stepping stone to resolving it so we're all in it together and the second area that I wanted to highlight is to where to find new companions so how do you recruit people into your project and I find for our project it's the user list, it's the user list I know that we have a lot of service companies et cetera that monitor our dev list but we have a lot of people, a lot of users that are sitting on our user list that maybe don't post or post very rarely and so trying to involve them, trying to communicate with them, trying to show them where the project is wanting to go and what we think is important this is where we can try and get some feedback from people and make sure that they're encouraged to participate so sometimes we find that people are saying hey I'd like to do something and people are encouraged to do proof of concept go away and go and do something and come back and we'll have a look at it and then people get that first positive reaction and they're motivated to go and they're energised to do something and they go away and go and do something and they come back and they come back really really quickly oh yes we've done this, here it is oh right, okay have you thought about doing this, that looks good, that looks good and then all of a sudden you find that you're pulling in various people from the community I did some stuff on that, I did some stuff on that maybe we can do something together and straight away you've got a bit of a synergy and that really really helps so this is the treatment plan so I'm going to, so if we take a look at the symptoms so I just wanted to see where you, I mean we've got quite a few people in here that are committers already but I think it would be interesting questions as well so if you're, you know, where are you, are you already involved in open source or are you still looking at it from the outside are you still not sure whether or not you want to get involved with an Apache project maybe you're a user at the moment and you're here at Apache Khan to find out a bit more about Apache and how it all works you know, are you monitoring any existing lists at the moment are you watching a community you know, are you already inside a community are you already a contributor in a community but you're not sure what you want to work on you're not sure what to do next or maybe you've found something that you want to work on or you're not sure about how to post, straight post to the list and think ah, maybe they won't want what I want you know, have you started doing things that you already enjoy and you think that will be really, really beneficial for the project or maybe, you know, you're frustrated in the project and you're finding you're conflicted and you're not sure whether or not you want to stay have you worked with the community are you realising that, you know, you have a responsibility a part of the community to look after the welfare of that project so where are you think about where you are in your open source journey so I will do my summary diagnosis so just a bit of a review, so commitment okay, we're not committed to a mental institution yet but we are giving our time and energy doing something that we believe in that's what we're doing, every day we're doing this we're helping our project by doing things that the community values this is merit, this is where you gain merit doing something the community values we also have a responsibility for looking after our community for making sure that our community will endure for looking after the code for looking after the community and the project but not only the code we also have a responsibility to our users and our developers to bring them together to create a vibrant and diverse community so I would say, you know, if you have all of these then you're definitely committed thank you for your listening so I don't know, so do I have any questions does anybody have any questions or comments even or alternative diagnoses no worries, okay thank you very much everybody