 Everyone's energy level is really low after lunch. Your screen is no longer on. Ah! Ryan told me I didn't need to change anything. Christopher Neugebauer, who is a absolutely integral part of the Australian open source communities, Python and Linux and all the things. You should all come to Hobart in January next year when he's running a small conference. It's going to be awesome. And today he's going to be telling us about how we can decide between continuity and change in open source. Let's make him feel welcome. Thank you very much for that, Katie. Yes, as Katie mentioned, my name is Chris. My Twitter handle is hidden somewhere on that slide if you wish to harass me via Twitter. You can do so if you can find my Twitter handle. Small challenge for you after lunch. Have you figured it out yet? Great. So I'm from this city here. It's Hobart, which is somewhere in the south of Australia, north of here, but south of most of Australia. I run a lot of open source conferences. Notably, I ran the two Australian PyCons in 2012 and 2013. And as a result of doing that, I was elected as a fellow of the Python Software Foundation in 2013. As Katie mentioned, I'm the organizer of LinuxConf AU 2017. So you should come to Hobart. We'll be opening ticket sales in a few weeks. And basically, I'm going to be talking about stuff that is tangentially related to my work on LCA this year. So running conferences has meant that I haven't really had a whole lot of time to write code or contribute to open source projects over the last few years. And this year, I decided one way to fix that would be to combine both of these roles into the same thing by working on an open source project that helps me maintain the conferences that I run. And this is the first time I've sort of been leading my own open source project, well, code project conferences aside. And this work has been mostly enabled by the grants program of the Python Software Foundation, who I would like to thank. So community run conferences exhibit most of the difficulties that open source projects, open source code projects have. But they tend to be amplified in the extreme because when you are running events in physical spaces, there are deadlines. They have financial penalties. But the staff of volunteers and many people who are within a team are in your team because they want to scratch some form of their own itch. And over the last 10 years, enough people within Linux ConfAU decided that writing conference management software was an itch that was worth scratching. It resulted in a project called ZooKeeper, which it survived 10 years, so clearly wasn't too bad on the surface. You can take what I say in some of the coming slides of sort of, I guess, a coded critique of certain aspects of ZooKeeper perhaps. Clinton is twitching. Is that coffee, Clinton? Okay. It's coffee, we'll trust Clinton. So I mentioned that a lot of volunteer conferences capture difficulties that open source projects have in general, but amplified. So open source projects experience a phenomenon called drive-through contributors, or drive-by contributors, they're often called, but that has certain connotations in certain places. We like to think of people as being not quite so violent. These are contributors who show up, have a short interaction with the project, and then leave, just like a drive-through. Conference organizers who use conference management software are like drive-through contributors in the extreme. They have a project. They have an engagement with that project that fulfills their own needs, and then they often disappear. And for more on this phenomenon of drive-through contributors, I recommend Vicki Braser's talk from Pike on Australia last month. Likewise, the maintainability of software becomes less of a relevant issue as deadlines approach. There's less time available to spend on code review because deadlines are approaching and eyeballs are hitting the site and you need to get things fixed now. And this is, if you think about it, conference sites have a fixed maintenance cycle. Maintaining one conference's website stops. It stops being useful after that conference is finished, which has meant there's actually been a fork of ZooKeeper, that's LCA's project, for every year of Lynx Confey use since 2010, and most of those forks did not get merged back into Mainline because the people who were developing on them stopped caring after their engagement with the conference finished. And so if you imagine running a conference like an agile sprint, the earlier timeframe in an organization has this whole pile of things that you want to achieve, and you've got some people who can go and solve stuff. So all things being equal, you go and pick the things that you want to do most first. The things you think are fun that you think you can do and you think you can spend time on. And the later you get into the process, there's still a bunch of stuff that needs doing, it's less easy to do, and there's a lot less time to actually get things done. And the result of this is that problems that emerge very late in planning do not tend to get fixed, even if you see exactly the same problem emerge year after year after year. If people don't have the time to solve them when they come up, they do not get solved at all. So this year I've tried to do a different approach somewhat. We're dropping ZooKeep and have decided instead to use a different existing conference management project or package and writing the code that's necessary to bring the existing software up to scratch to come to parity with what we've expected in the past, well, at least the good bits. This essentially has found me writing the ticket sales software for conferences and trying to solve some of the mistakes that the ZooKeeper project made over the years. But I've been involved in running PyCon Australia now for a few years and I've failed to make the case for change for a few years now and we end up using ZooKeeper again for the 2016 conference. And this was even with the promise of working functional code to use for the 2016 conference. I was not really able to bring the community over. So I guess this talk is about what I've learned in five years of failing to get people to act differently. So I'd like to talk about how we successfully affected this project but right now the project isn't complete. We haven't run the conference with it. I can't really talk about how it went. It seems to be going okay for now, I guess. What I can talk about though is what thought went into making this project happen. So we're going to take a bit of a philosophical look into how we bring these community projects to change the software that underpins it. There's a bit of a point of view in here. You can take what I say with a grain of salt or you can not. I don't really mind. So justification of change or continuity for that matter generally comes to the idea of a cost-benefit analysis. Your way up what it will take to make a change and what benefits the change will bring about. So when you're a for-profit operation, a cost-benefit analysis really asks one question. Will the time and money that is saved into the future exceed the amount of time and money spent to affect that change? Now, secondary question you might have here is when this will happen because if it's going to take ten years into the future for something to take effect, then you might not be around to see it pay off so you don't really want to do it. It might not be worth it now, especially if you have an extended amount of pain. But the point is the metrics are tangible when you're dealing with money and you're trying to make a profit. When you're a volunteer project, you're generally not driven by the pursuit of profit, by the pursuit of money. Indeed, where possible, spending more money to reduce burnout, for example, and increase familiarity and joy with the processes, with no monetary reward, that can be a good thing. People are on open-source projects because they want to feel belonging and they want to feel ownership of what they achieve. They generally want to feel like they're doing good things, they're doing good work. Burning out volunteers is a thing that happens, but it's really hard to measure. And indeed, if you don't have the resources to go and measure it, the actual act of measuring the things might be something that the project doesn't have the capacity to do and might cause burnout in and of itself. Because volunteer's time is limited. So projects don't sail smoothly from start to finish, they're living their breathing things, they last through multiple years, volunteers come and go, people's directions change, projects make mistakes, they develop technical debt, they can become obsolete. So continuity is what happens when the benefits of change, the change that you want to make, are severely out-weighted by the cost to your community. I don't have much to say about continuity, other than sometimes it happens and for the most part that is fine. That said, well-considered change can look like continuity to the casual observer. And if so, it's really, really easy to justify because even if you change things substantially, you don't impact what the remainder of the community sees. Who here knows about Django channels? Okay, so it's an addition to Django that allows you to do web sockets and asynchronous stuff. And if you're familiar with developing for Django, there is a request response cycle in it. That doesn't really match how web sockets works. So with channels, the developer Andrew Godwin entirely rewrote Django's event infrastructure but kept the API for request and response cycles exactly the same. That meant that most of the community would not be affected if they decided they did not need the asynchronous stuff that channels provided. But the people who needed it got that change they needed. So it looked like continuity to the vast majority of Django developers. Python 3 is also a good example of this. Though it took until about version 3.3, that's five years after Python 3 came out, until the community at large realized it was actually continuity. Sorry, Barry. The harder type of change to justify is the wholesale replacement of something that was completely important to people with something else. And this is harder to justify because it intimately involves people who aren't you with the unknown. It means that the development on the old thing is tenuous and possibly wasted effort and that development on new ideas might not pay off. And so I'm going to be spending the most of the rest of this talk on considering how to handle this sort of wholesale change. Examples of wholesale change in the open source world. Who knows what Turbogears was and who he uses Turbogears anymore? So a few years ago, the project leads of both Turbogears 2 and the Pyramid project realized that their goals were exactly the same and they decided to merge the products. Unfortunately, this resulted in the entire Turbogears community disappearing and the Pyramid project not really getting the developers they wanted. There are successful projects that have done this. In the late 1990s, a fork of GCC called EGCS emerged. It fixed a bunch of problems with GCC and eventually became the project known as GCC and that project went and absorbed all the contributors to the fork. Another example of wholesale change is Python 3 before people realized there was a common subset of the language and compatibility tools appeared. It appeared as a wholesale change for most developers. So with change comes risk. Open source projects being run mostly by volunteers have a few that you need to consider specifically. So the first one is bike shedding. Bike shedding is when you have endless arguments over relatively minor details of a large proposal rather than substantive engagement in big issues. Now, this phenomenon is actually really, really frequent in volunteer projects because commenting on something takes a really small time commitment and people tend to comment on things that they can grasp easily. But large scale change takes a large commitment to understand. You have to go and read all the background, look at large swathes of code in order to understand what's going on and making a useful contribution. Bike shedding is a waste of time and it leads to key architectural decisions not getting the sort of scrutiny that they deserve. And this is often because volume of comments is often mistaken for rigor. People thinking that seeing lots of comment on a proposal means that it's been well considered. Now, bike shedding is something that should be considered inevitable on any project. But it's important to reduce it at inopportune moments. So one way to do this is to focus on getting code done before having planning meetings or rather having endless amounts of planning meetings. Now, open source projects uniquely are susceptible to forking. You can fork things on GitHub and that doesn't really matter, but if you have a large project and the large project forks and has two different communities splitting because some members want to focus on one priority other members want to focus on something different. Now, whilst it's not something that needs to be avoided at all costs, if you lose volunteers it can hurt. You should always consider what you need to do to maintain all of your volunteers and what you can do to keep them on board. That said, you don't need to try to keep people who want to go and work on old code. If they want to do that and not work on your things that's probably not worth your while to force them to do what they don't want to do because having people who don't really want to be there can reduce morale across the entirety of your team. Now, after you've considered that change is necessary consider how to make people in your community want to make the same sorts of changes that you want to make. So the more central the thing that you're trying to change to your project, the greater amount of the project you are going to affect. Generally, if something exists in your project then there is somebody out there who owns it or feels a really, really strong emotional attachment to that part of your project. There might be a user whose ability to work at all is affected if the thing that you're doing stops being there. Give fair consideration to whose needs are more important. If you focus on the needs of current developers it will often help you maintain momentum with your current contributor base, you know, keep a project rolling along. But focusing on end users can lead to growing your user and contributor base because users can become contributors if your software meets their needs better and they want to work on it and help make it even better. If you're having difficulty attracting new contributors focusing on your existing developer pool might not necessarily be the right idea. In the case of Linux ConfEU even though our change was motivated by fixing issues with end user usability we made the decision to adopt a base platform with a significant existing developer base which meant that our own community had a better support base for our own developers. Speak to the people who you know will most benefit. Getting support is really, really important before going and taking your changes to a larger group of people who might end up offering resistance. Doing that progressively is a great way to do that. So how can you make this happen? Well, you offer a clear pathway to achieving the changes that you want. What's the end goal that you're trying to achieve? Are there intermediate steps where you will need help? Can you evaluate whether what you're doing is worthwhile and likely to succeed before you go and take the effort to try and convert your entire community? In our case for LCA we set deadlines for evaluating the functionality of new software before undertaking any development work. We knew when things would need to appear to be viable before we could commit to using the new stuff so we knew when stuff would have to be ready and we knew exactly when we would be able to back out. Now once you've advocated for the need for change you need to figure out how to go and affect that. A community in general will not accept immediate change that is handed to them down from above by dictum with very, very, very few exceptions. People in an open source project or any volunteer project for that matter will not decide to do something just because their project lead tells them to do it. That's because usually volunteers are in a project because they have some sort of itch that they want to scratch for themselves. Deciding that you want to go and do a large pile of work does not mean that everybody in your organization is going to want to do that large pile of work, especially if there is no clear benefit to them making the contributions that you're asking them to make. Now if you're in a community that centres around code which most open source projects are, being able to say, this here is what we can do is a better thing to be able to say than wouldn't it be good if we could go and do this thing? Showing that you have something that you can do and needs improvement is better than asking somebody to contribute to something that's completely nebulous. This comes down to giving your volunteers a clear pathway towards the end goal at all times. You make it obvious that progress is being made towards solving their problems and you make it clear that the problems that they have are being solved. And in general, having work in code almost always prevents bike shedding with great reliability. Now it doesn't always make sense to involve absolutely every stakeholder in a project, at least at first. There'll always be people in a project who think that they're completely fine with the status quo. People who don't have much of an incentive to change what they're doing. Instead, a better thing to do is to find people who are having difficulty with the way things currently are, people who are being let down because these are the people who you can most obviously help by doing things. Volunteers are generally there because they want to work on your project. So find out how you can help them do that. That said, don't exclude people forever. Get engagement from people and do that, and that's best done when you have a proposal for people to hack on and improve. Don't exclude people permanently. Involving people at the right time means that you can have greater control over the sorts of resistance that you might encounter. Having a working prototype or mostly finished products means that you can change the decision from should we start doing this work to should we adopt this change. And should we adopt this change is a much, much easier decision for a community to make as a whole rather than should we go and do some work. Now, sometimes the energy required to get something up and running exceeds what volunteers can do in a weekend, for example. That said, there are organizations out there that can help you raise funds in order to achieve an initial working project. My conference management work has been funded by the Python Software Foundation. But other projects have used various foundations programs. Excuse me. I've also seen Kickstarter and Patreon used a quite decent effect to kick off or maintain various project success. Actually having money to go and work on useful code and get useful code for the community to evaluate is a really good thing. So once you do go off and do the things you expect to do involve everybody you can throughout the process. Make sure that you are doing the right thing and that you bring your community with you. At the same time, keep their expectations managed. Make sure they know what's happening and they don't know, and they don't get wild expectations of what's going to happen. In my case, my work with the PSF has meant that I've needed to give regular status updates to the board. And I've also involved other potential contributors and LCA team members as the times have been right. They know where things are at as I develop them. And finally, sometimes your attempts will not work, and that's absolutely fine. Just make sure that if you are going to fail to achieve what you've set out to that it happens for the right reasons because the things you wanted to do weren't necessary. If your ideas were flawed. Or that there are better solutions to the problem that you're trying to solve. Not because you went the wrong way about trying to do what you're doing. And with that, I think we have time for questions. Thank you. We have a couple of minutes for questions. Did anyone have a question? So, what do you think the role of or maybe the effect of having a very strong BDFL is on a project where when consensus can't be made they can say it'll be this way or it'll be that way versus it's more hurting cats on a project. Well, I mean there's always... So, if you have arguments it's always good that your argument can end at some point. Because nobody likes having a thousand long threads on mailing lists with no clear outcome at the end. There are places where having a BDFL whose opinion is respected works. For example, the... Like every single Python enhancement proposal basically goes through Guido these days or somebody who Guido really trusts on a particular area. And that tends to yield really good results for Python. It's really a matter of the BDFL being trusted by the rest of the community to make good decisions. I'm not going to say it works absolutely well everywhere. Like you could argue that, for example, the Linux kernel alienates a lot... The Linux kernel process alienates a lot of people because of Linux's approach to solving problems. So, there are places where it works. There are some places where it might be seen to be technically effective but hurts the community. It really depends on who your BDFL is. Tim? For the audience, can you just describe what you mean by BDFL? Oh, yes, sorry. BDFL stands for Benevolent Dictator for Life. In the Python world, Guido van Rossem is the BDFL. He is basically the sole arbiter of all enhancements to the Python programming language. And generally, I think the community has decided that his opinions on making the language are pretty good. I mean, Python is a pretty good language and he rarely makes terrible decisions. That is a BDFL. Thanks, Chris. I was wondering if you had any advice for, say, dealing with poisonous people, right? Like, you've been... you've put up some strategies for preventing bike-shitting. But let's say that there may be two or three people taking a disproportionate amount of time from some... if you had any ideas or any success stories. In my case, I tend to just exclude those sorts of people. If you can... Hmm. Not pointed at all. If you can make technical decisions that avoid... or that avoid needing to consult with those sorts of people and build up a critical mass around the decision that those poisonous people would not want you to make, then generally, people just stop listening to them. You know, a lot of people sort of... a lot of people continue doing what they're doing because they see what they do as effective. And if, you know, if they don't get the results that they expect, they'll probably stop doing it. Demotivation is a wonderful tool. We have time for one or two more. Making me run all around the room, Clinton. Gosh. Very much on conferences, but not on software. How do we encourage conference organisers to not live in the shadows of previous conferences and let them decide how they want their conference to run? Hmm. Interesting question because one Australia which I've been involved with has very much had a, I guess, an incremental improvement approach to continuing the conference. So getting the subsequent organisers to make minimum possible changes. I don't have many thoughts on that, that are well formed at the moment, but you should come and ask me later on. Were there any more questions? You talked about obviously the human aspect and organisation of stuff, let's say like the process. I was wondering in terms of the insights how much of a difference the technical tools and the underlying infrastructure make a difference. Okay. So firstly technical problems are easy. The more people, if you have smart enough people to solve problems and you can set them aside doing it without needing to interact with people, they will probably solve the problem for some definition of solved. I think a lot of the problems with ZooKeeper were social ones and solving the social problems with ZooKeeper led to having a better technical solution, I think. Basically, I think tech problems will tend to solve themselves if you have the right social tools in place at first as long as you have capable people. And that's all the time we have. Let's all thank Christopher again for this good talk.