EuroPython 2024 — Open Source Sustainability Panel
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 131 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/69438 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Data acquisitionOpen sourceProjective planeMereologyLine (geometry)Self-organizationOpen sourceRoundness (object)Interactive televisionSoftwareIntegrated development environmentComputer animationLecture/ConferenceMeeting/Interview
01:23
Dot productObject-oriented analysis and designAriana TVOrdinary differential equationSoftware as a serviceBarrelled spaceOpen sourceRoundness (object)Self-organizationProjective planeCore dumpRight angleSoftware maintenancePlanningBitPerspective (visual)Group actionUniform resource locatorSinc functionRepetitionMultiplication signMessage passingTotal S.A.Meeting/InterviewLecture/Conference
04:43
Reading (process)Personal area networkPrinciple of relativityStochastic differential equationTamagotchiDensity of statesWeb 2.0Ewe languageRevision controlCodeMereologyProjective planeDegree (graph theory)Different (Kate Ryan album)Sound effectSoftware maintenanceStandard deviationCycle (graph theory)Traffic reportingPoint (geometry)Disk read-and-write headRight angleRule of inferenceSoftwareLibrary (computing)Multiplication signMoment (mathematics)Expected valueRepresentation (politics)Open sourceSelf-organizationProduct (business)Software bugNumberQuicksortCore dump1 (number)WebsiteMachine visionBoundary value problemProcess (computing)Business modelMathematicsTerm (mathematics)String (computer science)BitInstance (computer science)Data managementMachine code2 (number)Data structureReduction of orderMeeting/InterviewComputer animationLecture/Conference
14:10
Total S.A.OctahedronRoute of administrationDot productCross-site scriptingHand fan2 (number)Dirac equationDesign of experimentsAiry functionSystems engineeringPrinciple of relativityIn-System-ProgrammierungSystem of linear equationsGotcha <Informatik>Polar coordinate systemComputer iconCAN busOrdinary differential equationNetwork switching subsystemPressurePseudodifferentialoperatorSatelliteMountain passTrigonometric functionsSuccessive over-relaxationRouter (computing)Density of statesIntrusion detection systemCone penetration testRadio-frequency identificationBit rateSystem on a chipService-oriented architectureDifferential algebraic equationEstimationRothe-VerfahrenRaw image formatExact sequenceReceiver operating characteristicNetwork operating systemError messageAlgorithmic information theoryMathematicsMoment (mathematics)Open sourceArithmetic meanSoftware maintenanceRevision controlComputing platformCategory of beingComputer programmingStudent's t-testPhysical lawData managementAxiom of choiceEndliche ModelltheorieExpected valueVenn diagramBlogVideo gameMoney <Programm>PlanningPoint (geometry)outputPatch (Unix)Library (computing)FreewareQuicksortBoundary value problemWage labourRule of inferenceTerm (mathematics)Normal (geometry)Different (Kate Ryan album)Software developerFile Transfer ProtocolDressing (medical)Projective planeDependent and independent variablesDecision theoryCodePower (physics)SoftwareWordData conversionRow (database)Multiplication signLattice (order)Self-organizationVirtual machineWhiteboardShooting methodRegular graphExecution unitLevel (video gaming)InfotainmentNetwork topologyType theoryBitInheritance (object-oriented programming)Structural loadSoftware frameworkArmDisk read-and-write headSpacetimeExclusive orMereologyProduct (business)Design by contractFrustrationString (computer science)BuildingHypermediaIntegrated development environmentHuman migrationStress (mechanics)RandomizationElement (mathematics)Software bugOpen setSound effectComplete metric spaceGroup actionProcess (computing)Information securityTelecommunicationWindowLaptopTrailRoundness (object)Game theoryElectronic mailing list19 (number)Goodness of fitCore dumpHydraulic jumpDivergenceMetric systemCASE <Informatik>Service (economics)Real numberPhysical systemDirection (geometry)Online help1 (number)Right angleCausalitySparse matrixNumberConnected spaceComputer configurationInterpreter (computing)Degree (graph theory)Validity (statistics)Parameter (computer programming)State observerTwitterInternet service providerPoint cloudFood energyClosed setInternetworkingSurjective function10 (number)Exception handlingLoginPerspective (visual)Instance (computer science)Business modelFrequencyMobile appElasticity (physics)Extension (kinesiology)Office suiteSimilarity (geometry)Circle2 (number)NP-hardMappingThumbnailDiagramHard disk driveLecture/ConferenceMeeting/InterviewComputer animation
Transcript: English(auto-generated)
00:05
Welcome, everyone. Thank you for joining us today for the Open Source Sustainability Panel. The motivation behind this panel is to provide some insights into the audience with, for the audience to, regards to funding open source projects and making them more sustainable.
00:20
So, you might think, what kind of sustainability are you thinking about? We're not going to talk about climate change or the environment, which is also an important topic. We're going to talk about, more about burnout and funding and making sure that projects are set up for success and long-term success. That, we're also going to talk about community interactions.
00:43
So, it's not just about the money part and, yeah, that's, we're going to do the first, like a couple of questions and then we're going to open a microphone for the audience. We have one microphone over there. If you want to ask a question, please line up. And, we'll be happy to take the questions.
01:01
We have five panelists today. I'm going to do a short introduction now. So, we have, sorry for my laugh, we have Deb, the executive director of the Python Sutter Foundation. Round of applause, please. Then, we have Charles, a community organizer and the vice president of the Django Sutter Foundation.
01:24
Then, we have Anuesha, the PyLady and the community organizer as well, also working for Red Hat. And, one round of applause. Then, we have Armin Roneher from Sentry, among other things. And, at the end, last but not least,
01:45
we have Samuel Colvin from PyDramtech. Okay. So, let's start with the first question, which is how would you define the sustainability and what's the most effective thing you've seen
02:01
for setting the project up for the long-term success? And, for this particular question, will you please everyone start it from. Yes. All right. All right. So, I think one of the most important things for setting a project up for long-term success is doing the work
02:20
to figure out what you want to get done there before you kind of open the doors. So, if you have a goal in mind, then you attract the people that want to help you with that goal. So, I think it's really important to do a little bit of like strategic planning and thinking about the future. And then, just kind of as a side note, if you're picturing your project as diverse,
02:43
don't put that off. You should start at the beginning. Because it's really hard to add it back later on. Okay. I'm going to answer from a different perspective. So, my approach will be from the community side and,
03:03
like, sustainability of the peoples and projects held. And, maybe, yeah, since we are talking about community, I'm going to give an example of a group of jungle girls workshops that I helped organize over the three years.
03:23
Like, in total, kind of 20. This location is Turkey. So, like, what was the success that a group of us come together and manage to reach so many women over the years successfully?
03:42
Is that, like, we built a good, like, core organizers community, which is equivalent of, like, what we have as maintainers in Django or in other open source projects.
04:01
And, like, the collaborative working of that group. So, even though one of us were burned out and couldn't continue, the work was going on. And, as a group, we were able to, like, lay the knowledge, message, expertise over the years
04:21
and, like, successfully managed to run it. Yeah. A sustainable open source project to me is a project which is adaptable and which can change.
04:43
It's not rigid in its administrative ways. When I'm saying administrative, it is code, and also the new changes in technology and also legal for the matter of fact. And, but without changing its basic structure.
05:04
And, on the other hand, not exhausting its base. Not, when I'm saying not exhausting what it has, I'm actually talking about the community.
05:22
These things, when you're starting a project, seeing the most small things initially. But these are the things, trust me, it is going to be the biggest ones in future. Initially, we all are technologists. We are just too excited about the code.
05:41
Like, whatever is the problem, let's do a website and it's going to solve everything. No, it's not. So, think about the small things, how to deal with the community, how to maintain a behavior and set a tone of the community.
06:01
So, that is what a sustainable open source project looks like to me. So, I will wear two hats here today. So, hat number one is, I build a lot of open source libraries myself, usually not really commercialized. So, that's hat number one. And then hat number two is,
06:21
we are also sort of representing Sentry here, which is a company that has, what I would still consider a very strong open source core and our main product is also open source, but it is also open source with Nascaris. We can go into this later. But it is a very capitalistic business with venture capital and everything that comes with it.
06:43
And both of those things have to be sustainable, right? If you want to make an open source company, then there's certain rules. But if you want to have your own open source project, there's certain rules. But these things don't look anything alike. For an open source project like Flask
07:02
or any of the things that I've built, I don't know if they were ever sustainable in the sense that they are still alive, which is great, but I didn't really do a particularly good job at keeping those things alive. It eventually became popular and then other people started maintaining them. So, I actually don't have good suggestions
07:21
on how to do community management because I didn't ever succeed in this. But I think part of what makes these projects actually be sustainable is get to the point where others can come in and help out, even if the original person like me just runs away. And what helps that was actually mentioned before,
07:41
which is clearly communicate what it was supposed to do. Maybe you didn't even finish building it in the first place, but you wrote a little document that says, okay, vision 2030, this thing can do X, Y, Z. And if it's written down once, then that's maybe also what gets people into it. And then even if the original maintainer runs away, the project has a much higher chance of surviving
08:02
because it was written down at one point. And I think for the sustainability on the company side, it is a very different thing. It's like there are actually a lot of these legal protections. It's figuring out like how do you set boundaries between the business part of it and the open source part of it. And like many different companies have done it in different ways. There are red heads of the world.
08:21
There's like the centuries of the world. And depending on the business, there are like very different rules, but you have to be very, very specific because there will be competing interests and you have to be transparent about them because otherwise you're going to have a very terrible relationship with the people that actually want to have the only open source part of it and so that's I think the second version of this.
08:44
I would say there are three parts to the health of any open source project. There's like the quality of the code, there's how fast you're moving and there's the degree to which the project is kind of community led or has lots of different people contributing and you get to choose one in effect
09:01
or rather it's always a trade off between all three of those. And so the first thing is to acknowledge that and accept that there's gonna be trade offs. The faster you move, the more likely there are to be bugged. The more people you have contributing, the harder it is to maintain code standards and to move fast because someone comes along, starts a pull request and they might finish it in three months, but if you're trying to do a monthly release cycle,
09:21
that becomes problematic. But the point is all three of those things matter to the longevity of a project. The code quality obviously affects it but if I come and contribute and the project is excellently managed, zero bugs, but there's not gonna be a release for two years, my willingness to come along and contribute another pull request is gonna be reduced. So I think that it's some difficult challenge
09:43
of basically those three things and trading them off and accepting that you're gonna not get all three of them right. You're gonna have moments where you basically take over someone's pull request or close it and do it yourself, but try and do that as little as possible except that you're gonna delay the occasional release by a week to let someone finish their pull request. Yeah, working through the trade-off of those three things.
10:06
Okay, so now maybe let's move on to the topic of related to funding. We have a diverse representation of different organizations on the panel. Some are for-profit entities, some are non-profit entities.
10:21
What's the approach to funding the project? Because eventually, if you want to make it sustainable and it's not purely based on only volunteers and it's also based on some compensated work, there are many ways to approach this. So would you like to maybe share your thoughts on that approach?
10:41
And maybe this time, let's go from the other side. This time, I don't get to think about my answer. I'm lucky. I was working on Pydantic more or less on my own. I had some people helping me, but I was basically working on it full-time on my own. The end of 2022, I was being paid, got some sponsorship, got some money. Salesforce, for example, gave me $10,000,
11:01
which was very nice. I suppose I was getting towards being paid like $35,000, $40,000 a year to work on it, which was beginning to be a salary depending on where in the world you live, but definitely wasn't the salary I was hoping for. And then basically the biggest VC in the world reached out to me and said, would you like to start a company, and can we fund you? I'm very lucky in that situation,
11:20
and now I run a for-profit company, and I'm very much enjoying it. Very hard to know what I would have done the other way around. I think the first thing, again, is to acknowledge there are open-source projects that are not for profit, that are purely community-led that die, and there are open-source projects that are managed by big corporations, and people are funded, and they die too. And there are successful projects of both sorts as well.
11:42
Like, neither one is guaranteed success or guaranteed failure. You just have to work through the challenges. And I think, I mean, the one thing I would add is like, if you go and take money from a VC, you have to acknowledge what that means. That means that at some point in the reasonably, in the medium term, they want extraordinary returns. And they're prepared for you to do anything to get there.
12:03
And that is a compromise that you have to accept, and I'm enjoying it a lot, but you can't pretend you're going into it and that you're still running a charity. Yeah, so, I very intentionally did not try to raise money
12:20
for any of my open-source projects. Mostly because, actually, for what was mentioned, which is like, the reason some people like the libraries and things that are built is because they are open-source, no strings attached, no ulterior business motive behind it.
12:41
And, but it is a challenge, because like, eventually you actually realize that there are lots of large companies that use your stuff, and you feel like, hey, I feel a little bit entitled to get some of this money. And so, I chose to join a company due to my open-source work, which also did open-source, but had a business model. Very clear one, like make money, sell stuff.
13:03
And one of the things we were trying to do at Sentry is we have been funding open-source dependencies for the last couple of years. So we take some of our money, and for us, it's marketing budget to some degree, but it is like giving back to the community of the people that we use. So we go through our dependencies, we try to figure out to which degree do we use them,
13:22
and then we fund them every year. And we're also looking at encouraging other people of doing that. But there's a very clear challenge with this, which is, Sentry, for instance, is a commercial business, right? It makes money, it sells the software. But then we also have open-source libraries, and we had many people contributing to us over the years
13:43
who are basically unpaid, right? And at one point, I felt really bad about this. And I actually figured out it's really hard at times to pay people that don't want to be paid. Because the moment you give someone money, it also turns into like, well, now I have expectations, right? And so we, like one of my reports,
14:02
or former reports at this point, has been very helpful in actually like sending Christmas gifts and stuff to contributors there. Because they didn't want money, but that doesn't mean that they are not appreciated, right? But it is very tough to walk this line, because the moment money is involved,
14:20
your perception of the project changes. And sometimes people are not willing to do that. Okay, I'm not sure whether I'm the right person to do it, like answer this question. Definitely I am not, because I am working in a project, the community side. I work at Red Hat, and I work in the Ansible community engineering team.
14:42
So I release the free version of the stuff we sell. So basically Red Hat pays me to do the community job. So Ansible has a automation platform which you can actually buy,
15:01
and Ansible has a open source version where you can, like for the community version. So now, in our case, it is very predefined and preset. What in Ansible community, especially what we do, we keep the definition of those two things
15:21
and what you are getting if you are paying. When you are paying, we try to keep that definition very clear. So that works for us, but again, I need to say that I am not the perfect person to answer the VC funding. Yes, previously I used to work,
15:42
I used to make those agreements as a lawyer for VCs. So I know the bad clauses we used to put, like I used to insist to put, so yeah. Okay, I'm going to answer from a non-profit perspective
16:05
and give the details of our fellowship program. So like in Django, Django Software Foundation owns the intellectual property of Django and also like PSF is responsible
16:24
from all the things that student council is responsible for which is like all the non-technical decisions, directions, including fundraising. And since a while, we run this fellowship program.
16:42
So like even though Django is a big open source project and there are a lot of volunteer maintainers, we have two full-time employees employed by Django Software Foundation, DSF fellows.
17:01
So they are employed to work on Django. And I think we can finally say code base because a few years ago, we officially saying we hired them as community managers because of the US law.
17:21
But I think now we can freely say we are actually hiring them to work on the code base as maintainers. And like the direct effect of this is thanks to them, Django can release a security release once a month.
17:42
This is not something you can easily run in an open source project by a group of volunteers. And I think yeah, a good example and I think then PSF actually adapted the idea.
18:05
We have Lukasz, the first PSF fellow. So like it looks like this is working as it's proved itself for Django and it's also proving itself for Python.
18:24
Yeah, so for small projects, like I've been part of a couple of different nonprofits that have helped small projects get started. And the first advice I give them is that the amount of money going out should be less than the amount coming in.
18:42
So that's important, you should not spend money you don't have. But more seriously speaking, like you need a budget and you need to decide what you wanna do. And then if you wanna create a sustainable relationship with funders, like for something at the PSF or any kind of nonprofit or community run project,
19:01
what you need is transparency, like you need to really be honest with those funders about what you're doing, what's on your roadmap, what you're planning to do in the next couple of years so that they understand where you're going and then making sure that you continue to have alignment with those funders. Because a sustainable relationship with a funder
19:20
where you have told them a bunch of stuff you think they wanna hear so that you can get a check this year is not gonna be all that happy when they find out that you've been telling the community something totally different about what your roadmap is and what your plan is for the code base. So sustainable funding relationships have like honesty, transparency and alignment at the heart of them.
19:46
Deb, you mentioned a roadmap that you need to share with the potential founders and you need to essentially have a plan of where you wanna go as a project. Now, when you start the fundraising,
20:03
obviously the founders, the donors and the community might have divergent interest or in case of a company, the company might have a different business interest than the community around the project. How do you manage the two of those? Yeah, I mean, there's like competing interests
20:21
so the alignment might not be a circle, it might be a Venn diagram with a big chunk in the middle like certainly I've been at conferences where it's like, oh, now we're reading the lengthy list of sponsors again for the 19th time today and you can see the audience is like, ah, yeah, is that alignment?
20:41
No, exactly. But I think people understand that's like a necessary part of thanking sponsors for the work. When you get into technical decisions, I don't think you can tell one group one thing and the other group another. This is not gonna work. It might work for one year of funding.
21:04
But I think that it's like people need to, if they don't understand why they feel like there's misalignment, then usually it's like a matter of doing some education. So for instance, the PSF is a US nonprofit.
21:21
We have some weird rules that are arcane to IRS code in the US. Things we can and can't do. And sometimes like people are a little frustrated like for instance, why can't you send money to Iran? And it's because we're a US-based company and it's illegal for us to do that.
21:40
Would we like to? Would the community like to? For sure. But because of where we're based, we can't. Usually at the PSF at least, if companies ask us to do something that is gonna make the community really unhappy, I tell them no thanks. Because it's not worth it. Like our real value is the community
22:01
and a company that is that wrong-headed and misunderstanding of what open source is is not gonna be a good long-term partner for us. So for me, like for us, in Ansible what we do,
22:20
essentially the basic definition and the boundaries were set at the very beginning. And we, the community team, works as a liaison between the Ansible community and Red Hat. That is what we do. And since the definition and the boundary for both the project and the product
22:43
has been set very earlier, our only goal is to change it or like revamp it or have a look at the definition time to time. So that is how we manage.
23:02
So yes. Yeah, so I think this is a little bit of a loaded topic for us. I never represent Sentry here now because we have been, I don't know if I would say accused, but I think there was quite a bit of controversy about our license change because we moved from an open source license model
23:22
to what I call delayed open source. Like the first two years is an exclusivity period. And then any code older than two years is fully open source. And our head of open source, he wrote an interesting blog post about it, which is like, it is really only a rug pull if someone is standing on the rug.
23:41
And I think this is really interesting because what is the reason why you're doing open source? It actually turns out there are many different ways of going about it. From our perspective, we like all the elements of open source and particularly also being able to have a business running side by side.
24:01
But there are also other people that say like, well, the actual definition of what it means to be an open source practice be very open to contributions, to be very open to forking all of that, right? And not everybody actually shares all of those ideas. And I think one of the mistakes we sort of made or we didn't realize is that our original motivation
24:20
of building this as an open source project was actually a different one than some other people's motivation for being an open source project. For instance, for me, for Flask, I want it to be open source so that everybody can use it, no strings attached. The reason Sentry is open source is not so much to get a bunch of contributions from everybody, but to also say like, hey, you can keep using that software even if the company fails.
24:40
Like if we go away, it's still there. It's still for someone to use. Do you want to use it in an environment where we can't legally serve you? You can take Sentry and run it in Iran. We can never sell you the software there for legal reasons, but you could self-run it there, right? This is absolutely okay for us. But you also want to have this business on the side.
25:01
And so there are many different ways in which you can go about it. And we sort of made this mistake a little bit to not change anything that we felt is important to us, but a lot of other people felt like we really ripped their understanding of open source apart. And this is challenging because you don't know
25:21
how people respond until they actually maybe change one of those boundaries, right? Like we had pretty clear boundaries in the beginning. Turns out we interpreted them differently than other people did. And I think that risk will always remain. Can I ask how come you didn't know how the community was gonna respond? Did you not talk to the community before?
25:41
So the challenge is not so much that the community, our community responded in a specific way. Actually, our community didn't care, right? But there's open source community as a whole. And the open source community as a whole was very frustrated with how can we call ourselves
26:00
an open source community if we do delayed open source licensing, right? So there's a lot more than the people around us. All the people that we service, everything, for them, that change was not meaningful, right? Because everything that was possible before and possible afterwards is the same. The thing what the license restricted
26:22
is commercially operating Sentry as a cloud hosted provider. But we sort of culturally appropriated the meaning of open source in a way. And I think to the degree to which people outside of the space that we looked at
26:41
had opinions about it, I think we underestimated. I'd say this is a really hard question, which is why I tried my very best to completely avoid it. And so whether or not it's the right decision, we decided to keep Pydantic completely open and MIT licensed and go and build something that solves a completely different problem
27:00
for the same people. And that was mostly because I've wanted to build Logfire for ages and I was able to kind of co-opt this company into doing that. But it also means we don't have really any of this tension. The main problem is that people come and say, why you, the people who do data validation are building an observability platform. But I think we can get around that. But it means that for us, Pydantic is purely a way of bringing people
27:22
and getting their eyeballs onto Logfire and giving them some level of conviction that we might build good software. But I think having watched Sentry, Elastic, Redis, et cetera, I'm not saying you all did exactly the same thing, but all of those companies took a lot of heat, some rightly, some less rightly. And watching that was definitely one of the reasons that we, one, one of the reasons
27:42
that we went and built something different. And two, one of the reasons Logfire is not source available in any, well, the platform is not source available because I watched what happened with CodeCov and I was like, well, if you get that much heat for making the source available, but easier not to. So I do think that like the open source community, to some extent,
28:00
so some of it shot itself in the foot by being so critical of source available licenses. I also, I got a lecture from a lawyer about how we should be doing open source. Lawyers have never given anything away for free in their life. And I find the idea of lawyers who stand to make You have the wrong lawyers. Who stand to make lots of money
28:21
out of the ongoing grievances about open source, complaining that things are not source available. Oh, sorry, they're not truly open source, it's somewhat hypocritical. So that's why we avoided it. I want to say one thing on this one, because I'm very outspoken on there is a world where it's like open source on one clear corner,
28:41
proprietary on another corner. And I am a very, very strong believer it's better for companies to be closer to open source, but maybe not entirely open source, than to say like, well, screw everybody, we're just going to make it proprietary all along. Like, I think that nobody wins from that. And it's, I kind of hope that we can push at least the conversation a little bit in a direction
29:00
of saying like, maybe there's a middle ground somewhere that finds most of the benefits of open source. Because I feel like there's still a world where Sentry could like fail as a company and doesn't have a future. And I would love that product to be fully available to people to use, even beyond our like ability
29:20
to run a successful company, right? So I never wanted to be dying somewhere on a hard drive, never to be seen again, and just hoping that someone eventually comes back and says like, well, it's 15 years, let's open source it. Like a lot of computer games did. Where you really, you're subject to someone doing a good service years after someone stopped caring
29:43
about something, now it's open source. But like until then, like nothing. Yeah, I think it probably highlights a lot the difference between for profit and nonprofit. So like the PSF is community driven and is a nonprofit. And we consider it part of our mission to continue using a real open source license
30:02
under the open source definition. It would be pretty freaking obnoxious for me to be like, thanks for 30 years of work y'all. I'm gonna cash in. I would rightly expect all of you to throw a rotting fruit at me forever for the rest of my days. So it's not gonna happen because I don't want any rotting fruit.
30:23
I think it depends too, like if you're starting a company and like 98% of your contributions are coming from people who work for you, then you know, they're on salary. Like do whatever you want with your license. But I feel like if you take a lot of community contributions and then change the license,
30:42
like when I look at what happened with, and this is super old, one laptop per child, and people were really angry. Like they were like, this humanitarian cause, we're gonna give laptops to children in places where there's sparse electricity and sparse connectivity. And people poured hours and hours and hours
31:02
and hours of unpaid work. And then they were like, just kidding, we're gonna take some Microsoft money and make it proprietary. And people were like extremely upset. The project never recovered. So I think it depends on like how indebted to the community you feel and you know,
31:20
like that contextualizes a license change for me a lot. One of the challenges, right, you can move from open source towards less open source. And there's like a lot of companies who've done that some cynically. I don't think Sentry have done it cynically, but like some companies have done it definitely cynically as in they've started off pushing its open source and then they've like changed the license.
31:42
The other option is to start fully closed source or like source available and then move towards open source when you know your business model. And I think like, obviously you can't change what's happened in the past, but like with new companies or new projects, cause that's quite a good way of like insulating yourself from the like toxicity of stopping being open source right and wrong.
32:01
Yeah, and it kind of goes back to what I said at the beginning is having a strategic plan at the beginning and to just like put a finer point on that, like whether it's a open source business or an open source nonprofit, like having someone from legal in the room that understands what open source is and is okay with giving stuff away if that's what you think you are gonna wanna do.
32:21
Having engineering and having someone who understands what your business plan or your community outreach plan is. Cause that's, in my mind when I see companies like whoops, like it's, oh, I feel like maybe legal and engineering should have gotten in the room a little earlier to understand like how this code base is gonna be used
32:40
and are we relying on the community for like input and libraries and add-ons or are we like expecting like three people at some of our customers companies to do patches every so often. It's a really different model and it should inform your license choice. Okay, here I am actually finding myself
33:00
exactly in the middle. And I'll wear my community hat and I would like to express what as a community person what I want. As a community it is absolutely okay to shock the community but it is not okay to surprise the community.
33:22
So if any project has started by giving an expectation of something else and at the end, not at the end, at the middle, that Deb has given an excellent example of one laptop per child that how they just put it out.
33:43
Oh, we just took your labor and now we are just going to use it for our profit. So that is not acceptable. So and also whenever we are putting a license, when we are choosing a license, we are essentially choosing our boundaries. We are agreeing not only to those licensing terms
34:04
but essentially to follow the rules of a community, norms of a community. When you say you do open source, there is an expectation that we do follow these basic rules. There are different sorts of license. When we say that we do open source,
34:22
I don't say that I do MIT or there's a BSD clan, there's a MIT clan but essentially it's everything together, free and open source community because we share a similar kind of mindset. So when you're choosing your license and also you're making your boundaries,
34:42
think about what you want to do in future and if you want to change in future, which is fair enough, it's a project and it should be a community decision and it cannot be now, from now we are doing it kind of. It needs to, the community needs to heard
35:02
and when I'm saying community, it's not about only that project's community. That project's community has the veto power to take a decision but when I'm saying community, I'm saying the open source ecosystem, open source and free software ecosystem. So yes and everyone in the community
35:22
is very, very open united. So that is also a norm in the community I think. Thank you all for the input. I can see that we already have someone lined up for the Q&A so maybe take one question from the audience. Neil, would you like to ask the question?
35:43
Yeah, now it works. Hi, my question is at what stage of a project's development would you recommend you start looking for funding? So I have some ideas about how much time
36:01
people should spend on an unpaid thing and if you're spending 30 plus hours on an unpaid thing you should be seeking funding. If there's three of you and you're spreading it out, okay but if you know that it's gonna grow and you know that people are gonna be spending more than a couple hours a week on it each, then you should start looking for funding.
36:22
I think it's also telling like maybe you are spending just a couple hours a week on things but there's stuff that nobody wants to do. So I was on the board of an arts organization locally and we had the, and it was everyone's an artist like on this board, but we're a non-profit
36:40
so we have to file 990s and do accounting and understand what the IRS wants from us. So each year it'd be like, so who wants to do the taxes? And we'd all like shoot looks at each other. We should have just hired an accountant. Someone was like, can I do it as a art project
37:01
like with embroidery? I'm like, I don't think so. But so like if you have things that must get done to keep your project going that should be paid for because nobody on your volunteer team wants to do it, then you should be looking for funding. One thing I would say is like there are projects that you know you want to carry on contributing to
37:21
or that you want to keep going but there's also such a thing as open source that has a fixed lifespan. You go and you do an experiment and it doesn't need to be around in 20 years time to be successful. But if you want to prove something is possible over a week, over a month, over six months but then you think it's reasonable to abandon that then probably you don't want to get sponsorship
37:41
and get people assuming that that's gonna stay around until you're sure that you think it should stay around. So I think that's one of the things because I've definitely built libraries that I've abandoned and I don't think that that's always a bad thing because it's an experiment. It might have turned into something big but also it might have inspired someone else and I think that's important too. I also think GitHub sponsors for all that it's not perfect
38:00
and for all its Microsofts and people like to be critical of like these big organizations, it has fundamentally changed the game. Not that there are that many people who are making a complete living off GitHub sponsors but there's a lot of us who get a nice meal out with our partner once a month from GitHub sponsors to say thank you to them for sucking up that we're upstairs working all night sometimes.
38:20
So I think GitHub sponsors has made a big difference and that was definitely the first sponsorship that I had that was like more than $5 I think kind of thing. Also I like to add like I think a good time is when you are ready for it because like software development and fundraising or like managing sponsors are two different jobs.
38:45
You might think you are fundraising but if your front shop is not good enough, I don't know how much amount of work went into that but you're just assuming you're showcasing your project
39:02
and like searching for funding but like from other side of the room, they only see a white, black window. And even if you like manage to put some efforts forward
39:26
and attract sponsors, funders, this work of like funding is continuous then you need to like releasing reporting and keep that communication.
39:42
Otherwise you will have like other conflicts which then might lead unsustainability of your funding. Oh, I just want to say Microsoft's improved over the last 16, 17 years since that one laptop for child story.
40:01
I would like to build up on what Charles said about building the community around the project and making sure that there are more people involved, there are diverse contributions and so on. Would you like to talk a bit more about that topic? Yeah, in our prep talks,
40:21
so there were like two different sides of the story, the financial part and we're like, yes, yes, but like what about like health and like community because like probably unlike some lucky ones between us, most of us are working
40:42
for like companies that's run for profit and like you're all aware that we have roadmaps like metrics and teams and like team performance is important and we are putting a lot of effort into building healthy teams and then I switch back
41:03
and looking at the open source community from like a small project all the way up to like big projects like Sentry, Pydantic and like Django, Python, like how much effort are we putting
41:24
into the health of like the community, the group, like the maintainers or contributors and the like wider community. Why all those like companies, profit companies
41:41
are like putting that much energy into team building and we are just abandoning open source, it's not us but like it's super valid to run an open source library, that one, on your own. Like how did we create such a culture
42:03
because like back in the days, like for example Linux had a like huge community, healthy, not diverse, toxic, now we can discuss it but like I think maybe it's the GitHub
42:20
or maybe you have better answers but like we are like, we built this culture, we are abandoning our like contributors so like that's why my focus within like my like open source communities and DSF is around like how we can actually make, take better care of our maintainers, our leaders,
42:44
like what goods look like, what health looks like because I think good and healthy is more sustainable. Like that's why we are looking for diversity and then I'll jump to another topic.
43:00
Yesterday, the like the core developers of Python was talking about their efforts towards diversity and some like some achievements and some frustrations like what are we doing wrong there because it's same in like in Django Sofer Foundation,
43:22
last two fellows left like after five super successful year finished their contract with DSF, super like tired. So like that's why I think, sorry that wasn't a suggestion
43:41
but like more of a diagnosis and maybe like maybe we should start talking about like how we can support open source projects and big open source frameworks in terms of like health of the contributors, ways of working, how to better like
44:02
manage the non-technical side of the things and arm and like that. I would like to add something to this. So Sentry is about 400 people as it's not a huge company but it's I think probably like at least as far as my involvement in companies goes about as large as it went.
44:23
I will say I find it much easier to be a manager at a large company than it is to run a tiny open source project. And part of the reason for this is that I go in the morning into the office, it's always the same people around. It's a very like a very safe space like you can say something like it's very constrained
44:42
in like in the place where you are. The biggest stress that open source actually creates that you typically don't find in a company or at least you're shielded by other people from it is you don't know where your community starts or ends or where the expectations are. You can release a bug that breaks CI for random people and within like 15 minutes you have like a bunch of people
45:02
you have never heard about piling into your issue tracker and if that gets sufficient amount of curiosity then it will be shared on social media and then people jump in that have absolutely no standing in this because they haven't ever used this offer but they're happily going to pile on it and they can tell you what a terrible human being you are
45:21
because you're not replying to this fast enough. And I quite frankly, I got incredibly burned out from Python a couple of years ago and this was the biggest reason I sort of stepped away from Python for a long time is because I didn't feel at all happy about how the two Python three migration went and I felt like and that was probably incorrect
45:42
but I really felt like I got a little bit of a heat for like having sort of like a maybe not so welcoming opinion about like how this migration went. And it is, I don't know the answer to this but I will definitely say that no matter how you go about open source, it is very easy to end up
46:01
in a place where you really don't know how to deal with your emotions about it because like there are expectations, there are all the sudden people you have never felt like are stepping into your space and have feelings and opinions and my biggest learning over the last couple of years and this is purely for myself is that
46:21
there is a huge difference between GitHub comments, Twitter and all that sort of stuff and then in person conversation. I was involved in more than one controversy on Twitter where like afterwards I went into a conference and talked to a person like we actually had really good face to face conversations but we interpreted the worst kind of interpretation
46:42
into each other. And I think that is like one part that I sort of definitely want to encourage people is like take advantage of conferences if you're open source maintainer. Get to like walk up to people that you had an argument with because it's really cleansing in a way to realize that the person on the other side
47:01
is not just an angry post on GitHub issues but that's the only thing that I know so far about dealing with this because it's really, really hard like creating this healthy environment. Can I add to that? Because I think one, yeah it is really difficult and I think the internet has sort of this
47:21
flattening effect. So one of the things that I noticed when I first came to Python is everyone likes to do and then I'm like will you blog and brag about your work and give people more insight and they're like oh that sounds like spotlight I would rather not. Mostly, we have a couple exceptions. But that means that like the perception of Python
47:40
is that we're this massive like tens of thousands of people like getting like awesome Google salaries like thicken your skin up, you're making 300K a year, jerk. And it's like no, no, no, this is a volunteer or someone making a nonprofit salary. And so like I'd like to really like kind of
48:03
is it like one of our challenges is to highlight like hey like you know when your landlord kicks you out like and you're homeless like maybe don't bring that same energy to I didn't appreciate the last migration process. We're not taking anything from you,
48:23
we're trying to give you something and then the complaints are, it's a lot, it's weird. Anyway, yeah. One of the very first Python meetups I ever went to I saw an 11 year old give a talk about how we should go back to Python too, actually. So you're not alone in the unhappiness with the migration.
48:43
We have another question from the audience and after that we'll probably move to the closing notes because we are already running out of time. So please ask the questions. Thanks. So I have two questions. We are all probably working in some company which is using open source software.
49:01
And I'd like to ask you first of all, what we can do to improve funding, I mean from our perspective, how we can fight for any help for open source libraries. This is the first thing. And second thing is how to, yeah, how to make this guy maintaining this small piece,
49:23
how to make this guy to get money he deserves for, or she deserves for. Because right now if somebody has a lot of stars on GitHub, it is probably kind of easy to get the funding. But this guy probably doesn't. He doesn't have so many stars
49:41
because this is, let's say, a very low level library. So yeah, these are just two questions. I'll give two answers. The first one is you should use Logfire because it's awesome and you get to sponsor Pydantic or support Pydantic through doing that. And then the second one is that I don't think we have a good solution for it. I think some of the stuff Sentry's been doing
50:00
in distributing money not just to the top level projects but to the dependencies is great. We should all do more of that. I think that there's been some discussion about more of a system of pledging in companies to do that and that would be awesome. But I think it's a yet to be solved problem and it's a really hard problem because fundamentally companies pay for stuff that they need to pay for to get it.
50:22
And by the definition of open source, that's not the case. So it's a hard problem. Yeah, I mean, I'm going to pitch our idea a little bit here which is we're toying with this idea of like open source pledging where the idea is you count the number of developers you have in a company and then you have a budget per developer and you give to the community
50:41
and you publish what you pledge as a way to encourage that all these dependencies, including these ones over there, eventually get funded. And I do want to mention this GitHub Star thing because GitHub Stars, NPM download counts, all that sort of stuff, I think they're kind of dangerous in the sense that they are elevating certain projects to visibility,
51:01
but they are not necessarily actually the ones that sort of really holding something. There are a lot of open source libraries that are published on an FTP server still that everybody's using. If you go to your car infotainment system, you will find a lot of licenses mentioned there from open source libraries that you yourself might also be using,
51:20
but because it doesn't show up, you know, packages.json or in your project tunnel, you will not see it because it's like a C library somewhere in the Linux kernel, right? So the amount of like this kind of like pillars that are holding up the world, a lot of it, we even as developers forget that they exist because they're like, they're so ingrained in the whole thing,
51:41
but they're still at the end, there's a human that still maintains this that is even less visible than some of the projects that are on GitHub. I want to say there's also a little bit of an issue with the sort of behavior that we applaud and the kinds of behavior that we maybe forget to applaud. So like, oh, wow, like you've been running that library
52:02
for 30 years, high five, I bet it's a total pain in the ass by now. But, and you know, it's like, I would rather see us be like, hey, you took on a second maintainer and passed the torch so that you can finally retire and maybe live somewhere other than Nebraska, high five.
52:20
You know, it's, we're not like, I think that should be awesome. It should be like, you passed it on, yes. As opposed to like, cool, you're just gonna die with that thing, amazing. So, you know, maybe that's like an introspection for us. Like, that doesn't really help the funding problem, but we talked a lot about funding already.
52:43
Yeah, I also like to add a few points because I actually had a total proposal on the topic, which is rejected, not this year, not this conference, don't worry. Like, I think appreciation comes first.
53:02
From X import Y, I think the first thing that we all can do, X didn't fall from a tree. It's, if you're in the Python ecosystem, it's probably built by one of these lovely people
53:23
or the other lovely people that cannot make it to here. So like, first of all, realizing all the packages that you use, there are people behind it. The second thing, like, yes, appreciation. And like, you can always, always reach out or check, like what type of appreciation they want
53:41
because not all of them want like, not once, but ready to accept the money, which I learned by surprise, like we were also running OSS funding and there were libraries that is suggested and selected.
54:01
And when I reach out to them, like they didn't even know how to receive the money. So like, I think like, that's also good because maybe they need something else. They don't need the money. I don't know. And again, coming back, like we all have employers
54:27
and if you're here, you're probably all like incredible developers or have different hats in your companies. Like, you know, you depend on like that guy
54:42
or like all the other guys. It's like, I usually start in the interview asking these questions, but it's not enough. You need to follow up. Like, hey, we're using this and this and that. We pay the Circle CI bill every month. Is it because they're not open source?
55:02
Can we please like also put our appreciation in terms of money to all those other projects that are not sending us the bill? And like, you don't need to individually go for it. Like you can take all the other like 10 other developers,
55:25
build a gang and not like, I think it's a culture. For example, I work with Django Python and when I'm interviewing, I'm asking like, do you contribute to Django? Are you like corporate member? Same, PSF.
55:43
Are you asking that question? Are we all asking this question? Shall we start asking this question, please? I think to summarize the whole thing, I think the community in general and the maintainers, everyone has a responsibility
56:01
if we need to summarize the whole conversation. For the community, and I'm not answering the funding question. I was a high paid lawyer and from there, I am working my ass off to be a technologist where I don't get paid that much. I don't understand money for sure.
56:20
But like having said that, when we are talking about appreciation for the like, I think it is a duty of the community. The maintainer is actually giving you a gift if you can think of something. Even if you don't like it, it has, say I got a gift in a Christmas and it's a red dress
56:45
and I hate red, I wanted a pink one, but I am not going to shout at the person that why did you give me a red dress? So don't do that to the maintainers. They are giving you something if you don't like. So don't bother them like a thousand meals
57:03
in like one hour or something. So that is a responsibility, like behave responsibly. And also there are norms which needs to be set by the project maintainers as well that this is not acceptable in a community. Clear your boundaries and set the boundaries correctly.
57:24
Also when Armin was saying that he, like he was completely right in saying that the people who actually look very scary on GitHub, they are not that scary at all. Essentially they are very friendly when you meet in person
57:40
because when you read the words, the words doesn't have any emotion. You don't understand when someone is showing you a thumb, whether a person is showing you a thumbs up or they're just showing that it's nothing. Like you don't understand it. Like when Armin said that I witnessed it
58:01
in 2018, PyCon India, there was one developer, his whole life's goal was to meet Armin once. And I have that moment recorded. Like he was just spellbound. So he had, like if you go to different conferences and meet people personally, you experience that thing as well.
58:22
And as Charles said that it's important to show appreciation when a maintainer, and it is valid for both the community as well as for the maintainer. So if someone pushes something which breaks your code, don't go, like as a maintainer,
58:42
don't go all blazed on that person. Try to understand why that person did it. And also if someone, like if a maintainer did something which crashed your system, don't go all blazed. So I used to think Python community is a washing machine
59:01
where all the human being comes and they become clean and they become this amazing Yodas. They don't. The social norms, the regular world norms follow in the Python community as well. So yeah. Thank you very much for the nice words at the end.
59:24
And unfortunately we run out of time, so we cannot take any more questions or we cannot provide any more answers. But I would like all of you to join me in thanking all of our panelists for talking with us here today. And a round of applause for our panelists.
59:47
And thank you to Artur for moderating and keeping us on track. Thank you, Azu.