So, good morning, it's me again. I'm very glad to have to introduce Peter Hintjens.

He has been, he's a long-term community activist and on many fronts, he fought against software patents. He did like on an organization level and apparently, as you know, he also succeeded. And he's also the main, one of the main guys behind ZeroMQ, both developing-wise and designing-wise.

He has written books, Culture and Empire. He probably likes to show it. And he's also thinking about, apart from developing like questions about and philosophical questions about systems, how to organize them,

also on the society level but also on the technical level and consulting companies on distributed systems and so on. And what we're doing here is that Peter is going to give some input. And this is going to be a bit of a different format

than the keynotes we saw in the last days in that you are invited very soon to walk up to the microphones and to enter a discussion. So, Peter has, of course, a lot of prepared thoughts but he's very happy to actually enter some kind of more interactive discussion.

Please, when we do that, try to restrain yourself to something like 30 seconds. Think of it like a tweet or something like this. Maybe also 60 seconds sometimes if you want to present something more but please don't go over that. And Peter's going to repeat what he understood

from you then and otherwise, I think we're going to have an interesting discussion and so I give the word to Peter. Thank you, Holger. Thank you very much. EuroPython, you guys are awesome. So, I'm the zero MQ guy, as they call me.

It's a tough community, I founded it but I made a bad patch and I got this the other day. So, you know, tough. Actually, this came from a couple of Ruby guys who were annoyed I came to EuroPython. It's a funny community, the zero MQ community. I've done many community projects, many

and it's the first one large community project where there's no fighting and no arguing and people will argue with me a little bit but in zero MQ community, if you look at the mailing list you won't find flame wars, you won't find people with any kind of emotional anxiety or it's basically very pragmatic, straightforward,

walking through what happens. This is very unusual in a large project. Zero MQ is actually a project of projects. I looked at the GitHub organization. There are about 675 projects that use zero MQ in a title somewhere in GitHub.

It's about, I think, 50 in the organization. It's about half a million lines of code with about 400 contributors. It's been about seven years building this up. I'll give you these figures just to tell you how big it is and how active it is. One of my projects is a C binding that has another 10 languages on top that use it and wrap it.

I think it's D, Q, OOC, OCaml, CL, two, of course, two Ruby bindings on top. They can never agree, those guys. And the Python binding on top of that. And the core zero MQ library is about 33,000 lines of code so it's about 15, 17% of the whole project.

And this is a big project. It's successful. And yet we don't really argue or fight. Also, we don't do design. We don't do meetings. We don't do IRC meetings. We barely have meetups anymore. I used to organize these meetups like two, three weekends where we'd discuss what come in the next version. We stopped doing all of that.

Now and then we have beer. That's about it. We don't do meetings on IRC. We don't do wish lists. We don't have roadmaps. There's barely anyone in charge even. I mean, I'm kind of in charge but I'm mostly busy looking after my kids at the back there. My three kids. I brought them with me to come and see Berlin.

And you've been very good with them. I was kind of a bit afraid what would happen but they've been good. Thanks for that. So this is a very strange community. Unusual in many ways.

And it's not accidental. Now this has happened over time. We've developed over time a process and a way of working very deliberately to get away from certain problems. Now what we do is we solve problems. And all of our problems somehow came from centralization. And so the theme of this talk today is about this kind of conflict and fight

between centralization, which we as engineers, we love. We love the feeling of being God and creating with our brain something miraculous and new. And that requires coercion. It requires power. It requires control. And yet the natural world, our economies,

everything we live in is about decentralization, giving up control. If you look at a city like Berlin or London or New York or Brussels or any village even, who runs the food supply system? Well, nobody. It's a completely decentralized system. I think Berlin has maybe two days worth of food

in the pipeline. And yet we all eat every day. We have lovely ice cream and drinks and it's all magically working. And no one is in charge. And so our most essential systems are decentralized with nobody in charge. And we know from the history of Europe that when someone organizes a central planning committee, the results are disastrous, right?

So why do we accept that in our software engineering projects? Okay, if you look at the ZeroMQ community as a kind of a worked example of this, what you will see is a decentralized,

asynchronous, concurrent, message-driven, lock-free process with no one really in charge of it. Where we came from before was a very conventional, single-threaded, highly locked shared state.

Very serial, not very much concurrently going on with no message passing. Process run by a few guys. And that's a process that you will know from most of your work and most of your projects. A very planned system, possibly a hierarchy with a very clear flow of power from top to bottom.

Flow of orders and executions. Most of you in companies you work in will recognize this as your daily environment, right? How many people work in companies and are employees and don't have this model? Well, I see very few hands, a few, very few. And probably you're running your own companies at that point or in charge in some way.

And when you scale to more than a few friends, you'll find that you somehow need this level of coercion. So, stepping back from controlling what we make, allowing people to compete and make freely, not deciding what the future will bring but allowing the future to develop naturally

and organically out of problems is kind of difficult. And yet, if you can't do that, where's the future? Now, let's look at the future of computing specifically. We come from a past where computers are very, very expensive. We all remember IBM's famous market study of 50 mainframes as a global market.

We go to a future where computers are dirt cheap. They literally cost less than dirt. And there's trillions of them. And every year, the price falls and the number of computers rises. And so the future of computing is distributed, whether you will like it or not. And if, as engineers, we can't build successful,

scalable, distributed software, we don't have a job in five or 10 or 20 years' time. It's simply a matter of time, not of if but of when. So as software engineers, we should be asking the questions, how do we build successful distributed systems?

That's the future of our industry. The answer, apparently, and this is my best experience, is kind of weird. The answer is, we can't actually build successful systems. We can only grow them. And if you look at the examples that we have

of massively successful decentralized systems, they've all been grown organically. Apparently, without planning. The internet is the best example. Now, who built the internet? Nobody built it. What is the internet? We don't even know. Where is the internet? It's in a box on my table. Don't break it, all right?

And this mysterious thing, it defines our lives and is built by nobody or everybody. Has grown over time. Can anyone tell me what the internet actually is? Someone give me a one-liner tweet for the internet. Let's have our first volunteer. The first person to give this a decent answer

wins this book right now. Okay. And this book is worth it. The microphone is there, sir. You have to move the microphone. Someone, what is the internet? A network of autonomous networks. Nah, I like it, but it's not good enough. Someone else. Sorry, I have the microphone, I decide.

It's just a communication channel. No, not good enough. Sorry, it's brave to stand up, but still, somebody else. The internet. The internet. You know the answer. When I say to you, you'll be like, oh, yes, of course, come on. Everything that's between computers.

It's the, sorry? Everything that's between computers. Everything between computers. No, we're not satisfied, are we? It's a living being. It's a living being. We're getting very meta here. No, come on. Let's... Whoops. Substrate of the human race.

Okay. A substrate, I will make it easy. I will just give you the answer and keep the book for myself. I like my own books. The internet is a stack of protocols. Okay? It's very dry and academic and legal-ish and whatever. RFCs are the internet. The internet is a stack of RFCs.

We have now thousands of RFCs. It used to be only a handful of you, doesn't it? The very first RFC, RFC 001, I believe is an RFC for writing RFCs. Or it got very close, maybe number two. That is the internet. It's a bunch of contracts.

What do we think? Does he get the book? Okay. Let's give the gentleman the book. Or you can come and get it here. Okay.

Now, the fun thing to note about the internet is that when it was invented, which it wasn't, when it was born, which is more accurate, there were very many companies, very many large companies with existing similar systems. It wasn't like there was nothing

and then some guys in the garage said, oh, let's make some networking. Come on. The biggest companies in the world had spent billions in making networks. And this went on as long as, who was still, you guys are all very young, ladies and gentlemen. But I remember 1995.

And I remember Windows 95, which came out without networking. And then they brought networking and they called it MSN 1.0. And that was Microsoft's network. And it didn't even talk to the internet, which they regarded as a second class thing, kind of a gypsy nerd rubbish.

And MSN 1.0 did not talk to the internet. And we had AOL. We had IBM with their LU 6.2 and all this rubbish. It wasn't that the internet came in a void. It was competing against the largest companies in the world with the biggest budgets and the most brilliant engineers. And the most power.

And it destroyed them without even blinking. It destroyed them without even thinking about it twice. So we're talking here about very significant competitive advantage. And everybody whose job it was to build LU 6.2 bridges had to either learn something else or go on a retirement.

There was no future in IBM networking or even in novel networking in the end. And certainly not in MSN. And AOL only because they gave away lots of free CDs and spammed us all for years. And the internet, the stupid little RFCs became world power.

They became a superpower. And yet nobody, nobody really invested in that huge amounts of money. There was no one backing it. There was no Steve Jobs or Bill Gates behind that. That should demonstrate to the power of the market when it's enabled by accurate contracts, which is what RFCs are.

Okay. And so we've all lived through this growth of this superpower technology grown by competition and collaboration with actually very few fights and arguments. Most of the fights and arguments were from the losers when they discovered they couldn't hijack the process. Oh, you can't use our patented email.

Oh damn. Oh, we can't capture this and this. Most of the actual honest work was done by any fighting argument at all. And so we all know this, but we kind of ignore it. And we come back to the old model of trying to make stuff by power, right? It's very ironic how we can, in our minds, have these two completely contradictory models of operation.

We all depend on the one, yet we all make the other. And so let me throw you one of these a little bit argumentative, controversial statements I like to make about the nature of good software.

All those IBM engineers and even most of the Microsoft engineers and certainly novel engineers all made good software. They were all very good programmers. They were all highly selected, good degrees in computer science. They all made fantastic scalable algorithms and everything else perfect. All their stuff was thrown out, right?

As is most software. So what defines good software? And I'll argue that most of us in our industry have a completely wrong understanding of that. It's one of our biggest weaknesses is that we do not understand what quality is in software. We fundamentally got it wrong. And that wrong assumption drives us to extraordinary mistakes.

A lot of what we did in the ZeroMQ community was to correct that big misunderstanding, what I consider to be a big misunderstanding about software quality. And so the old model of collaboration in ZeroMQ community was, I'll explain how it worked. There was a guy who was the main author.

He was the main author. He would write code, be very clever, a genius man. There was a friend of his who was a main maintainer and he could understand Git and branches and merges and packages and make files and auto conf and all this very complex stuff. And he could talk to this man here. The brains would synchronize with this amazing shared state,

which involved lots of beer and meetings in strange locations. And these two were a very good team. Made amazingly good software, which was very fast and didn't crash and was good, it was amazing. And then there's all these other guys here who were like using it and contributing it. But the contributions had to go by a mailing list

to one of these two guys here who would then look at the mailing list patches and say, we don't like your patch. We don't agree with your patch. We think your patch is, we don't like it. And you know, it's basically, it's our baby, so we don't like it. Oh, we'll think about it. Your code's badly indented, no.

And so there was this very strange communication process based on a pure monopoly of power. It was a purely classic, very serial, single-threaded, highly blocking, synchronous process based on this fuzzy communication that nobody could ever track. No one ever knew what the basis was for a decision.

The users had no idea. And I think after I had my fourth or fifth patch rejected, and I'm like, why is my stuff being rejected? I'm trying to contribute here. I mean, of course I felt very hurt. I cuddled my babies and said, this is terrible. But what I really felt was like, if I'm getting my stuff rejected, what about other people?

This sucks. And this was my money in the table, so I was kind of annoyed as well, as a businessman. And that wasn't the worst part. The worst part was that what came out of this process was really rubbish. I mean, it was really bad. It was actually sad.

It took us like six months to make a stable release. We would spend six months just removing bugs from raw code. And we would throw this stuff at users who would say, oh, it's better than being stabbed in the eye with a fork, but it's really, why is this stuff so raw? Why is it so immature? Why is it so much untested code in this code base?

Because this guy wrote code. He was a very good engineer. He liked to write code. Engineers write code. And as we went through this kind of process of maturing the code base, we discovered that a lot of the code that was in there was never actually used. It was written for no reason

except that the person who wrote it thought in his opinion that people might need it one day. Or it was fun to write it. Or he absolutely had to make it. He was convinced that he had to make it, but he was wrong. We're often wrong as humans. And so what came out at the end of the pipeline, and if you look at the first versions of ZeroMQ,

they're kind of embarrassing. I mean, they're very good in certain ways, but they're obviously completely wrong. That's why nobody uses them today. It's kind of obvious. And over time, we've gotten packages and designs that have emerged which are more and more and more accurate.

That's why people are using them. And the current process is very strange. Basically, you send a pull request to master, and I'll merge it. And that's it. It's really that simple. It's not quite that simple. There's a little bit of filtering, of insanity,

but not much. And even insanity, I tend to welcome and embrace it and say, if you're really crazy enough to send me a completely insane pull request, I kind of like your character. Come and join us. You know, it's always good to have diversity. People who agree with me aren't very useful to me in my projects. People who argue with me are always more valuable.

They'll always challenge my perspective. And often, they'll be right, and I'll be wrong, in fact. And maybe their patch isn't the right patch, but their presence is the right presence. And now you get to seeing the software not as a quality in terms of how fast

or how beautiful, but in terms of how accurate and how relevant, which is a completely different thing, right? One person or a small team can write very high-quality software in terms of its technical characteristics, but they are incompetent in writing software that is relevant to a broad market.

And in fact, only the market can write that software. And so to make successful, large systems, you need to bring in successfully the large market to make those systems, okay? And so when you're building software which has to be distributed,

which, as I explained, the future does demand, you need to bring in communities that are distributed, otherwise you can't build those systems. No one's arguing with me here. The microphones are there. I should maybe give some diplomatic pauses and then people just stand up and...

Okay, any time you like, just raise your hands and say, Peter, this stuff you're saying is ludicrous. You know, you've heard of Conway's Law. Conway's Law is popular. It says that as an organization, we build systems that mirror our communication patterns in the organization. If we are a top-down hierarchy

with a very coercive use of power and a very one-way learning where you learn at university, you apply in your job and that's it, then the software we make will look like that. It will be very big, monolithic hierarchy with the flow of power from top to bottom and basically very fragile over time.

That's Microsoft Windows. We know how it works and how it dies. If we are a decentralized organization with nobody really in charge, with very strong contracts between different pieces, between different layers, with a very smooth process for improving those contracts,

where the contracts let us compete very honestly, then what we build in the end is a software system based on contracts with nobody really in charge, with competition between pieces, a very different perspective. Gentlemen, Holger, I believe.

I'm just going here because this is not about moderating. I'm just having a question. So what you're describing basically in the process that you established with ZeroMQ sounds... Could you repeat the question? What you described with the process with ZeroMQ, that sounds like a coding wiki, right?

So basically people contribute code and you look at it and if it doesn't look somewhat too crazy or so, you'll merge it. So how do you make sure that if you release... No, not make sure. What is the experience then when you release something

in terms of breakage? How do you deal with tests and things like this? Like these are practical concerns, right? Okay, so the question is, how do you come back to quality in a certain level? What is your testable status for your deliverable? I'll answer the question. I'll first make a comment about what happened when we moved to our process.

It was about two years ago, I believe. Two and a half years ago. And actually my model when I explained to people was Wikipedia. I said, I want to get as close as I can to Wikipedia and people said, Peter, you're insane. And I'm like, I might be insane, but I know what I'm talking about with this here. My goal is to bring in the most possible contributors

and give them the most freedom to make good stuff. And when there are mistakes, to detect them and fix them as fast as possible. So low latency. I don't want six month cycles. I want six hour cycles or six minute cycles. And making mistakes is fine. It's one of these fallacies of distributed computing

is that the world is perfect, but physics is not perfect. There's always lag, there's vulnerabilities, things break, things disappear. People make mistakes. People make big and small mistakes. And the trick is to let people make mistakes, to learn from them, not to punish them and let them or others detect and fix those mistakes very rapidly.

Wikipedia does this, obviously. And it's been criticized for decades, well, at least years, as being full of trolls and vandals. But if you look at it, what you see is the very successful accumulation of very accurate knowledge over time, more and more and more and more, unstoppably. It's never had any real crisis.

And that's because although you can vandalize any page, you can also fix any vandalization very quickly. And so that was my kind of ideal model for the code base was where I could almost get the master

branches to be production quality almost all the time. And that's what we got today. And today, most of my work is always based off master on many projects in the Zero MQ community. We don't use the stable releases anymore. We still make them for customers because customers like that. But we get to the point now where the master branch is quality, usable.

And how do we define usability? And I'm sorry for making you wait, sir. How do we define this stuff is reliable, trustable? What we do is we let the users, of course, contribute test cases. And the test cases are a contract. And when we build, and we have Travis CI running on this all the time,

if you make a change that breaks a test, it shows right away in red, there's an error. This stuff is broken. That's not a fatal mistake. It's just a mistake. Somebody can fix it, but it shows right away. So the thing about contracts, contracts by themselves aren't enough. The contracts must be testable.

And the faster and the more automatic they can be tested, the better. This is why RFCs that are protocols can be tested. If you have a web server and you write it and it doesn't perform, you can test that with web clients. People do this all the time. That's how you check it. So every patch goes on master, gets committed or merged, tests get run.

If it's broken master, we know about it. And the test cases have grown and grown and grown and grown. As they were applied systematically as a quality measure, they simply grew to cover everything. And now they cover the whole API. And that seems to work very well. I think you're first, sir. Go for it.

Technically, I would agree to almost everything you said, but somehow I thought, are you doing a parody? So because we are here on open source conference where we have a dictator for lifetime, and the same with Linux or Linux at the first, Mr. Tobalt was very dominant in the first phase.

So maybe this dominance with Linux or even now with Python is somehow not the best. I talked to people who said that Guido did not accept something, whatever. And the third argument is Wikipedia is not a free thing.

You can vandalize pages and they are corrected. But the problem is some political pages are in the hand of left-wing people who have non-democratic views, especially they are against Nazis, that means against all Germans who have a different opinion than left-wing people.

So there is no democracy. You cannot even point to somebody on Wikipedia and he is killed from the page. So let's take these points one by one. So the first point is about the role of a benevolent dictator in a project, open source project. The second question is about controversy in knowledge

and propaganda and so on. Okay, we'll take the second point first. The thing about software is that you don't really have controversy in perspective and points of view. We're not doing journalism, luckily. And I think with Wikipedia there is this kind of, it covers a very broad scale. It does cover very old,

uncontroversial subjects to journalism. And there is always going to be a part of Wikipedia which is extraordinarily controversial. If you're trying to get a single point of view, you cannot in those pages. However, that controversy has to go somewhere, may as well happen, may as well be documented

and may as well be captured in some place and Wikipedia serves for that purpose. If this is a real controversy, let it be documented. What we have in the open source community when we have controversy is people, they fork projects and they make competing projects. So we let people make five packages doing the same thing if they're arguing about the approach.

And then the customers can choose. And effectively you get the market saying, I prefer that perspective, I prefer that point of view. And that's fine. So we try to, of course we don't say people should have one point of view or there should be one single way of doing things or thinking about things. When there's competition of ideas

and when there's conflict, let the market decide, make many. And give people the freedom to create around that. And now you come to the role of the dictator. Now I'm probably the largest contributor to ZeroMQ. I'm still programming all the time. But I'm not really the one who wrote it. There was a team that wrote it. Mostly Martin Sustek wrote the first generations of it.

My role has mostly been lawyer. It's mostly been writing RFCs and problem solving. So mostly what I've done over the years is use it, write about it, and from the perspective of the users, solve the problems in the process.

Rather than trying to push through any design ideology or push through any kind of technical vision. I have no technical vision. If I do, I put it away. It's mostly junk. When I've made projects in the past with lots of technical vision, they were garbage. Very fast, beautifully documented, well written garbage.

And so when I have technical vision, I'm very skeptical of it. And I put it away and I try to get the market to tell me what to actually make. And so I teach people that same process. Kind of modesty, which is hard for me really. I think Holger has something. Oh no, one more question sir, go for it.

Hi, is this on? Yes it is. Hi, so this is a sort of a political question rather than a technical one. Because we're talking about the way you organize people and resources and where the power flows and things like that. And it strikes me that the perspective

that you're talking about is anarchic. And I don't mean that in the, we're all gonna rip our clothes off and hit each other over the head with a club. I mean the political philosophy of anarchy, which is, I guess I'd summarize as being the people who should make the decision should be closest to the ones who are actually going to be doing the stuff that is the effect of that decision.

So it's a very bottom up rather than top down way of doing, organizing things. My question then is, did that outlook, and perhaps I'm wrong in putting that outlook on you, did that outlook emerge from the bottom

or did that start because you thought, because that's already an existing perspective that you have and the way Zero MQ has developed in the way that you've described in terms of the way the project is organized. Is that more a reflection of you in your outlook or the group's outlook?

I think in the terms of anarchy, it's what you call a philosophical anarchy where there is authority, but anyone can choose the authority they like best. So you could model this in terms of, you do have countries and governments, but you can move to any country you like, and they're infinitely big. And if you don't like the government

and the tax systems and the infrastructure, move somewhere else. So there is authority and there has to be authority. The reason is if you're trying to work with contracts and base your collaboration around contracts, when there's conflict, when someone, people cheat and people do cheat,

who enforces the contracts? Where's your tribunal? Where's your court? You need a monopoly of power to stop people cheating. So an anarchistic system which doesn't take into account that you have a small percentage of determined cheats, determined cheats, people who are either

predisposed to always cheating, maybe they're psychopathic by nature and they will always cheat out of born talent, or they will be opportunistic cheats who see money on the table and who say, ha ha, I can steal the money now. I'll put my morals aside for a few days and cheat. Those people will be present

and they will do great damage to communities, like really, really serious damage. And I've been in communities, large communities, which were torn apart by a few cheats, literally destroyed the work of thousands of people. And it's a terrible thing to see. And one of those was in our anti-patent fight,

the FFII, which I was president of, and I was trying to run this organization by consensus and there were a few guys in the organization who were determined to cheat. And because I didn't really have the moral authority of being the founder, I couldn't tell them to stop. And I couldn't convince them to stop. And it tore the organization into pieces. It was a terrible thing.

So I'm very pragmatic about identifying sources of conflict and sources of damage to other people's work and stopping that by any means necessary, including real violence if I have to. I'll be very brutal to people I consider to be a threat to people I consider to be valuable to each other.

So it's not anarchism in the sense of, hey, let's all do what we like. That doesn't work in my experience. But the authority is there to protect, not to attack. And it's there to protect the work of the collective. If you read my book, which you should, the book is very good, I like the book.

And the book came out of my work in politics and my work to organize people for politics. And I was trying to explain this to others, how to organize and how to build communities for political ends.

And my sister who's a professor in political science says, oh, you're a Marxist. I always knew you're a Marxist. I'm not a Marxist. I'm a free market, I'm a free Marxist. I'm an Adam Smith. I believe in the free market and the beauty of the market. She's like, I know you're a Marxist. Yeah, my brother's a Marxist. I'm like, okay, I'm a Marxist.

I didn't grow up to be a Marxist. I consider myself to be right wing capitalist. I'm a businessman, I like to make money. But it turns out the best way to make money is to make many people happy. And it turns out that requires a good efficient market with good rules and with good authority and we come to certain forms of anarchism. No, I didn't invent these words, so.

It's funny that you just mentioned that you believe in the Adam Smith theory about the invisible end because I think what you're missing in your view is that behind power there is people. And I want to ask how many women is in this room

right now because we have to fight our way in IT and we have to justify how we are doing that. And because I was in the Django Girls Project, I don't know how it was in the Python Society, how it's worked for women to express their point of view.

But in France, somebody tried to do something like that and was thrown out. So I think you are missing that in this room there are many male white almost and that behind power there is people and there is this, maybe you think that you don't have any oriented view or stuff like that but you are in fact oriented.

And when you choose to have people doing funny codes, you choose to have this guy but maybe it's a threat for others. Maybe you are missing that behind power there is people. So thank you for your question. I guess to paraphrase what you're asking for is how this kind of, I guess a fairly pragmatic process

takes into account diversity, whether it be diversity of origin or gender or religion or culture, whatever. I'm not going to talk about women in software, that's a different issue and that's not my expertise. I'm a white man, I cannot talk about diversity very much.

I grew up in many countries, I think my mother language when I was young was Swahili as much as it was English. My wife is Congolese, I know about culture diversity but I can't talk for women. What I can talk about is the work we've done to remove the preconceptions that filter out contributions.

And I don't know how successful it's been but a lot of the bias that people might have towards a contributor because they know who they are. You're my friend, therefore I like your patches. I don't know who you are, therefore I reject them. We've taken away.

If you look at our process, there is no basis for discrimination in the process. However, what I've also noticed is that our contributors are more and more dominantly male, not from any one country. We're very around the world, very geographically diverse but I believe the process is a fairly brutal process

in certain ways, fairly competitive and may have a certain communication pattern that feels pretty masculine, that's possible. If that's the case then I'm happy to get patches and changes and suggestions. When it comes to the people in the invisible hand

in the market, what I think is observable but I think the basis for economics is that we make money, we make a market by specializing and by trading. That's to say that diversity doesn't have to mean we all do the same thing.

We can do many different things and work together and having different talents in our minds makes us valuable, right? That's to say difference is valuable. Difference is what makes us valuable as individuals. Being different from the people is a valuable thing, should be a valuable thing. If we are free to use that difference to trade, to connect to people, if there's no barriers

to communication or barriers to moving to different place to work, whatever. But more than that I can't really give. It's funny that you say that you have no bias but when Wikipedia made a survey, most of the males said there is no sexism

and you asked the woman and all the women said, yeah, there is sexism. So it's funny that you say that there is no bias. Of course I'm biased. I know I'm biased by definition but I can't see my own bias. I couldn't tell you where it is. I feel that I grew up in, I have four sisters and I grew up in a family where we were, we were, you know, but of course I'm biased. But everybody in this room is biased in different ways.

The no one on earth is not biased by their own perception of the world. And I don't even, I suspect that gender bias isn't even the largest bias. We have age bias, we have language bias, we have so many biases. So, you know, that's kind of the reality we live in. I don't know how to make that into, you know, more happiness for people except to make more doors open

and more opportunity for people to contribute in different ways. Yeah. But thank you for that question. Okay, so this is the two last questions. We have five minutes left and we have to close, right? He started first. He came first.

Okay. Okay. My question, you said you thought positively about the market deciding about their own software and not one person making all the decisions. I want to quote, I want to say a quote from the book, The Shallows. The brighter the system, the dummier the user.

You think when the people decide about their software, will they always choose the best software for their own benefit? So what's interesting about, we're talking about the ability of the market to make decisions. Yes. And what I think is most interesting is not so much about the solution for a particular problem.

There are many solutions for problems and we can always move around and change solutions. What's most interesting and what's most valuable and what defines, come back to quality in software is choosing the right problems and solving the right problems and solving the biggest problems first.

Now, once you've identified the right problem to solve, of course you can throw away solutions and the solutions come with new solutions. And what we really depend on our community for, what we bet on the community is to identify the right problems and the biggest problems and those we solve.

And then the solutions can come and go over time. They're basically much trash, right? Okay. Does that answer your question? Well, to a certain extent, maybe I can say it in a more concrete terms. Like when people choose the system that is most easy and most, that things be on their behalf. So for example, if ease of use is more important than performance,

that's a valid choice. I mean, everyone is making a bet on their own. When they choose software, they're betting their time and money on that. And of course that's valid. You can't say, no, no, I know better than you, but that's your business, but I know better than you. That doesn't work. So just the quote was about

that their brains will function less over time. That was the negative things that they may choose. Okay. Thank you. Yes. Hello everybody. Yes. I'm listening to you. And my feeling is that we just compare two times of management, directive management

and participative management. And my question is quite easy. Is it not just a question of resources? I mean, when we speak about Linux, it was the beginning. You have to, you have few resources and then you have to go straight on.

And it was not so easy to have enough resources to just to listen to the market because the market was just at the beginning. When we are now at that time in two, today, the community are much larger.

And for that reason, resources is much easier to bring. And for projects, it's much easier to have a participative management now. Okay, so the question is whether this is different management styles, yes or no, and whether it's a question of size or not. There is a management consultant a long time ago,

a guy called Argyris. He has two models, you can research this. Argyris Model 1, Argyris Model 2. And it's worth reading about. And this is exactly the dichotomy. Model 1 is a top-down learning process. You learn in university, you learn in workshops, you apply in your job. And Model 2 is a circular system where you learn as you work and you apply that all the way around.

It's not about scale, though. Those models apply whether you're a team of five or 5,000, both models. They're quite inconsistent. You can't make a shift from one to the other very easily. They're competing models. But they are two management styles, yes, most definitely. And it's not my invention. I mean, no one invents anything. We just reuse stuff where we discover the stuff

that people have been doing for a long time. There are companies which operate on Model 2 very successfully. And internally, they are very fluid and they look very strange, but they're very successful. And most companies still operate on Model 1, okay? But it's not about size. When I began making the community with Zero MQ,

the goal was from the very beginning was to build this kind of learning, building by learning rather than building by dogma and by design. Just to remark, I think it's not only human resources but key resources. I think we have to finish there, I'm sorry. I mean, Peter is also going to be around afterwards

so there's a discussion. One last, 20 seconds. We are half convinced here that this decentralized organization works. I mean, GIT is decentralized. We do have contracts through conflicts, the kind of things, so we are halfway there. I was listening to you and was thinking, this guy needs to go to this big economic firm in the Alp

where Bill Gates used to go and all the big leaders used to go. Because the people in power right now, they need to hear you. No, they don't. And I don't want to talk to them. I mean, you're the people I want to talk to. Nobody else.

Okay, they can read my book. I have a few copies for sale if you want some. I'll sign them. Thank you all very much for being here today. Thank you, Peter. Thank you, Holger.