 Kia ora. Thank you. Actually, I'm surprised at how many people are here. This is not a straight out data talk. This is more about producing open source products. And this is only the second time I've given this talk. The first time was, I think, yesterday or the day before yesterday at Penguin Con, which is a really interesting conference in Detroit if you ever feel like getting your favourite Penguin costume and going to an open source conference. I recommend Penguin Con. It's awesome, full of really fascinating, amazing people. Anyway, so this is called Scratching Someone Else's Itch and it's about producing excellent open source products. It's sort of going to be connected to this book that I've put out, The Cabbage Tree Method. But this is just one strategy of a greater strategy that I want to talk about. So first a little bit about me. You can find me at Adam Hyde.net. I'm in New Zealander. I'm now living in San Francisco. And I've started a few open source projects. Fluss Manuals, which is a community that writes free manuals for free software. Book Type, I didn't write it, but I was the founder of it. Book Type is a book production software. BookJS is a lot of projects in this realm, which is all about open source solutions for producing books. I'm a co-founder of the Collaborative Knowledge Foundation, so I founded Book Sprints, which is a methodology to write a book in five days. You can find that at booksprints.net. Started off with writing software manuals. And The Cabbage Tree Method, which I'll talk about. I'm also a Shuttleworth fellow and I used to be an artist and stuff. This is me standing in front of RT32, which is one of my favourite gadgets as an artist. It's an ex-Soviet radio telescope I used to make sound art with. This is the Collaborative Knowledge Foundation, CoCo.Foundation. We are working towards solving scholarly publishing problems with open source and building good faith networks. We were part of the group that brought together the Open Source Alliance for Open Science that met for a first meeting yesterday, which was a wonderful day. And we're building interesting infrastructure. PubSuite, Inc. Editoria, XSuite Editoria is a monograph production suite. And these other tools are basically enable us to build the kind of like suites for building workflows for publishers. Most of it's JavaScript based. We use 100% Open Source Toolchain so you can find this stuff at GitLab.CoCo.Foundation GitHub is proprietary. So it's to scratch. So those of you know anything about Open Source, there's this famous chap, Eric Raman, who sort of categorizes himself as being the first Open Source anthropologist or self-appointed Open Source anthropologist. He wrote this book called The Cathedral and the Bazaar and Other Works, right? And he has a few famous statements. One of them is every good piece of software started with developer scratching their own itch. So this is the, you know, considered as a sort of foundational work, Cathedral and Bazaar, and this is a foundational concept. And I think it's very true. You can see it in action in prototypical form with Linus Torvalds. He wanted a free operating system. There wasn't one that he wanted. And he started on it. The itch is wanting the operating system and he started on it. That's a scratch. Then, of course, he did this famous first posting of his email saying anybody want to help. And then the rest is history, right? Just developed into this massive communal scratch. So there's a couple important things about this itch to scratch model, right? It's like, you know, if you have a problem that you want to solve, that's the itch. And scratching it is going through the process of actually solving that problem. I think the critical part of this is two critical parts, but the one I want to focus on is that the fact that your itch is critically important, right? Because if you have a problem, you're an insider to that problem. You understand these nuances incredibly well, right? This is kind of the thing that set off just about every open source product, a project that there ever was. You know, that a developer has this specific problem. They think, ah, I've got to solve that. It's annoying. And then they work towards solving it. And because they know it well, they know the nuance of the problem and they develop a really interesting solution, right? In this case, a developer is both the use case specialist and the code specialist, right? So the developer knows the problem, the use case and they also know how to solve the problem because they're a developer, so they work towards solving it, right? So knowing your itch gives you these insights and motivations. You're motivated to solve this thing and you have this internal understanding what the problem is. But it's this knowing your itch which is the important part of it. It gives us, it's an important quality of an experiential factor. It's critically important in my opinion. It's different from, for example, proprietary approaches where, you know, you have a different kind of culture. Open source is kind of like a cultural method for solving problems. It's sort of evolved as a culture. Whereas commercial strategies, proprietary strategies are much more intentional and they often treat the user as a research object, right? So we go out and find out what the user wants, we'll document that and then we'll build it, right? And you can say, well, this old school, this is true for just about every methodology that's evolved out of the software development life cycle tree. If you know about software development life cycles, it's just a roof ceiling under which it houses a number of different ways to develop software, these models, methodologies, spiral, agile is mistakenly called a methodology, it's an idea, kind of. But, you know, right from waterfall, right through to following all these things through Scrum and whatever you want to choose, you're basically treating the user as a kind of research object, right? In some methodologies you have avatars, you turn the user into an avatar, so you draw a picture of them and you think, I know what that person wants, which is second guessing user, right? It's really, the user is external to you. And I think that that's where the key differentiator why open source is being so successful in solving the problems, right? That the developers have their own problem, they solve it and they solve it incredibly well because they understand that problem, they're internal to the problem. And I think proprietary takes this other approach, right? And it sort of works, it's pretty good at working. But the big question is for me is that I don't really care about proprietary software, I don't want any part of it. So how could we work with this itch to scratch model to solve problems in the user space because open source has generally failed at this, right? I think you can look around the world at the different categories of software and you can say, well, open source has solved the infrastructure problem, right? You can say it's one more or less. The internet runs and open SSH and bind whatever you want to name, all open source infrastructure is there, operating systems are there, drive the internet. Every phone has got at its core pretty much an open kernel of some description. Even, you know, many proprietary OSS have got open components so it's solved the infrastructure and it's also solved developer tools, right? JavaScript libraries, you can't pretty much can't develop any piece of software without using open source. So open source is one in these categories and it's been a progressive win, right? When Linus Torvalds did this original email, there wasn't that much open infrastructure and so open infrastructure was first solved with databases and operating systems then came developer tools after that. And so it has been an evolving process and one of the last areas that open source hasn't solved and I think needs to solve is how to make good user-facing products and I think it's entirely failed. There's not many products out there that you could say were beating the proprietary competition when it comes to user space, right? So if you look at Libra Office, it's a copy of Microsoft pretty much of Word. Social media, we've pretty much lost, right? The open frameworks, open source platforms for social media haven't really won the social media game. Just about every desktop application, even desktop environments, you know, I think Unity is a beautiful operating system desktop, open source desktop, if you don't know it, it's what until recently has become the default desktop for Ubuntu is going to be replaced by GNOME but it's a great desktop. GitLab I think is a better product than Git Hub. I think it actually looks better and works better. I think Matamost is a better product than Slack. I think there are some examples but I think there's a lot of failures and in fact mostly what I see is failures and we should be crushing the proprietary competition, right, in the space, in the user space. So why has open source failed in this area? And why has it failed in the user space, so to speak? And I think the fundamental problem comes down to that open source has not been good at scratching other people's itches, right? So in this situation we have a user who has a problem and you're having developers that are trying to solve it in the open source world we've pretty much put the user at the end of the line and the developers are trying to guess what they need and they're developing towards that. The developer is no longer internal to the problem space and doesn't have that same nuanced understanding of what the problem is. So there's kind of been a breakage here in that developer, the open source developer, the core solution provider in all open source projects pretty much and if you doubt that just look at the language that's used in open source, you know when the word contribution is made what do people mean, right? You look through any forums, you can see people talking about coders and non-coders, right? There's not even a language for people who aren't, a nuanced language for people who aren't coders. And so we've sort of failed, we've pushed the user out and that makes sense if developers are developing their own tools because there are their own users, that makes sense but when it becomes developers solving problems for other people, it becomes a real problem, right? Because the user in this case and I'd like to re-categorise or reclass the user, is not a user, right? A user is somebody who sort of hangs on to the good will of developers and accepts what they're given and uses it, consumes it but the user shouldn't be thought of in this way. A user is actually a use case specialist. They are the expert of the problem. They are internal to the problem and they are incredibly valuable to you when you're developing open source products. They shouldn't be somebody that you're trying to second guess. They should be core to the solution model, right? Right in there, at the beginning and helping you design the solution. So if we want to scratch someone else's itch, the user must be central to designing the problem at the solution is my opinion. So there's a very simple takeaway from this and this is generally where I would kind of finish the talk because open source is a hard beast to change, right? It's a calcified culture and you have to be very careful. I've brought up, I've done this kind of presented this kind of idea in various open source forums and pretty much got, you know, burnt at the stake as a heretic because you're challenging the status of the developer, right? It's been the primary solutions provider and it's not something that open source culture is comfortable with. Generally speaking open source people have most of the say in open source projects and everybody else comes after and they find their way to work including using all the software developers, tool chains, etc. even though they might not be comfortable with them, right? So there's an established legacy dynamic and so trying to improve upon this is very hard. It's not about changing workflows, it's about changing culture. So what I'm trying to do is change the way that I present this idea and I'm saying, okay, well everything's got to change in open source and just say if you can, if you have an open source project or about to embark on one, if you could think about these two principles if you're producing user-facing solutions you would do a lot better, in my opinion. The solution would be a lot better and you can be guaranteed that it's going to be used from the get-go. And it's basically designed first and designed with the user, right? The user as a use case specialist is critically important. They have the problem, work with them to work out what the solution is and then work towards that solution and build it. So the reason why, I used to start this talk, I've only done it a couple of times as I say, but I've thought through it a number of times and I used to say, okay, well the cabotry method which is the method that the Collaborative Knowledge Foundation has evolved, designed is the way to do this, but it's not. These two principles I think are the guiding principles and point to a whole lot of different pathways to get there, right? So you could just start if you have an existing project sitting down with users, bringing them in and saying, okay, how would you design the solution? What is it that you need? But I do want to talk, since I have a few minutes, very briefly about an example of how to do this and this is the cabotry method. I think I've got five minutes or so, 10 minutes? Well cool. So there's the cabotry method and you're welcome to one of these books should you want them. And I've got some stickers also. And the cabotry method. Cabotry, by the way, has got nothing to do with the methodology. A cabotry is just a tree in New Zealand. I have a house in New Zealand and it's on Cabotry Road and people told me collaborative product development was a really boring name. So that's why it's called this. And also, by the way, methodologies in case anyone's wondering is just something somebody's made up. This is another important point that you should experiment in trying to develop the methodology that best suits you to get you towards better products. If you were to adhere to these two principles, design persons assigned with the user don't take anyone's blueprint on how to do it. Sit down and work it out for yourself because every culture, every production culture is different and you've got to work out how you can iterate on this that best suits your culture and your project. Anyway, so the cabotry method, we had the opportunity with Cocoa Collaborative Knowledge Foundation to design a methodology from the beginning for developing products. The first product was with the University of California Press where we developed a monograph production platform, book production platform, largely before Open Access works. So we thought, OK, so how are we going to do this? We could design a platform and give it to them so there you go, you can praise us now. Or we might sit down with them and work out what they want with them. But in a way which is more sensitive to open source culture, not treating the user as an avatar, not researching them, not waterfall-ish, not spending three months writing requirement documents, stuff that felt good to us, that felt like we wanted to do. So we had this opportunity to design that process. So before I start out, I just want to say the cabotry method is a method. It's documented here. Methods are not written by religious. They're just guides, navigational instruments. But this particular one is good for building platforms and working with organisations that have workflow problems, right? So this is a category where I see it fitting. So you can take that for what you wish. But haven't tested outside of that realm yet. So also it's a strongly facilitated method, right? So I developed this methodology with Book Sprints where you facilitate a group of people through writing a book in three to five days. And through that, I understood, come to understand that these processes need guides, right? Production-orientated processes and community processes need guidance in my opinion. And so I think we should be seeing the evolution of the facilitator with an open source, facilitative leadership, rather than the sort of benevolent dictator model, which is, you know, someone starts a project, they're there forever, and whatever they say goes, even if it's crazy. And I think facilitated leadership is a very interesting idea and it's an idea about how you would facilitate communities and all their operational parts to build a solution together and to be a healthy community. But we practice facilitated design, right, where we actually literally facilitate the use case specialist to design their own software, right? So, and this is against a lot of open source but also just general software principles, right? There's this sort of sometimes unspoken, sometimes loudly spoken mantra that, you know, users don't know what they want. And we say, no, that's crazy talk, right? Users know exactly what they want. They're not users. They're use case specialists and you should listen to them. And so we facilitate these people to design their own products. And this is pictures of use case specialists literally designing their own products. And these are all publishing staff. These are not developers, right? Or systems designers. So I'll just walk you through how we do this. First of all we have a facilitated session which is the first session where we come up with this light bulb at the top which is the big idea, right? We do this in one session and we talk about, you know, where are you now? What are your kind of problems? And then together we reimagine a solution and that actually might even materialise as kind of, you know, high level, what you might call architecture. It does not really architecture like drawing of, you know, we want this and then we want this and we want this. And then we go through iterative design cycles where we say, okay, that's a big picture. We'll think about that. We'll come back. We take off a slice. We sit down and we facilitate them again through a process where they then design their software, that's slither of the software. And they say, this is what we want. And then we go away and we build it with specialists and code specialists. Then we bring it back and say, is that what you want? They say, yes, no. And then they design the next thing. We iterate and iterate until we get to the end. This is a particular foe for the Collaborative Knowledge Foundation. We have these, what we call design sessions. We facilitate with the users, with the use case specialists. A very brief brief comes out of that. We then have a design meeting with the code specialists and UX specialists. Some things are really locked down, some things are open-ended and we talk about it through. We update the brief, the code specialists and generally start coding straight away. The UX specialists can update mocks and then add them to the brief and we just keep going. Everything is very conversationally based. It's not really like locked down, highly managed development processes because that's, generally speaking, not so comfy for open source cultures. And going from the design session to the final brief and everyone starting to the final brief, it's more than a week and has to happen immediately after the design session that we go through this, right? The iterative cycles when we do the build and come back can be something like two weeks to six weeks, something like that. Here's an example. Kate and Cindy from University of California Breasts, two production editors designing their own software. Cindy has got a whiteboard marker in her hand and on the right is a whiteboard and she's drawn a redboard marker, but this came out of conversation. You can basically see that there's a kind of a drop-down menu here. There's Edit Buttons, there's sort of statuses, styling, editing, review and something else, I don't know, clean up. So we took this out of one session, they literally drew this themselves. I really said to them at one point, we talked about a lot of issues and said, well, what would you like to do? What do you want? They said, oh, okay well, and they drew t نегa o teʻot filing tu singwai rendo te구�era ringu i te ni nidadiu te tajatu tnu te iarri mahiawun i whānau Weitburg paio angaail, and vivu te kouriu te ronde Ngai teauiai te awa uu mikun ma Career kasgo darora rト nouin na te a roti these individual things here is that one little component, that they designed and so they are literally designing their own software right and this is just the next thing that design wich is an editor that we're just about to implement…so that's it. That's all allow on what to say Yeah that's caveatry method but the design first designed the users thinks and try to communicate is a lot of history behind that of course uses into design and all this but my point is that your project needs to develop own ways of doing this, right? Don't follow established methodologies but find the right path for you. That's the starting point because you can't deconstruct your current culture and then suddenly throw this new methodology on top of it. You have to iterate towards something that makes sense to you. If you are starting your own project, you're in a better place. You can actually intentionally design it, which is pretty interesting. But if you wish to go down, you're working with organisations, you need to work through workflows or maybe developing CRMs or something like this. This is the kind of platform that I think the cabbage tree method could be useful for. Anyway, so I have a book here. It's written collaboratively. That's why it doesn't have my name on it. But it's got pretty much everything we've learnt so far in here and we'll be iterating on this. Oh, and also you can get it for free online. We use completely... We use the system that we design the cabbage tree method to help build Editoria, which is a monograph production system. We then use Editoria to produce the book on the cabbage tree method. And so this is in the source file format as HTML and this is using Vivlio style open source JavaScript library to render that HTML into an online book. So you can see the book here and this is all page-nated like a book in the browser. It's all HTML, open source and then that created the PDF from which we printed the books. It's just a little side story. Anyway, that's dog-fooding. Round and round. Okay, thank you.