Rethinking Open Source in the Era of Cloud & Machine Learning Keynote

Speaker 1 [00:03]

move this a little bit closer. How's this? Everyone hear me in the back okay? Awesome. Well thank you for the very kind introduction Alex. I really do appreciate that and I appreciate being here. I love coming here to Berlin. I love Germany and I'm also appreciative all of you have shown up here at nine in the morning for my keynote. So we're gonna have a good time. So my talk is about rethinking open source in the era of cloud and machine learning. And for me, one of the... This is a topic that's, of course, very near and dear to my heart. And I think over the last couple of years, we've seen a tremendous amount of conversation happening in the world around open source, around sustainability, and all these things. And they're great. We need to be having more of these conversations. But as I go through these conversations, as I read the blog posts and listen to the podcast and everything, I feel like there's some essential things that are missing in the conversation. And specifically, there's some unique aspects of the conversation that we can drive from within the data science community, and specifically within the Python data science community. And so I'll go through that whole arc over the course of the next, I think I have about 90 minutes, is that correct? 45. Oh, okay. So over the next 45 minutes. So we'll get through it here. Like I said, these are common. I'm going to assume this is mine. Oh, we're off to a great start. All right. this is great. I'm actually finally over jet lag, but no, it's fine. Did you do something to it? What did you do to your coffee that makes them undrinkable? All right. So are we recording? Is this being recorded? Okay. You can edit that first part out. So anyway, we commonly talk about sustainability, right? Maintainer burnout, commercial users. And one thing that's interesting, I was talking to a friend of mine and he said, you know, what's really annoying now is that people show up on github and um as opposed to being like hey you did a cool project they're like hey i need to use this piece of crap for my job and like you need to fix this and and so there's more of that right now i think many people kind of can understand that and then we've been trying to fix these with like uh you know github has the has their support things and there's tidelift and there's patreon and there's you know things that we do at anaconda and there's things that like quant side does and all these different folks are trying to support in our various ways So everyone's trying to tackle these problems. And then we also, of course, have certain kinds of unfortunate behaviors that we see around commercial exploitation. Black? That's too bad. Okay. Thank you. We'll start black. Okay. And then people are even, and so one of the defense mechanisms that's been happening is that open source projects have been starting to actually say, well, you know, maybe we need to change our licenses. We do things that are more defensive in nature. And that makes me sad because I think there's something wonderful about the openness that's in the current sort of licenses and infrastructure and community. So, again, you know, I thought I had a 90-minute talk. Apparently, only 45 minutes. So we're going to have to do this really, really fast. That was a joke, actually. This will be 45 minutes one way or another. So ludicrous speed. So let's just break this down. So let's talk about open source, right? now the the free software folks you know they have that famous term free as in beer or free as in speech um the open source folks don't seem to have quite the same sort of pithy thing but i like the term open better because there's more you can do with it right one way you can look at it is yeah it's a free beer it's it's open here's you know well here's a coffee you just drink it another way to look at it is open means well i can open the file i can open the source code i can go and read the source code. Now that's SciPy. Okay. SciPy is 170,000 lines of Python code has 80,000 lines of Fortran 77. And most terrifyingly, it's got 142 lines of make. So, you know, you can read that source code, but I don't know if you really want to. And even if you do, you haven't read the source code for Firefox or GCC, certainly not for, you know, any of these other TensorFlow, maybe you've read some bits of it, but not the, you know, Gorpi C++ bits. So when we talk about open source, in theory, you know, being able to read the source is really important, right? Everyone talks about all that, but at the end of the day, we're really treating it like a free beer. We just get this free stuff, right? So we have to be honest with ourselves, I think, about what it is, what's the actual value, how we're actually interacting with the open source code. Another way of looking at open, you know, another reason why I like the word open is because you can do more with it. And one of the things you can say is, well, open means open to PRs, open to contribution, right? Well, that's great, but in order to submit a PR, I have to read 170,000 lines of Python to make sure I don't break anything, right? Maybe it's really well-factored, so I'll have to read 2,000 lines of Python to make sure I don't break anything. But that's a pretty big hurdle. And again, how many people drink the free beer versus how many people go and make the beer? Not that many. And we can't lie to ourselves about that relative ratio of contributors versus users. That is what it is. I mean, time has proven that to be the case. How many people here use an open-source web browser firefox chrome anybody how many have submitted a pr to firefox or chrome there you go there's data another way to say is open is not just open to prs but open to ideas i give my feedback right um and that's true you can go to github you can submit your feedback to anybody i mean if you if you buy software they have any piece of software as a support for them you can go make a comment on the app store if you want to you know um so open to ideas in our open source community some projects are more open to ideas than others and certainly if all if we have the same ratio of users submitting ideas to users not contributing code, then the projects can get swamped. So all these theoretical definitions of open sound very nice. And in fact, I've used them in the past. And then, you know, when you really go and hold yourself intellectually honest on this stuff, you're like, well, this is all good. But, you know, we have a very small ratio of people that actually contribute and maintain this stuff. So the thing here is just to set things up, I want to sort of challenge you and encourage thinking about open source as more than just licenses, but really thinking about the basis of empowering people and communities to innovate. And this is sort of the underlying concept I'm going to be carrying through the rest of the talk. I think open source software is best at aligning users and customers and innovators, all of those. That's my key idea. Not that open source is about a particular license, not that, oh, anyone can go submit a PR because very few people do. It's really actually about empowerment and alignment. And I'll take that all the way through to the very end. One thing also that we should think about is that in modern day and age, software and the code is actually, because of the nature of open source, because GitHub has made coding so social, what we have now is an era where the software itself is less of the important thing relative to the APIs that it establishes. I don't know how many people were coding like 20 years ago before we had a lot of social coding but you would submit patches if you participate in open source you'd be on mailing lists or Usenet you would submit patches via diffs but you would build larger and larger software systems and you would work on a system for many many years especially if you're commercially employed you'd go work on some like electromagnetic solver or you'd work on some piece of like you know 3D graphics software and you'd be doing that for 10-15 years but actually more and more now people are using these open source frameworks because they are open they do so much capability there's so much around like open source frameworks like blender open source frameworks like react you know all of these different larger pieces of frameworks the open source middleware thing has really taken root so fewer projects or monoliths more bolt on lots of little frameworks to make a thing happen and one thing to be aware of for younger developers is that this is actually, this is kind of the uberfication of the gigification of the software industry. Because it used to be that if you spent 15 years working on Monolith, you could really polish that thing down. It'd be really nice. But then you'd also become very irreplaceable, right? But if we build them out of these modular, relatively fungible software middleware pieces, I can go out and say, I need 10 React developers. I need three Django developers and get 80% of what I need to then do my work. I'm not saying it's a good thing or a bad thing. I'm just saying this is a dynamic that's happening in the industry. Maybe it is good. Maybe it means that the cost of production of software is actually cheaper. But this is something that materially impacts people's jobs. And it's really tied to the same shift, moving from code to privileging APIs. And one thing about this that I will point out is that there's a darker pattern in the industry, which is that people will release APIs and get people hooked on those APIs. Oh, you want some middleware? Here's some middleware for you. Oh, you want a prediction API? Here's a prediction API. And now your code is stuck on that particular API. Now you're tied to that particular set of services and that particular way of doing things. So when we look at in the last, you know, I think the last year or so, you know, Mongo, Redis, CockroachDB, some Timescale, Elastic, all these folks have been, they've found their open source. Well, their open source got taken up by, you know, commercial cloud vendors and produced as commercial services on those clouds. And everyone, you know, there's a lot of wringing of hands about, oh, open source has this sustainability problem. What happens when a big player like Amazon come along and swoop in and take all this open source code from these hardworking contributors and make it their own? And actually, I would say that my thought on this is that this is not actually an open source problem. These are business model problems. Because a lot of these companies, if you look at their open source that they produced, They were a single vendor, open source. They, of course, took contributions in from people on the periphery, but the core vision of the project and the governance model was always housed at a commercial entity. And not out of altruism, but out of strategic business purpose. They wanted people using those APIs, and then their business model was to then monetize that. And they didn't close the back door. They didn't defend that right by explicitly putting in like AGPL or something. They said, well, okay, this is totally BSDM IT license. You can take it and do whatever you want. And Amazon says, okay, we'll take it and do what we want, right? So this is actually a business model problem for these particular companies. Not that I don't have a lot of empathy for the hardworking developers who made all this code and didn't get much from it, but it's just, you know, we should be very clear in our thinking that this is not an ecosystem level problem. It's particular few companies that had business model problems. and it speaks to an underlying truth which is that when we have stable apis when we have open apis because to be very clear these pieces of open source software give rise to open apis when you have open apis they actually represent a kind of utility or commons that um is a marketplace it's a really nice in economics it's called a shelling point it's a meeting ground between um maintainers between you know the people actually have to keep the code from bit rotting all these things between the users of it who just want to consume these things and a different class, which I'll call the innovators, people who want to say, well, this is nice, but gosh, this could structurally be so much better if I did this. So the difference between submitting a small PR or small fix for a little thing to say, oh, this doesn't work with this version of some public API anymore and say, oh, this is really neat, but you know what I want to do? I want to build this whole additional set of capabilities. And now I can do that without having to reproduce everything in this project. There's a quote that, you know, science, so Newton famously said, if I've seen further, it's because I stood on the shoulders of giants. And so that has become, I think, basically the term is science advances because scientists stand on each other's shoulders. And there's a great version of that. It says computer science advances by stepping on each other's toes. And what open source does is allows us to advance by not stepping on each other's toes. It lets us basically climb up this ladder of success of previous projects. So how many of you submitted a contribution to GCC, for instance? I know. But how many of you have benefited from projects that use GCC? Right? All of us. And this is finally open source, open APIs, and not having to reinvent the wheel from scratch every time in a commercial entity. This is what allows that to happen. It's what allows computer science to finally let people stand on each other's shoulders once again. And more importantly, it's about preserving choice. And this is where the free software people are fundamentally correct. It is a matter of choice. It is a matter of agency for the user. And I'll get to that at the end of the talk. So if we look at openness, we say, well, openness is not just about the free beer or the free coffee. And openness is not just about, you know, you can contribute, but no one does. Then we should actually maybe think about different ways of measuring openness tied more to that freedom, tied more to the well-functioning and the smooth functioning of that market. And, you know, here's just, I'm just strawmanning a few ideas here about, you know, maybe if i build a bunch of if i build a running workflow and it sits on top of a bunch of open things but some of them maybe are proprietary open some of them are like open but the the company you know is the only one that can seem to get the thing stood up you know i can sort of look through this whole thing and say you know what would it take for me to reproduce this entire deployment from scratch from bare metal right or what would it cost to change some core schema and how i'm doing something all of these kinds of ways are ways of measuring openness in a non-binary like is it mit license or is it some proprietary license and i think this this orients us correctly in the frame of of thinking about um uh you know the the impact that user user choice how much freedoms the user actually have so then open source build one step above that open source software right i want to talk about this the actual software bits um and there's two i think there's two ways to look at it, or two kinds of open source software that we can look at. And one kind is what I would say is the traditional idea of open source software, whether it's Linux or Emacs, maybe it's Apache, maybe it's Docker, right? Whatever it is, all of these things I would call classical OSS because they're made by devs to scratch devs' itches. Docker is, you know, Linux was a little project. It wasn't really scratching an itch, but it was like, yeah, it kind of was. It was like Linus wanted to play. And then Vim and emacs these are you know there's a whole bunch of stuff in gnu that absolutely was scratching an itch and that was richard solomon saying i need agency i need freedom um i don't want to have to pay some you know at&t or whoever in order to use uh unix on on a computer so they are scratching itches whether they're feature itches whether they're philosophical itches these are devs making stuff for other devs right but in the sci-fi and bi-data world it's kind of different these projects almost every single one of them was made by someone who is not actually a formally trained computer scientist um you know the the there's a saying i forget who it was in our community that said it but they said that the the sci-fi ecosystem advances you know one failed phd at a time right it's people basically trying to avoid having to work on their dissertation uh in the case of numpy actually is more than that i mean travis my co-founder travis oliphant he built numpy and basically failed to get tenure he was on tenure track and then he wasn't actually able to get tenure because he wasn't doing more valuable things like writing papers so um so i would say the sci-fi and the pi data ecosystem has has also been scratched it's about scratching your own itch but python was just good enough for these people to take it and scratch a numerical itch a weird a weird sort of like why why don't you just use matlab or mathematica right why are you this why are you using this weird pearl like thing um and these people laid the groundwork for all that we do today. So there's another way to look at this, and this is something that was communicated to me by our former CEO, Scott Collison, who was at Microsoft, and he did open source work after that. He worked at different companies and started a couple. And at Microsoft, he said, we always felt that open source was great at solving well-known problems. And it's kind of true. A text editor, I mean, how many of you love Emacs? Anybody here loves Emacs? All right. Well, screw you. I like Vim, okay? But actually, I'm just kidding. Let's not get into it. Emacs versus Vim is like worse than Python versus R. Let's just not even get into it. However, what I will say is text editors, like kind of a well-known problem, okay? Like text editors is you can build good ones, you can build sucky ones, but in general, editing a text file is a well-known problem, right? Docker, it chose its own problem to solve in its own way. I wouldn't say it was a well-known problem, but you can sort of maybe understand the sentiment that a lot of devs making stuff for devs, they're solving problems that these devs are like, oh, this is something I need to do all the time. People can see them. And I would say that the data science and the numerical ecosystem, again, in scratching its own itches, it wasn't trying to be way ahead of the curve. It's just doing its own thing. But it turns out the entire world needs all this cool vector computing that they were doing. The entire world needs to do dot products with matrices, although we call them tensors now and make more money. So, you know, it turns out that that just happened to be lucrative. I'm not going to take the luck part out of this equation, but I will say that in that space though, there have been really cool innovative things that the people in the Python community, the open source Julia community, and R, there's been a lot of really great stuff that's been done in our community that is not well-known problems. It's actually innovation. But in both cases, and this is the important thing, whether you're doing innovation, whether you're just pursuing a relatively commoditized and well-understood problem, open source facilitates an open marketplace of ideas, right? And not just ideas, but also some basic economics. If you're looking at solving well-known problems that are commoditized, open source means you can work with lots of other people. So the cost of maintaining this kind of not so innovative, but like important need, that's spread out across millions of people. That's really cool. and then on the innovation side you have a marketplace of ideas so you rather than amortizing costs what you're doing is paralyzing the search but as soon as someone finds something they don't have to go like if someone goes and makes a really cool new visualization library in python they don't have to reinvent numpy right they can take all the data frames they take all the array structures they can take many of the the the work that's already been done by matt plotlib or bokeh or whatever, and build on top of that. So it's a free network exploration, and so in both cases, we have an open marketplace, and that's a really, really cool thing about open source and about the open APIs. And I would actually sort of kind of jumping off that point, I would say that the PyData and the SciPy community for the last 20 years has been at that edge, has been at the vanguard, pushing the art of the possible. I know this is a joined PyCon DE and PyData Berlin, but I will ask how many people here have heard of TensorFlow and how to basically know what it does, right? Good number of people here. How many people here have heard of Theano? Oh, good. Very good. Theano was doing basically the core of what, what TensorFlow does, right? It was doing it 10 years ago. So, you know, this is, this is the kind of thing. And if you look at the performance of things like, you know, Hadoop and the Hadoop file system, you know, we had higher performing things, more performing things in the Python ecosystem many, many years before all that. So the SciPy and the PyDate community has been pushing the art of the puzzle over the last 20 years. One of the things that I've observed in this process is that the successful projects, they're different in the SciPy ecosystem. There's actually a really lovely thing that happens here, which is that the successful projects will tend to limit scope. They don't try to boil the ocean. And they work well with other people. They try to interrupt. So, for instance, Dask, the Dask project, out of the gate, it tried to play well with NumPy and with Pandas. It didn't say, well, you know what, hold on, we're going to make our entire new C library for doing arrays. And also, there's a community aspect, and this kind of prefetches a little bit of what's coming next, but they have reasonable leaders. Like, one of the really nice things about going to SciPy conferences since, like, 2005 is that I like hanging out with the people. like they're really great people um they're not like there's a few who are just like they've got the rough edges but you know whatever who doesn't but but in our community there's not like in general like raging wildfires of toxicity from what i've observed people actually you know a lot of people there's there's um a lot of folks with with families i mean it's very family oriented there's just a lot of really really great stuff happening there and and i think that's something that somehow we've just again lucked into just like the whole doing numerics and numerics are sexy now thing but but it's something that i want to make sure we preserve moving forward in a very intentional way and another comment i would make about this if you think about you know we talk about open source has a sustainability problem oh gosh it's terrible there was actually a point in time when i could literally fit the in the core sci-fi and numpy maintainers in my minivan like if you look at how many people uh and actually because west was the only one doing pandas you might as well throw west on the roof and then you get basically sci-fi numpy and pandas in a Honda minivan. So you can look at that and say, wow, but these people are all like suffering and struggling and trying to make ends meet. Surely the world is getting billions of dollars of value from their software. Why can't it just give them a little bit of just a few million dollars a year, right? You laugh, but that's nothing. That's a rounding error for businesses who get value from this stuff. We all know it. It's true, right? You think how many millions of dollars are thrown at like random Java middleware crap, that would do a lot more for Python. But here's the important thing. If you flip that tragic equation the other way around, if you look at that cloud from the other side, what you see is that actually, it's kind of amazing that a minivan full of people can create billions of dollars of value for the global economy. That's incredible, right? That's better than capitalism. So, and I personally, I think capitalism has its merits, okay? I'm a refugee from communist China. I'm not going to, I'm not really dissing capitalism but but i do this is actually a really deep point it sounds like a punch line but it actually segues to a deeper point moving forward um oh yeah there's of course there's a gif so it is a punch line sorry it is a punch line um uh but but before i get to that next point i want to finish off this section on software and and uh look at a fundamental disconnect that i see in the conversation about open source sustainability in fact we had the panel here yesterday of the you know core python maintainers and contributors and and they're talking about how you know people can get hired to work on python and you have one person here one person there um and again it's the same frustration how many i don't even know billions and billions of dollars every day of value is the world getting from python and we cannot even extract a fraction of a percentage of that to fund the maintainers doing such important work and that disconnect i think is because of a really actually a fairly simple disconnect but it's a deep one when businesses look at open source right how many people think that business is like open source because well i guess i prefetched this didn't i how many people here think that business is like open source because they get free stuff they get free software come on yes right it's a very it's a very straightforward way to look at it like you could pay for oracle or you take this free stuff right people can take free stuff but i think that's actually not actually the case based on what i've seen in trying to sell open source into soft into enterprises um because in the long run businesses pay more to maintain they pay more for developers building on top of that software the licensing costs right a hundred thousand dollars of software sounds like a lot of money but if you're paying one fte like two hundred thousand dollars it's it's it's i mean not rounding error but it's a fraction of it if you have a team of 10 people building on top of some database, if you have 10 FTEs being paid market rates anywhere, you know, in any of the G8 countries, the cost of an Oracle license, the cost of a SAS or MATLAB license is a rounding error. So it's not really about the cost. It's not about the maintenance of the software. It's actually around avoiding lock-in. That's actually one of the architectural decisions that's made. And this is a really odd thing for us in the open source world. We think about, you know, right now we've had so much gnashing of teeth about Python 2 sunset, right? And when do we stop supporting? We get so much hate about, oh, you forked the community and you left Python 2 users behind and now you're moving to Python 3. The thing is that one instance that we took 10 years to get over, it happens every day in enterprise software. Every day there are enterprise vendors calling up their customers saying, you're going to have to pay to move on to the next version. We're not going to support the old version anymore. So the thing about the amount of frustration that we saw in the community around the two to three transition, every piece of enterprise software, every version, every point rev creates that much stress and angst for their customers. And so customers who are tired of this say, well, for this next project, we're not going to use this thing. We're going to use MySQL instead of Oracle, or we're going to use Python instead of proprietary language. And the reason is because then we have control. The enterprises to say we have now sovereignty to decide when I'm going to rev that project, right? If I don't want to move off of some old version of Django, guess what? I can hire some people to continue maintaining that old version until I make the transition on my timelines. That sense of freedom for businesses is incredibly valuable. And that's why really at a C-level and at a SVP level, why businesses are deciding on open source. Now in America, we've been leaning into open source pretty hard. I know here in Europe, some mindsets still have to take some time to change. But this is what I've observed selling enterprise software in the US. Now, the flip side of that, what is the open source community value? What are the values there? Well, it's a gift economy, right? We share with each other, we give our time, we give our energy, we pay out of pocket to travel all over the world to speak at conferences. And we do that because we care. Because there's something about giving that's deeply meaningful and rewarding for us as people. And there's a culture of participation, which is why we get so annoyed when someone shows up entitled on a GitHub issue and says, just fix this, or like, da-da-da-da-da, and like, this still doesn't work for me. It's like, well, okay, like, make it work. You know, why is that my problem all of a sudden? So participation invites participation and reciprocation, a sense of entitlement, free stuff, free support, free code, free, free, free. That is not part of our community values. It's antithetical to our values. That's why it offends us so much. And, of course, there's an aspect of this. Because open source software, many projects, they ship when it's ready. What that does is it shifts the emphasis onto doing the right thing. There's a sense of quality and pride in the craftsmanship around what we do as a software community. And down here, like the second section of this, the idea that the software artifact for the open source community, of course when you first start the code is very important right you're working on the code as community scale the software artifact is a byproduct of a well-functioning community the community isn't there to stress itself out and become dysfunctional just to ship some beta on time and um so i think of it as like a community orchestra right the important thing is actually that we play together we play together well and if we do that then we'll make good music versus the important thing is for us to kill ourselves practicing at night after a full day's work so that we can put on a perfect rendition of some Mozart, you know, concerto. Like these are very different emphasis. But both communities, the open source community and what it values and cherishes and the business community, what they both miss is that software isn't just about the code. Software is actually a relationship because software is not a fixed artifact. Software is, When you look at a particular point, rev, when you look at a particular revision, check-in in the source code, that is just one time point in a stream. And so how that stream evolves, how it flows, that's actually the relationship between the maintainers, between the innovators, between the users, and the customers. All the people who are around that river bend and shape the flow of that river. And so it's not about a particular scoop of water you're taking out of the river. And if we do this right, then we can get these really nice stable patterns where value is coming back into the water just as value is coming out of the water. And I don't want to get kind of too nerding out on this too much because it's still just 9 in the morning. But I really want people to think about this next time. Because many people, I think, will look at pieces of software like it's an artifact. But I want you to think about the software development process, the process itself. Get more into process thinking. that process is the relationship of energies and attention expertise between many different kinds of people and the developers when you start scaling up the software your product management process is more than just scratching my own itch right like for guido and now for the steering council python is much more than just i want to do a cool project or i want to like try to try to build this new language to do this so even for the makers and the innovators there's a different set of energy they get there's product management and product feedback they get from users and that's really important. That actually feeds into the river in a very important way. Another thing that's really important is that the intersection of the business world and the open source world where we have a problem is that open source software really screws up the economic thinking for most people because open source software is not a normal kind of property. It's actually the opposite of property because it's not scarce. It's fundamentally a good that is not rivalrous um and uh and you know the thomas jefferson has this quote uh that intellectual property or that copy left advocates like to use against the argument or suffer freedom folks like to use against copyright which is that you know when my flame lights someone else's candle it doesn't diminish my flame but in the case of open source software it's not just not diminishing it actually amplifies my flame it lets me see further in the room so it's it's this weirdly anti-rivalrous thing. The more you give, the more you get. How many other things, material things in the world can you point to? Metaphysically real things can you point to that have that property? The more I eat of this pie, the less you eat, right? The more air I breathe, the more coffee I drink, the less there is for you, right? So most of the material goods, most economics, we have the supply-demand curve. We have all these things that are set around scarcity mindsets and rivalrous sort of games finite games not infinite ones open source software represents the transition the transcendence of the software activity this intellectual activity into a plane where we clearly can see there's a generative aspect to it the more you give the more you get full stop so thank you um and and you can see that does not work with any kind of normal economic engines or calculus that we have even our terms about return on investment and things like that if your return on investment is not a small percentage but it's actually exponential and infinite what do you do then no you know no bean counter with the spreadsheet is going to be able to figure that out because that's not built into excel they know how to calculate that When we get together in communities like this, when we sprint over the weekends, when we put our energies, nights and weekends, organizing conferences, everything we do to help each other make our community better, that's a generative activity. It's not a bean counter thing. And so there's a really great tweet I saw a while back that is a riff on Conway's Law. And you know you hit a certain level – you transcend a certain level of hubris when you start quoting your own tweets in your conference talks. But I just want to highlight this. This is my pinned tweet for a reason. How many of you know Conway's Law? How many of you have heard? Okay, so for those who don't know it, it's an observation that this guy made back in the, I don't know, 60s when he was studying software systems. And he said that the structure of a piece of software tends to mirror the organizational structure of the people that produced it. So if you go and you have a system you want to build, is there a perfect architecture for it? Is there a perfect design? I don't know. But if you hire three different consultants to build it, you're going to end up with a system with three different major subsystems. If you go and give it to two different teams, it's going to have two major components. And so this idea that code comes from people seems like an obvious point, but it's actually a deeply important one. Yeah, in my tweet. Check it out. It's awesome, my tweet. But this idea that the flip side of Conway's Law is that code is a cultural artifact. So like I said about the community orchestra, how code is an artifact for us. When we play well together, we make good music. It's about playing well together more or as much as it is about the music. And so for me, this is a really deep point, that when we get together as open source software communities, the way we play is what enables better innovation. It's what enables broader search of the innovation space. It's what makes sustainability cheaper. So this is a piece that I want everyone to think about. Software is not just about code. It's not just a single fixed artifact. It's actually a process and a relationship. And the communities that produce software are very, very important because different kinds of communities produce different kinds of software. So community. There's a great book by Clay Shirky about crowdsourcing called Here Comes Everybody. And in it, he talks about the stages of collaboration. The first stage, he says, it's kind of a weird term he uses, it's called me-first collaboration, which is I want to vet that this works for me, scratching my own itch, as we would call it, right? The second phase then, and this is crowdsourcing for anything. It could be Wikipedia, it could be trying to build Burning Man, right? It could be like whatever. Before you get like 50,000 people in the middle of the desert, you're going to try camping in the desert by yourself, right? Me-first collaboration. So with open source software, same thing. Before I try to tell everyone in the world I've made this amazing thing, I'm going to go and see if I can make it work. The next step, then, is to have a place to have a conversation with everyone, tell people about it, people coming together to learn. And then the third step, of course, collaboration, where a group actually forms, and this is really important, they have a shared purpose. They have a shared purpose, and then they can, in their own sort of amorphous way, proceed towards that purpose. So you go from somebody proving it out, prototyping it, then having a place to teach other people about it and then everyone getting together to work on it pretty straightforward but a generic pattern of crowdsourcing that that clay shirky talks about a really important thing here in this in this quote directly from the book he says something very deep he says it can often be characterized by people wanting to fix a market failure and it's motivated by increasing accessibility it's very it's a bunch of words but it's like it's actually really deep if you look at the ways that open source whether it's on the commoditizing taking care of like well-known problems or whether it's on the innovation side open source software fixes the market failures of previous proprietary apis that's the market failure matlab has been around for a very very long time. The amount of innovation and people stepping on each other's shoulders instead of on each other's toes, or only going as far up as the gravity of the MATLAB license would let them, that's a very different dynamic than what happened in NumPy and SciPy. Pandas was written by one dude working at a hedge fund. And then he got another dude to help him. And then, boom, a bunch of other people joined in. And now Wes barely works on Pandas at all, right? It's maintained by a bunch of other people. And that's great. The unlocking of that kind of human potential, the creation of a community like that, they fix a market failure around the previous old APIs, the old markets. Now, this last thing, there's a fourth step, which we almost never get to. The fourth step that Clay Shirky talks about is collective action. The fate of the group as a whole becomes important. Some open source communities get to a point of success. They have the privilege of being so successful, they're faced with that challenge. I would say the Python community is faced with that challenge right now. When we talk about the future vision for Python moving forward, what does that look like? Well, it's a global tens of millions of persons, large user community. How do we do collective decision-making there? How do we get everyone's buy-in? What's the right model to make sure we don't blow up the old market, but go into the new spaces and try to create new markets? That question, it's a privilege to get there, to be faced with the ability to climb that mountain, but it is a big mountain to climb. And I think in order to climb it, we have to actually have very, very tough, straight thinking about what we want in the community. We have to get this straight. It's not just about shipping code. It's not just about fixing bugs and triaging the bug tracker. It's actually about having a vision about the community ethos itself. And so, you know, we need to actually make a statement that this is about participation. This is not just about getting free stuff. Get the free stuff if you want to, but if you actually want to have a voice in all this, then you need to participate. But in order to accept participation from all these different people, we have to develop trust with each other, right? This is why diversity is so important. This is why diversity actually is the outgrowth of a deeper principle, which is empathy. We have to develop empathy within ourselves and within our communities so we can actually then have an inclusive culture, so we can actually develop trust. And this is why it's also today, nowadays, it's very hard for people to trust corporations or brands because those come from very, I mean, corporate culture. They come from a particular kind of consumerism, particular kind of capitalism, a particular kind of for-profit, profit-seeking, rent-seeking motive. So right now, trust in our community is still inherently tied to individuals. I think for the Python community to move forward, we actually need to figure out what are the ground rules so that we can trust companies, right? and a way to think about this really is, I think, a very simple metaphor is to think about it as a community garden, where we're producing, you know, we're all tending to the garden, a few of us are, it produces this amazing verdant jungle of different kinds of cool things, and all this free fruit is out there for people. We put that fruit in a little basket and ask the companies, like, please check out my Patreon, please hire me, right? And that only captures a tiny fraction of the value of the fruit, but that's okay. We're not greedy. We don't need billions of dollars, but a few million would be nice. And I'm serious, right? Like a lot of these open source software have added billions of dollars of value. Why shouldn't the maintainers have a few million dollars? Like that is a totally fair fraction of the value. And another way to do it is to support, you know, grocers, people that actually span this chasm between the producers and the gardeners and the people who just want to easily vend and easily transact. And one framework I'll try to give you to think about this is it comes from a friend of mine who's actually here in Berlin named Joe Edelman, and he says that there's, in general, fundamentally, there's two ways we can look at anything in the world. We can look at it from a goal-oriented approach, which is to say, like, if I have a car, this car is an object, this car is a vehicle, I can use this car to get to places, right? It's a good car because it gets me to places. this is a collection of people. It's a reasonable collection of people. And I can use it to go and take my time, my expertise, and turn it into dollars, which I can then use, or euro, which I can then go and use to buy coffee and things like that. That's a very goal-oriented view of the world. And you can view people this way. You can view institutions. You can view literally any object, right? This coffee cup, right? This coffee helps me stay hydrated and also lets me talk faster so i can get my talk done on time that's a goal-oriented view of the cup of coffee but there's a different way of looking at the world which is to say how does this object or environment or these people help me live my values and it ceases to be about process you cease to look at things as mere tools i mean the problem with the goal-oriented approach and this is one of the most like damning condemnations of corporate culture is it views people as mere instruments towards achieving some strategic key goal with some key performance indicator. But really, people, we're people. We want meaning in our lives, right? And for us, it's about living our values. The open source community is a great example of the kind of generativity and the kinds of value we get when people get to live their values. And those values include technical merit. Those values include diversity and empathy. Those values include just having a great time and being nice to each other. You know, all of those things are values that we want to live by. and that's a muscle we don't flex very often but when we don't flex that muscle we feel lopsided we know the feeling of anomie when it relates to labor the difference between effective labor versus merely um you know the the labor economics of of marx and all these others so um i think joe edelman this point i would i would urge you guys to check out his work but if we refract that then if we think about our our community on the basis of that you know shipping code is certainly a nice goal to have, but it doesn't trump living our... I can't believe I used that. It doesn't override having a meaningful place to live our values. So what is the GNU philosophy for the ML era? What does it mean to be Libre? What is compelled? What is real freedom? What is generativity? These are the kinds of conversations we need to have, and they don't have to be global. We don't have to assert them to be global. They can be true just in Berlin. They can be true just in New York. They can be true just in India. They can be true wherever. But the idea is to ask that question, to start with that question. What kind of environment do we want? What are the values we want to live and express in this community? And I think the important thing, you might say, well, okay, that's all great. But geez, this is supposed to be a technical talk. Like, can't you show some code? And actually, I would say this is a really important thing. The reason why when you get, I think, any of the ecosystem maintainers and like the OG who like created these things, you get Travis up here, he will also be talking about community values and diversity and all these things. And the reason we all end up in this space is because of a simple concept, if you want to make it very practical, and it's called go to market, right? Like when you have a product, you can say this product is awesome. You should use my cool widget because it does these cool things. That works for a small early adopter community. when you want to take your product out to market, you have to explicitly think about how does this product solve my user's problems? You have to cross the chasm. With open source projects, it's the same thing. I can get a bunch of early contributors in, and I see this in every successful open source project. There's an early phase around the innovator community, the bleeding edge innovators and the true believers, then the early adopters, and then there's a chasm. And a lot of projects, they fall off in that chasm. They can't grow beyond that chasm because to grow past the chasm, you have to go to community and you go to community on the basis of values, not on the basis of tech. Now, for me, my values in the PyData community and the SciPy community and all this, for me, what I want to make sure we preserve is, so this is an articulation, just my answer for this question, is that we need to defend the commons for innovation. And the last couple of years have actually been pretty challenging for me because I've seen very successful projects in our community struggle. I've seen other very large commercially vendor-backed projects succeed and start attracting a lot of mindshare and a lot of interest. And they don't necessarily espouse the same values that we have. And I've tried so hard to come up with the right way to express these concepts. And finally, I've settled on this idea of an innovation commons. And this is Eleanor Ohlstrom, who is the best known. She's the best known person in the world about talking about the commons and the tragedy of the commons and things like that. And her research and her writing is foundational on this stuff. She's a personal hero of mine. But her work is mostly tied to actual economic studies of actual commons with scarcity, right? Where you're defending a scarce resource from the tragedy of the commons. But in our case, innovation and creation are generative and non-rivalrous, right? I mean, if we have a big corporate project that goes and does cool innovation, that doesn't stop you from going and doing your project. So what's the problem? And the problem, the commons that actually needs defending is the time and attention of developers. All of you, the humans, the bodies, the minds, that is actually a commons. And it's not linear. It's not, it's super linear. It's actually exponential, right? 10 people in a room talking about a project is more than 5x the power of two people in a room talking about a project. And so my concern, the commons that I want to make sure our open community defends, is that I do not want to see that hijacked by for-profit entities who do not care about some of these other values that have created the PyData and the SciPy community. So to put kind of a thing on it, openness is embodied in the lived values of the community around a software project. That's really, really important. I want all of you to be thinking about that when we talk about open source. It's not about how to get a dollar here, how to Patreon that, what license do we use here, source available versus blah, blah, blah. It's about what are the values of the community that produces this? Are those sustainable? Do I believe that will continue to have open innovation moving forward? So, open. Open is of value about freedom and sovereignty. Source is an outdated term. It used to refer to a time when just reading source could guarantee you sovereignty and choice and freedom. Not anymore. You can read this piece of source, but if you only can get it to work by deploying it onto a proprietary cloud, eh, you don't have so much freedom. Software. Software is a valuable artifact if you're a goal-directed business, but developing it well is the primary value for open source communities. And lastly, community. That's the most important thing. The social environment in which we can live our values, that we can innovate, that we can bring in more and more great voices, that's actually really, really important. That's the most important thing. And you'll have to, you know, I guess if there's a Q&A period that we have after this, and I can go through the last section of my talk about why openness matters so much in the machine learning era. But just a preview for you, some, you know, cool stuff there. So you should come to my Q&A. So thank you very much. Thank you. Yes. But, yeah, first, thanks for the great keynote, Peter. Yeah, we move to questions. So, who are the questions? And Mati is going to come. Oh, the questions were in another section? Oh, yeah, we have another session afterwards as well. but if you have immediately some questions, we can ask now. Okay, then we move to the... Oh, everybody seems happy. I think people want to run to tutorials. I also want to comment. Before I ask everyone some... Oh, yeah, you have a question. So you talk quite a lot about community and the value of the community and extracting that somewhat paltry sum of a couple of million for the community do you have any like practical advice on how do we actually get that money into the community yeah so yes that's a great question so how do we get money into the community since i talk about the money so much um i think right now the open source community has almost a visceral um uh antibody like immune rejection of certain kinds of businesses corporation interaction things like that right for instance when we think about um uh you know some projects like python even right you can't have more than two people in the steering council work at the same employer um and uh you know other things like that where it's like oh if someone's getting paid for this they have undue influence right what happens if if you know facebook hires lukash and then tells him hey but you got to go do this thing and he's like well i don't want to do this thing so we sort of have a a sense of anti-patterns around this and I think that the way we can get the first step to unlocking dollars or money for this kind of thing is to actually change the conversation to be about values as opposed to being about certain kinds of influence to say well if these companies are aligned with our values then we can take their then we then we can actually do things for them it's not inappropriate to say you can pay for roadmap as long as that roadmap here so you know is really pushing certain values maybe you're paying for a new innovation exploration of this project right maybe you're paying to maintain some old stuff. Paying for roadmap, paying for work is a-okay, right? What we have this like immune response to is the idea of paying to move the community and shape the community and just like, you know, that capture is what we don't like. But if we can just express it in those terms and think of ways to have that conversation with business, many businesses are happy to pay for those kinds of things. They don't want to screw up the innovation. They don't want to screw up the community dynamics, right? So I think that's the first step is coming up with of values-based discussion with businesses. Okay, so we have to close the session, but we have a Q&A section in the launch, so please just come there. Right now or later? No. Yeah, after the next session. After the next session. After the next session, just in the launch, and thanks for coming. Thank you.