 Okay, so me and Thomas is going to talk about the difference between the movement perspective and the product perspective when it comes to organizing work more or less. We had a conversation via IRC, I think, and then Telegram, and we argue a lot. And this is one of the things where we sort of don't agree. We sort of have this different opinion on how things should work. And he has a product approach. I have a movement approach. And we're sort of going to introduce both of them really quickly. I come from the left wing, which most people know, which is not a secret, might be. And from that, I got the movement perspective. It is sort of the way the modern left or the extra-parliamentary left tend to organize things. The difference, for example, when it comes to Linux, if we look at open source, there are two examples of product versus community and movement. And the movement perspective is used very much by FSFE, for example. But the background for me came specifically from two Swedish organizations, Plankapuknu and the Pirate Bay. The Pirate Bay represented very much a product-based idea. And Plankapuknu represented a very community or movement-based idea. And they separate from each other on certain key points. And me and Thomas will switch sort of by the by, and he will explain the product bit and I will explain the movement bit. Movements specifically focus on a larger, grander goal. That is part of what they do. They focus more on the group than the product. They focus on what do we do and what is our grand goal, the thing we really, really want to achieve, but we kind of assume we won't be able to. An example with Plankapuknu, which is a free public traffic or public transport idea. And the goal there is to create a free public transport for all. They know they probably won't reach it just yet. But instead of looking at specific products or specific actions they can do, they look at the overarching goal and how they can sort of achieve it by doing smaller, different tasks. And even laptop just locked up. Bit by bit, this will make perfect sense. We will go by it bit by bit. And Thomas here will go by the background of products. The second event, wonderful, let's switch forward. Keep moving. Okay, well, there we go. You can start with your background. Okay. Oh. Yeah, so the, wait, there we go. So the context of the product perspective, then when you say product in a free software community there, you may get some people a bit cautious because, for example, NU recommends to not devoid the term software industry. They have a whole list of terms you should avoid because they have some negative connotations or something. One of those is software industry because they say that industry makes it sound like we're all somewhere in a factory working on a car or whatever, which then has to be sold. And if you can't sell it, then it's bad. And there are limited resources going into a car and all these things. And they say that, well, the free software movement is quite different from that. And of course, product is a term that is often used in the industry because it's very, very important for them. But it's not necessarily as closely connected to something that is necessarily sold. Of course, for the industry, it is something that is sold, but a product does not necessarily have to be something that is sold. Marketing literature then defines or one of the definitions in marketing literature is that a product is anything that can be offered to a market that might satisfy a want or need. So this is something that gets much closer to what we're doing because, well, market again sounds a bit like money being exchanged, but it doesn't necessarily have to be that way. And so for us, the market is more like the target audience. And of course, we do want to satisfy a want or need of a target audience because otherwise what's the point of doing something? Whereas the product based ideal is essentially looking at the product that you're producing, looking at the thing that you're doing. If it's, for example, in open source, we do an application and we sort of finish that one. Instead of doing that, the movement perspective bases itself completely on the movement itself. Take Free Software Foundation again. Free Software Foundation wants to, as an overarching, massive, almost utopian goal, make everything open source, free information, free culture, et cetera. They know they're not going to reach it tomorrow, but instead they focus on products or smaller projects that they know they can achieve. They have, for example, like the stickers, for example, that they give out or they do these conferences. They have smaller, smaller products that might eventually leave to this grander overarching goal. And one of the focuses instead of the product that you're producing is the people that are doing it because you're trying to actually make this movement bigger. You're trying to get more people involved. You're trying to focus the group. And the goal is instead of doing one product and finishing it and being done with it is looking how the product fits into this overarching, relevant goal that you're actually focusing on. And so you take this overarching goal, let's take Free Software Foundation. You want to create open source. And within it, this movement that you created, you create subgroups and projects, things that you think will push this goal forward or rather closer to you. And you have short and midterm goals to sort of define what it is, I'm sorry, I'm looking at even as well, short and midterm goals that will sort of define how well you're sort of going towards that grander goal. You're not expecting to reach it, you're more or less expecting to go towards it. One of the focuses as well is also on group dynamics instead of looking at how well did we do this product? We look at how well did the group perform? How well did we move towards this goal? How many people notice that? There is a very clear difference in the focus between product and movement. A movement is more about the people involved and less about the product they produce. I think. So yeah, from a product perspective, what you want to do is of course reach people because without, which is for the industry, it's the market, as far as it's just target audience uses. And very important part is you want to provide people value. So if you do something just for its own sake, from a product perspective, it's completely useless. It only makes sense to produce a product if you can really show that, okay, this brings value to at least some people. Then of course, when you have a product that provides value, you also of course want to make people use your product. Otherwise, what's the point again? And yeah, I mean, from a classic commercial entity, of course you want them to pay you. But getting money is not the only thing you can get back. In the open source world, giving back often means just ranging from just simply writing a bug report about something to contributing themselves at some point. But it can also be money in the form of donations. So any way of getting people to think, oh, this is so cool, I want to give something back and this is something that we often experience that people come to us and say, I want to give back, I like it so much, so how can I give back? And this is the point where you've succeeded. Unlike the product-based thing, the movement perspective has very different, like I said, a different focus on people and the way you handle products. And it also requires certain steps to function. It also requires a certain level of, I would like to say cruelty because that's part of it. The first thing you do, you create that goal. You create that overarching goal. Like for example, we want all computers to be open source. For example, from hardware and up. That would be a weird goal. We would all go, oh, Jesus, but that's decades and decades away at best. And after that, you've made that goal large enough that everyone in the group agrees with. You define the group. You say, okay, we're the group. We all want the same thing. We all act somewhat the same thing, but you also define who's not in the group. For example, if you have this overarching goal and you're very strict about the free software ideas, for example, you don't want anyone going, yeah, but I'm going to use a little bit of this proprietary bit. It's good to tell that person in that case, no, no, no, no, no. That's not the goal of this group. We're doing this long-term thing. And it's fine to do that. That's one of the key elements of it. Being able to say what we're not, which sounds really cruel and it sounds really horrible, but that's the only way to actually keep a sort of focus. Otherwise, it's just a group of friends doing nothing. The second thing or the third thing is that creation of sub-tags. This is a sort of ongoing thing. You have to do it bit by bit. You can't just go, well, these are the tasks we're going to do, but you want to see like, oh, I have a cool project because if you have that group, a focus group on one goal, you have made sure that the group is all at the same mindset. And then you go, well, does anyone have a cool idea? For example, with Planke Puknu, the free public transport system idea. They did a specific protest. That's like a product, more or less. One protest is one product. It's not the whole idea of the group, but it's just one of them. And the upside is that they can do these things individually in the group because they're all focused on the same thing. The group has the same goal, has the same methodology and character. And I don't know how profit happens, but it can happen. But there's a very clear philosophical difference as well. Because we're a product, when it ends, for example, that may be problems. We'll talk about that later. But where the movement can sort of fail, there's plenty of reasons for that to fail as well. We'll talk about that later. But the focus is very clearly different. Like I said, the focus is more on the group and how the group will evolve and change. It focuses on the group interaction. And products or protests, for example, in the left-wing context, would be relevant, but they're not critical. They don't have to succeed. They are free to fail in a large-scale manner because you still learn something. The group still exists, the goal still exists, and you still can move towards it. That's the upside of it in many ways. Then a typical procedure from a product perspective is that first you need to find out about an unsatisfied need in the market. So from a typical product perspective, you don't just go, oh, I have a nice idea. I want to do this. But of course it starts with ideas, but an idea makes only sense by actually following if you can see that, okay, there is a need somewhere in the world and which cannot be satisfied with what exists. And that's where you can say, okay, this is the niche where we can get in. Then once you have identified that need, you would define a product vision. So define what your product is about, why it's beneficial, and to whom. Then the target audience, because you really have to define whom it's for. It might be a rather wide audience. It might be a very narrow audience. But if you haven't defined who your product is for, you're going to fail at creating it properly. Then once you have that, ideally you should gather requirements from the target audience because you don't, unless you're a member of the target audience, but even then you shouldn't just base it on your own needs, but really talk to people, find out what they're doing, what tasks they have, so you can really make your product work for them. Then comes the point where you define your features and your UI. You should do that again while talking to your target audience or to members of your target audience. You should do it iteratively and show things to them, have them, try them out and do the whole, what we call, human-centered design process. And here there's an author, Marty Kagan, who wrote a lot about product management and product design. And he says that there should be a product manager whose role is mostly to know the market and to know what people need. There should be this one UX specialist who knows how to design, use interface to work well for the target audience. And even in the design phase, the development lead should already be available so that you don't design something which then later won't be implementable. So it makes sense to together that, also the technical feedback at a rather early point so that you don't throw something over the fence and then the developer says, well, I can't do that. And then in worst case, just do something else or in the best case comes back to you, you go back to the drawing board, this is not efficient at all. So having everyone responsible on board early on is very helpful. Yeah, then of course you create the product, you ship the product and then you should measure whether it has reached its goals. But we can get to that later. So with the movement perspective, you have, like I said, a very different outlook. Mainly, will this help bring about the goal with capital letters? Will it help us bring us closer to it with the Free Software Foundation? If they do say a specific communication thing, event, for example, they will look at, will this actually bring us closer to Free Software as an all-encompassing or covering goal? It's also, when they look at, for example, projects like this one, they have a conference, they will afterwards look at, will this actually move us closer to the conference goal? Like the conference can have its own sub-goal. It always leads to the same point to grant the goal, but it still can have tiny, tiny small tasks. And then after that, you look at, will this help the movement or the group? As in, for example, me and Thomas here standing and talking. We're in this situation, a movement. We have a sub-project, which is to give this talk. And from our point of view, will this help us convey other people about these ideas and there's different ways to measure the success? But one of the things to measure it is how well did this go for us? Will Thomas go outside and slap me, for example, because he's really annoyed with the way I talk? That's not good. Or will he think like this was a sort of bonding experience? That means we might work better in the future, et cetera. It's actually a sort of sub-task of every single project. Will it help the group? That can actually justify a crappy product. If it helps the group sort of unify, work better next time, that's in itself a good thing. And then finally is will it make people notice the sub-group and perhaps want to join? That's a secondary or, in this case, a fourth goal. There's a lot of different ways to measure success, which of course comes with a lot of downsides. Thomas, let's see if you want to do the product. For measuring success, measuring a product success, you usually want to have quite specific ways. The most important thing is, of course, does it actually satisfy the target audience's needs that you have identified earlier? If it doesn't, then it's a failure. Unless by accident it satisfies some other needs. This can happen as well, but then you were just lucky. Then, of course, are your users happy with your product? Satisfying needs is one thing, but you really want them to be happy about it. Then, of course, does the... Then again, in a typical industry case, it would be does itself. In our case, it usually does usage increase. Do we notice that people download our software or use our service or whatever we're doing? If that doesn't happen, then something obviously went wrong. Then again, you always hope that people are giving back. One reason is that, of course, you hope that you're getting something back, but also because that's also an indicator of success and people being so happy that they don't just use it but want to give back in some way. Ideally, you have specific metrics. When you can collect usage data or at least track the number of downloads or if you are in some software store, you have the metrics of reviews and scores. Measuring the success in as specific a way as possible is actually really helping you to see should I continue with this or should I maybe change something fundamentally or if it goes all wrong, then maybe just give up and do something else? With both perspectives, there are drawbacks and there are gains. They're different. With the drawbacks of the movement perspective, you all can probably gain from this wishy-washy language of this almost hippie-esque movement is that it's extremely tricky to measure success properly. It's very easy for people to go, well, we're better friends now, so this went well, and that might justify it, but it's not going to be the end or be all of any sub-project. It's vague and diffuse. It's very easy. For example, if me and Ivan create a group, we could decide that we make our own rules of who should be a part and who shouldn't be a part. We can change it. Oh, I like that person, so you can be on board anyway. It can be easily subverted and changed. It's very excluding as well. It's very excluding because someone will always get hurt when you tell them, no, no, no, no, you can't be part of this group. I'm not interested in having you here, and it can easily be hurtful and bad, and it tends to start new sub-projects really quickly, and end them really quickly. Like, you can have new sub-projects popping up every day, and it's just vapor. It's nonsense. Nothing really happens from it. The upside is that it's way simpler to start something because everyone can do it autonomously. We all know the direction we're going. We all know what kind of group we are, so we can also trust, for example, Martin Gresslin to do his thing, and he starts a project or a project, and we all agree that, well, it's Martin. He's in the group. It's fine. Let him do his thing, and we all feel that we have some sort of responsibility for what he does, but we allow him to do it himself, so it's easy to start things. It's easy to do different things and indeed individual endeavors because, again, we all trust each other. We all have the same goal and methodology. It's easier to join, which is a little bit weird because it's also excluding, but it's easier because everyone can see, oh, this is what they're about. They're very clear about what they are and what they're not, and you don't have to actually do anything to join. You just have to be ready to join the group and agree with them. And it's also quicker production. That's one of the great upsides is that it's very easy to start new things and you just finish them really quickly and just hammer them away. So you get a quicker production because you trust each other. You can always jump across products and projects. Then some gains and drawbacks from a product perspective. The biggest gain, probably, is that you're focused on providing value. It's not just people doing things because they like doing things, but you're always focused on, okay, does that actually bring any benefit to my users? And yeah, you're focused on the users themselves. So proper product design cannot be done without knowing your users. And so, yeah, make some focus on you. And you can have very clear measures of success, as I already said before, which can really be helpful in the feedback. Yeah, then, of course, the one big disadvantage if you only focus on one product at a time is that you might lose sight of the big picture. Because usually, I mean, you might, for example, the VLC community, there's one very successful product, and it is fine for them to just focus on that product because it's a big goal in itself. But if you focus on only smaller products then they might, yeah, you might lose sight of your big picture. And motivation might not extend beyond the product. So if, as Jan said, you really do it like, okay, I want to do that. And if it's good, then I'm done. Then people might just lose interest unless they find a new product to work on. And yeah, if you do it really properly, the whole product management and design thing, then some contributors might feel overly controlled because you tell them, well, this does not help the user. You should not do it. And then people might say, but I want to do it. And then, yeah, this may create conflict. That's the end. One of the things that, the reason we brought it up as a twofer, more or less, why we're both here, is that the great upside with both of these things is that they can be intermingled in many ways. The greatest upside with them is compared to having no principle at all. And I'm not saying kitty and all, everyone here don't have that. But having no vision, having no principle at all is worse. It's always worse. If you think movement, for example, is a bit of a hippie thing, or a product is a bit of a business man-y thing, sure, but it's better than having nothing. And both of these can be intermingled easily. They can be changed. They can be moved around. They can be combined easily. Different people within the same group can do different things. And the relevant thing that we wanted to talk about, these are just two methods, by the way. But we need, as kerees specifically, we need these things. We need these visions. We need an ideal how to move forward, how to expand. And if it's the hippie method, I don't want to call it the hippie method, but it is the hippie method. If it's the hippie method, then that's fine. That's awesome. If it's the business man-y effort, I don't want to call it that either, then that's fine too. But we need something. We need something to move forward. Otherwise, we're going to be stuck in the same malaise, the same constant. What are we doing right now? There are a lot of talks going on here. And later this week about vision, about ideas how to drive KD forward. I've talked a lot about with individual people out in the corridors. Everyone has an opinion. But KD specifically, what we absolutely need and what every project needs is to get off our arses and define something. That's the important bit. It doesn't have to be perfect. It just has to be, because otherwise we're just floundering. I think that sums it up. Thank you for us. Small applause. Cheers. Are there any questions? We have a few minutes for questions. Not much. Do you think it refers somehow also to the bazaar and cathedral? If I listen to you, I think the movement is kind of the cathedral thing. Yeah, sure. I don't mind. The thing is for me, is that I would never be completely strict with either method, I think. But something has to be. And if, for example, people will say, oh, KD are such hippies doing this thing or being very excluding, because we have this grand goal and we kick people out, that's better than nothing. And yeah, it has connotations that might not be grand and perfect, but it'll be good. It'll be awesome. Any other questions? No. Then let's have some snacks. Awesome. Thank you all. Thank you.