 Yeah, thanks for coming back after lunch to my talk. It was a pleasure to be here last year talking about Icinga, so today I don't talk about the technical parts of Icinga, more about the community culture building into the team. For the people who don't know me, my name is Bandag, I'm one of the co-founders of the Icinga project, and I work for NetWaste, and you can find me on Twitter using GetHash. So Icinga is an open source monitoring, and to get a little bit of an idea, who knows what Icinga is? Okay, a bunch of people, and who uses Icinga for monitoring? So we have to increase that number, but looks good so far. So Icinga is an open source monitoring tool, we have our history in the fog of Nagus, since about August 2014. We have our independent code base named Icinga too. Icinga is a tool which monitors your servers, your services, your infrastructure in a regular interval, like for example every five minutes, bring back the result and the performance data for generating metrics and reports, and it should be absolutely your favorite tool for open source monitoring, because otherwise it would be a really sad thing for me. So please use Icinga, make me happy. We have a partner here in India named Olien Data, so you can find them over here, Chamshita Walter, if you want to talk to them or to me after the talk, you're very welcome. So Icinga, we started as a community project, we forked the code with about seven people this time, so right now we are a couple of more people, like in every open source project, some of them are more active, some of them are less active, depends on their private life and the time they have at work. But probably the initial idea of Icinga came out also in a small community to say, okay, we have to do something, because we want to have more progress and we want to see a roadmap, and that was an important thing for a group of people to start something. But the question is what is a community? So I would like to start a little bit of an introduction of what a community model could be or is. So in the end, a community social unit is a group of any size will share common value. So any size, you can discuss if two people are already a community, but I think if a certain people comes into the race, then making decisions could be more interesting because then you have different rights to vote for something. But a major thing for communities that they have a common interest in something, whatever it is. Another important thing is that communities are not controlled by people somewhere or not by the leaders. They are controlled by the people creating the community. So we always have community leaders in some way. I come to that later in the presentation that they try to take care of the community and take care of the people and the unified value. But in general, a community, and this is special to it, is controlled by the people in it because they decide what they can bring in, what they can do, what time they would like to bring into the project. And it's really important to understand in the open source world that a community is mainly driven by the people in that community. Another interesting thing is that communities look very different from inside and the outside. So the best example for this are political parties because to the outside perhaps they have a unified opinion on a specific thing, but inside they fight hard for it. And at the same with open source or other projects that sometimes what you see to the outlet that you have a common roadmap and common thoughts of it doesn't mean that all people share the same idea or have the same mindset about how they solve specific issues. What is the sense of a community? So a big thing is valuable membership. So for people participating in a community, they want to be valuable. They want to be recognized in that community. They want to have a real influence. And real influences depends absolutely on the perspective, on the values and the knowledge you can bring in because for a code it could be coding, but if somebody is not able to do some coding stuff, also in our community it's important for them to help with the documentation or translation. So people have different values, but for them it's important to bring them in. Integration and fulfillment means you have to take care of them and you also need to recognize what's important for every individual member in your community because there's a big difference between what people sometimes also would like to do and what they can do and this is a big thing. So how is a community created? So one thing is like, say hello, I'm here. Would you like to party with me? Then you have a kind of a community. Nowadays it's like, get in it. Sometimes a community starts. If you're a little bit lazy, you do a git clone and then perhaps it starts at this point because you have a great idea and think, OK, I would like to share my idea with others. And then people join you perhaps in the days of git, making a pool request, participate in your project and then at some point you recognize that your project dies, not dies, until the last user dies. So if you have a couple of users participating and interested in the project, they start yelling and start, I need something, I need feature ABC. But creating a community could be really a git in it. So starting a project, sharing it with others, and people come into it and say, that's interesting. I'm looking for that for such a long time. And this could be an interesting thing. For I think it was something we planned for two or three months at this time to say, OK, we would like to fork a project. And then we had something like a press release. We had our initial blog post that we do it. And that was the start of the project. Though the general value we all had and the general idea we all had is that we love Nagios. And we still love that concept Nagios had, but we were not happy with the progress and the roadmap and the features Nagios bring. And that was the idea, let's fork it. Because we had the feeling that the community uses some tool other than Nagios, for example, OpenNMS Subbix, whatever. But we liked the general value. We liked the idea using plugins. And that was the reason why we forked it. And so I don't know, around Easter, in 2009, we decided, let's do it. Then we prepared about eight weeks to have the website ready. It crashed after five minutes. So we didn't have autoscaling at this time. So we put it online. We released the press thing. And after five minutes, everything was down. Because so many people were looking on the website. But at this time, their community building happens. And we recognized it from day one. So after we announced it, that we have a fork. We didn't have any software. We just announced that the first release will be ready in the next weeks. At this point, the community started. So people were waiting for it. And people were really suffering and said, OK, I would like to go with you. And at this point, the community really grows massively instead and really happy about it. So that community building process could be split up in four things. So there are four stages of building a community. The first thing is you come together and everything is super great. Like you met your boyfriend or girlfriend for the first time. Don't see the negatives. Everything is shiny. So I hope for you there are no negatives. But in real life, sometimes there are. So everything is shiny. And that's always in the community. Everybody is enthusiastic. Let's do it. And let's do it after a week. They don't have time to do something. So but this is always the first step, creating a community that everybody is so enthusiastic. Like on the first date, I think it's the best way to describe it because nothing is better than the first date. Oh, OK, that's the wrong thing. Could be, could be. OK, it's up to you. Depends on your relationship. After a couple of times, then growing demands come up. So people in the team, in the community, say, I'm not happy with my role. I would like to do that. Or I'm not happy with the direction, the community. In this case, our approach, it goes. So it doesn't take such a long time after it gets also tricky. And people are unhappy with the specific things you decide. And this is probably the kind of a phase where it comes down to reality, where after that first emotional high, everything is super fancy, comes to OK, we have issues as well. We have the same problems like others. We have to deal with it. And the search date is acknowledged in these weakness. It means after the tie and the down, you come to a point where it's OK. Also in our project, we would like to make everything better. Or in our team, we would like to make everything better and faster. We have the same weaknesses. So we have issues. We have different opinions. And there comes a point where you acknowledge them and accept that this is the case. And at the end, it ended up in stage number four, where you respect each other. We have empathy and understand also weaknesses from the other team members. This is something like a broad process. There's no specific time that takes. I would say in our team, it took about, I would say, nine months. So after nine months, we came to the point that also a couple of people who started to forget this point said, I'm not happy what we are doing. And they dropped out. But after nine months, we came to a point that the core people really know what we want. And we had a strong relation together. And this was an interesting time for us in the first nine months. So what is important if you work in a community? So if you want to participate in a community as a member. So the first thing, you have to realize that everyone is a member of a community. So independent what he does, what role he has in the community, but everyone should be important in some way, should be valuable for some way. And you have to realize that also people, perhaps, make a decision, perhaps against your opinion, equal members to each other. An important thing is that you disagree with ideas and not with the people. So if you have a feeling that some ideas are wrong or not good for the project, it's always important that you be clear to that, that you communicate it in a proper way, but never disagree with people or harass them. So disagree with the idea and say, I'm not happy with it. I would like to do something else. But this is a really important thing. Another thing if you're important, always try to bring new members to your community because it has two arguments for that. One thing is you will die someday. And another argument is you will be assimilated by the ideas of your community because sometimes you will share the same values, but on the other, it's like seeing the tree in a forest. I don't know if that works in English, but it's sometimes hard to get out of it. So because it assimilates you and you only have the view of the community, and sometimes it's also hard for new people to see it in a different way. So it's very important for a living community that there are always new people because also people believe because they have a girlfriend or boyfriend and they are not allowed to sit on the computer the whole night or the whole weekend, and they will don't do work anymore. And this is reality. So take care that new people are coming to your community, to your team, to your project all the time. It means take care of the next generation and also accept that the next generation, perhaps, is not super good and super skilled in everything you need and give them a chance to find their position in your community. As a member, also be flexible as possible. So try to do work where it's necessary. Not say, OK, I'm only coding C++. I don't give a shit about the PHP website. So really say, OK, we have an issue as a project. And if we have an excellent core, but we fail in the web interface, we have an issue. So try to do everything. And stealing an idea of geek all down is like, don't be a red shirt. So you know what a red shirt is in Star Trek? It's a walking dead. So the red shirt people never come back to the airship. They wish it would be valuable, be a blue shirt or a yellow shirt. Does it make sense? Hopefully, if you are a Star Wars fan, sorry about that, but I had the order already. So I tried to have everything for both communities. So means be valuable, be visible in your community, be important, and care of an important part that you can bring value into that project. Working in a community as a lead. And I remember I said there's no control through a lead. Anyway, we have people that have to take care of a community. They have to take care of the processes, have to take care of the technical tools. But I think the most important role for something leading a community is maintenance the balance between the strong and the weak. And because there's always, if you have more than 10 people, you come to the point where you have the strong and the weak. And typically, the strong people are the loudest and the weak people, you can hear them. And this is very important to also give the people who are not yelling so loud and not complaining so loud and not writing 100-line emails to hear them, to figure out what they want, what their ideas are, because sometimes they are much more important than the loud ideas. So I think for me, this is the most important thing. If you're taking care of a community, that you really hear everyone. And you also hear that people, which typically, perhaps, not yell at you and complaining about everything. Take care of the internal culture. Means, as a project, automatically, or a community, you automatically develop some kind of a culture, how you treat new people, how you work with issues, how you work with unhappy people, how you deal with criticism, all these things. You have to develop your own culture of community, but it's important to take care of it. Whatever it is, so hopefully it's a good culture and you should try to do anything, that's a good culture, but you have to maintain it all the time that it stays probably equal. Especially the project grows, more people coming up. Distribution is a big issue, so if different people from different places, you're just working on the same thing, it's really a challenge. I'm taking care of the internal culture. Don't be a control freak. And this is hard for me, especially, because it's a term and advantage and disadvantage that we are control freaks in some way, but this is not really good sometimes, because if you ask people every day what's going up, what's going up when we have the release, at some point they will hate you, which is understandable. So trust in people, especially if you're not a million dollar project, it's okay if you release a couple of days later. So it makes me angry, it still makes me crazy, but it's okay, nothing happens. Earth still turns around, so really don't be a control freak is a really big thing, especially I know it very much because it makes me insane, but I work on that every day with semi-good success. Community maintenance, so taking care, what you can do like maintaining a community. So there are a couple of methods that came into my mind preparing this talk. One is talk, talk, talk, talk, and of course talks. Biggest method is try to talk to everyone, which could be very, very time consuming, especially in the beginning we had, in I think we had a mumble session every week and then we had a Skype session, and the funny thing is we started the project and there were only German speaking people in phone calls, but we spoke English because we decided if we are not English in every single line from day one, we will fail as a project because we had an international approach, but it was really funny having only German people in the conference speaking English, good and bad English, so we were sometimes not able to understand each other, we could just switch back to German because it would be easier for us, so we really fight it to our self, doing everything in English. So right now nobody has to discuss about it, and you can see a big difference in that for a good examples for that are French, for a French community project, because typically a lot of French open source projects do everything in, you guess it, French, and nobody can understand them, except the French, means there are a lot of excellent open source projects in French, but nobody has a chance to work with it because you cannot read the documentation, so I think language is perhaps not a super nice invention, but it's a really important thing, if you want to be international, English is no question, and we did it from day one, and this was tough in the beginning, but it helped us a lot to grow and also integrate other people because right now we are international, we have people in a lot of countries working with us, it's an international project, but as a requirement to that is that we started everything in English. Create a transparent environment, so everybody in a team should know what's happening, I don't think that everybody outside the team should know everything, perhaps they should like to see the issues and the roadmap, but not every discussion you have internally needs to be published on the external website, so I know that not everybody shares that opinion, but in my opinion there's absolutely a right for having some private conversation, having private ideas, having private discussion, and note them, but it's absolutely necessary that all your team and your community members have access to them and see on whatever stage what is going on, see the thoughts you have in mind and the direction you're heading to. Another thing in culture and community is measure progress and note community members, means from time to time, bring people on the website, show their faces, so we have a team site, perhaps we can do better, but we have a site where you can see everyone with a short description of what he does, with a picture of him. We also welcome new team members and write a blog post to say hi, what he's doing in the project, and it's really important, it's important for the people itself because it's a value for their work if they are public on a website and can identify themselves with the project, or the other end it's important for your project if you see that they're real human beings behind that project, it's very good marketing. Sorry. So it's important to measure in some way, so technical measurement is very easy in the days of Github because you see the activity metrics, you can see who is working a lot and who is lazy, but lazy just on Github, perhaps people don't do a commit. So I have a commit at a Sengar, I would say, five every year, which is horrible, but different things. Means you cannot only measure the activity three month Github, but that's a kind of measurement, you can see what people translate, how many blog posts somebody writes, and not from a measurement, judging him, it's like you're active or not, but to show it to the other members of the community, show it to the external world, what specific people do for your project. Meet as much as you can, that's usually just a question of money because if it comes to trouble, then you produce costs, but we try to do it once a year, so now we have our Sengar camps around the globe, we are thinking of Sengar camp over here in India. That's usually a point where we try to meet with some people because nothing can replace a face-to-face meeting. I know there are a hundred of technologies out there with WebEx and Hangout and whatever, but nothing can replace sitting together on a table, having a beer, yelling on each other, love with each other, so it's the best thing to meet, and this is what we try to do as often as possible, but it's mainly it's a money problem because otherwise we would sit together, I think every two months, on the other end the production rate will go down after our events. So community maintenance, though I think you need some tooling, also work in a specific technical community like we have in Sengar, so what we have is like a ticketing system, so we started with a RedMind ticketing system for our internal development. We are not sure right now, but I think it goes in the direction that we use GitLab in the future for the software development because in some areas we had Gittorius, but Gittorius was bought by, I think, GitLab last year or something around. So this is important right now and we also have now a ticketing system for external requests because there are so many external requests coming into the project. Before we did it, we had an internal mailing list and if you wrote an email to info.iSengar.org it lands in my mailbox and I don't know, three other team members' mailbox, but there are so many issues coming into the project that we have a request tracker system only for external communication. We have a wiki, I think it's gonna die because nobody writing stuff in. We started it, I don't know, a year after we forked the Nagus thing and we used Confluence because they offer a free open source license. The problem is that most of the articles in the wiki are outdated and we focus more now on having a good documentation and now the documentation is very much complete but it's not super end user friendly so this is definitely a go for the next two or three months but everything what we provide as a functionality is documented. Sometimes we need more like easiness, how to monitor a NetApp, how to monitor Oracle, SAP, whatever. So I think the wiki will die but it helped us a lot in the first stage having a view on our protocols and our meeting result was a good place to store there. We have everything on premise so we don't use a cloud offering for any us so we sync our repository to GitHub, of course, because everybody's out there but everything we have internally, we have from day one we had our own open LDAP server which is replicated so every iSinger user if it's from the inside or the outside ends up in the same open LDAP server where we connected all the tools to it means if you, for example, would like to open an issue in iSinger you have to create a user, it's stored in our LDAP system and we use the same for everything which is something we had at this point we don't want to have our identities and security somewhere else so it was just kind of an idea that we would like to have everything on premise and right now I'm really, I'm happy that we did it at this time because we spent most of the work in preparation of our going live event in creating our internal infrastructure but we still have the same mechanisms, we're still using the same LDAP server in a new version, of course but it helped us a lot having everything under control so we use our own Git, we use our own RedMine, we use our own build infrastructure with Jenkins so everything is self-hosted and we have fully control of our platform. It's absolutely up to you if it makes sense for you guys or not but for us it was I think the best thing to do. Dealing with failures. So I mentioned we have this first date thing where everything is ha ha shiny but it doesn't take a long time that people will complain about everything so internal and external people out of the community they will complain about features not fixed, typos in the website that you don't write blog posts that program language so we had people writing C++ is wrong, use whatever so you can never win a language discussion because in somebody use FORTRAN, use COBOL, whatever now we use that because we're able to do that but people will complain about everything and you will receive that feedback on any channel so Twitter, Facebook, they write you an email I received emails on our main info editor think about why didn't you choose whatever language? I said really? So don't use it if you don't like it but you have to deal with it so this is definitely something you also have to learn that it doesn't make you angry because there is bad influence there are so many people out there that say we love what you do, we use your project and this is the best feedback if I come here and people say after your talk last year we migrated to I think it works great that's the best you can get on the other end you also have these negative and you have to accept it so you have to accept failures people make externally but also internally in your project so typically we are always late with our releases I would like to plan it on time so if it's possible I would like to say release our new major version on November the 11th but I cannot do it because it turns out that the reality is against me and people have a private life and sometimes they're ill and then we are out of our planning schedule so accepting failure is a big thing and in learning that and accepting that it's really having a culture of failure is important I may absolutely advise you to have a view on that book a couple of guys of the DevOps community especially John Willis have a couple of talks also on SlideShare talking about this book and it's about a culture of failure and this is a very important topic just to give an example what they do is for Toyota they have a specific amount of failures every day in their production area so every day something happens and if the number of reported issues goes down then for them they start to be active so they do it a different way so they start, if we get less errors reported then it looks like that people act bad things means it's a different view on failure handling since if nobody's reporting failures it could be that we are perfect but it might be more, it might be more realistic that people say I don't care this store is not closing 100% but it's okay for me and so they are hunting, they are hunting failures and they are hunting failure reports from a positive perspective this book is absolutely nice to read there are so many nice interesting point of views about failure culture about learning from each other so absolutely if you have the time read this book try to be nice as long as possible especially in social media if you are in touch with other people try to be nice it's your duty to be nice and don't harass somebody but also don't accept harassment so if you're working in a community and especially in my part sometimes I think people cross the line and it's also absolutely okay if you work for your community and if you wanna protect them to say okay this is the last area so stop it here not complaining, don't harass us so it's so you should be nice but there's the end of it and you can make it absolutely clear to somebody you're entering an area which doesn't do so so if you don't like it if you're not happy what we are doing we don't harass anyone but please don't do it as well use something else and this is important now I'm off I'm on okay it's important to learn where that line exactly is but there is one I have to figure out where is it for you but it's definitely something you should think about community rules nothing happens nowadays without a code of conduct so I don't know especially in our area where I live there was another thing last year there was a tweet coming up because of FOSTEM you know FOSTEM? it's a big development event in Belgium and somebody tweeted that and you can see there was a lot of discussion going on and then Patrick De Bois one of the DevOps community leads wrote back and there's truth in it okay so hopefully you get the sense so it's absolutely important to have a code of conduct to take care of it so it's really really important but much more important like having a code of conduct is really taking care and sometimes you go to you go somewhere and read a code of conduct it's 20 pages long nobody can understand it so sometimes it could be reduced to don't be an asshole perhaps it's not super sexy say don't be an asshole but that's it treat others like you want to be treated be nice to each other and this is so important that you take care of the others and also don't rely that the organizers will take care so you as a member of a community of a conference if you see that something is wrong take care of it and not say okay somebody else will take care or go for lunch so take care take care of others in your community take care of people to be nice to each other because the world is not pink nice lovely fancy it's not but we should do our very best that is the way it is that's it thanks very much do we have time for questions I guess yeah one thanks a lot it's a brilliant talk just a question one of the issues that we often face is as the community grows the older members of the ones who either feel left out or you know are sort of it gets hard to engage with them I don't know if you've dealt with this problem and you know what I mean what you have to say to this yeah we had we had for example we had some guy which started the project and he took care about the documentation which is a very good example at these days we we thought doing every documentation in DocBook is a good idea and now we knew it was a worst idea ever he worked into that and he invested a lot of time and then at some point we decided DocBook doesn't make us happy we switched over to Markdown and then he was really disappointed because in our community it was his thing so he was responsible he was the DocBook king of Isinga and then we killed all work and all his knowledge because we are moving to Markdown it took me a lot a lot of time I talked to him a lot I called him and at this part at some point he say okay I still like the project he still comes to events so he's out of actively contributing to the project but it took me some time to to make him to understand why we made the decision also against his knowledge but I think you cannot prevent it all the time sometimes things change and some people of your community are not happy with it but I think it's like treat them well explain them why and you can reach a point where they understand it and now we don't lost him as a member also we lost him as an active member I don't know if it makes sense but you can only talk but sometimes you make decisions which are not fit to everyone more questions some open source projects start as more like free to use for example we'll take Redis and later there will be some commercialization happening and some of the core contributors moving into the commercial organizations so I wanted to your thoughts on that and like us users also what to look into that okay so yeah commercialization of a product is a big issue because you see that a lot in open source product that it someday especially if they have financial backing from venture capital open source as a service or support model doesn't scale so then they have a dual core license or they have an enterprise model right now 90 percent of the development iSinger is done by Binetways and the money to that development comes from professional services and support we sell means there is no enterprise offering there's no subscription and there's no plan to do that because most of the community people in the iSinger project don't want that for them it's the worst having something like a dual core and so I think if we if we switch something to an enterprise iSinger and to make it clear not everything is better if you put enterprise on it most of the time it's going to be crazy so I think we will also lose a lot of our core people so right now we will our plan is to to keep it open source we are planning about having a mobile app this will be in the app store we will open source it at well perhaps we take three dollars for the app but we don't have a single line of code so it will take three years until the app will be ready but everything will be open source and there is no plan doing a dual-license enterprise version or questions okay thank you very much again thank you burned a couple of announcements the boff on databases is starting at 3 p.m downstairs uh walter hex talk is starting at 3 20 p.m on puppet in this auditorium at 3 20 p.m please fill out the feedback forms that have been given out