The Challenges of Maintaining a Popular Open Source Project
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 | 132 | |
| Author | ||
| 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/44891 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 2018114 / 132
2
3
7
8
10
14
15
19
22
27
29
30
31
34
35
41
44
54
55
56
58
59
61
66
74
77
78
80
81
85
87
91
93
96
98
103
104
105
109
110
111
113
115
116
118
120
121
122
123
125
127
128
129
130
131
132
00:00
SoftwareOpen sourceEvent horizonMereologyMultiplication signOpen sourceSoftware maintenanceDifferent (Kate Ryan album)Self-organizationBitEvent horizonComputer animation
00:43
Software maintenanceCore dumpSoftware developerSoftware testingMenu (computing)CodeSoftware maintenanceBasis <Mathematik>Software testingSystem callFrustrationHTTP cookieSlide ruleHacker (term)Touch typingUniform resource locatorFilm editingVideo gameOpen sourceTwitterSimilarity (geometry)BlogPiProduct (business)Online chatComputer animation
02:28
Hill differential equationOpen sourceVideo gameTemplate (C++)Utility softwareComputer programmingFile formatFormal languageMarkup languageComputing platformFreewareSoftwarePlug-in (computing)EmailEmulationSoftware testingPrice indexSuite (music)Execution unitParsingHTTP cookieCore dumpSoftware maintenanceSoftware bugLocal ringGroup actionFlagHTTP cookieNumberTemplate (C++)Software testingMultiplication signInformationDigital photographyInstance (computer science)AuthorizationCASE <Informatik>Extension (kinesiology)Online chatService (economics)Revision controlOpen sourceQuicksortPlug-in (computing)Ocean currentBitPiWindowGraph (mathematics)Latent heatMobile appConfiguration spaceCodeComputing platformFood energyProduct (business)Directory serviceSuite (music)Computer fileSoftware bugExecution unitSpezielle orthogonale GruppeLocal GroupOffice suiteInterface (computing)Unit testingEntire functionInstallation artData structureSoftware engineeringMultiplicationCondition numberLine (geometry)Software frameworkCore dumpUtility softwareSource codeSoftware maintenanceSoftwareScripting languageMereologyDifferent (Kate Ryan album)CollaborationismDisk read-and-write headEmailServer (computing)Computer animation
12:04
Multiplication signEmailChemical equationProcess (computing)LaptopArithmetic progressionQuicksortComputer animation
12:48
Bit rateCodeSoftwarePersonal digital assistantSoftware testingBuildingRevision controlComputing platformCore dumpCodeMultiplication signHTTP cookieSoftware testingLine (geometry)MereologySource codeLibrary (computing)Latent heatFingerprintProcess (computing)Level (video gaming)QuicksortSoftware maintenanceOnline helpCASE <Informatik>Digital rights managementThermal conductivityBit rateTouch typingDifferent (Kate Ryan album)Revision controlUtility softwareEmailFrustrationControl flowTemplate (C++)Sheaf (mathematics)Computing platformPatch (Unix)Goodness of fitDirectory serviceMathematicsDistribution (mathematics)Computer filePosition operatorInstallation artSoftware developerAutomationWritingBuildingComputer animation
19:07
TorusTelecommunicationDecision theoryCodeVideoconferencingEmailProduct (business)Software maintenanceNetwork topologyProcess (computing)Software testingFatou-MengeWritingCodeSynchronizationDependent and independent variablesEmailMobile appSheaf (mathematics)VideoconferencingDecision theoryMultiplication signTime zonePosition operatorPatch (Unix)Lattice (order)CASE <Informatik>TelecommunicationMathematicsOpen sourceScheduling (computing)Instance (computer science)Expected valueSoftware maintenanceProduct (business)Computer-assisted translationLatent heatHTTP cookieProcess (computing)Extension (kinesiology)Inheritance (object-oriented programming)Thermal conductivityComplex (psychology)Universe (mathematics)Software industryComputing platformWritingAsynchronous communicationSoftwareBitGroup actionSet (mathematics)Computer animation
25:26
Goodness of fitFrustrationTemplate (C++)Sheaf (mathematics)Software maintenanceComputer animation
26:06
Capability Maturity ModelWebsiteSelf-organizationDampingVariable (mathematics)CodeDegree (graph theory)String (computer science)RandomizationKeyboard shortcutThermal conductivityParsingInternetworkingInstallation artUtility softwareLine (geometry)Software engineeringMultiplication signMereologyProcess (computing)MultiplicationCapability Maturity ModelProof theoryCASE <Informatik>Type theoryOpen sourceLibrary (computing)WordHTTP cookieConfiguration spaceKey (cryptography)Direction (geometry)Computer fileComputing platformCore dumpTemplate (C++)Point (geometry)File formatShared memoryRevision controlInsertion lossComputer animation
31:22
WebsiteSelf-organizationEmailBoundary value problemOpen sourcePlug-in (computing)WebsitePoint (geometry)CASE <Informatik>Software testingMereologyExtension (kinesiology)Slide ruleEmailBoundary value problemHTTP cookieLogic gateSelf-organizationCore dumpMultiplication signBlogProcess (computing)Associative propertyData miningQuicksortRepository (publishing)Decision theoryReal numberText editorOnline helpCommitment schemeSoftware maintenanceLoginComputer animation
36:37
Software maintenanceExpected valueElectronic mailing listOpen sourceComputing platformBitVideo gameLine (geometry)Thermal conductivityCodeNumberEmailCASE <Informatik>Machine codeDescriptive statisticsMereologyControl flowMechanism designInstance (computer science)Chemical equationComputer configurationSource codeSingle-precision floating-point formatContinuous integrationDoubling the cubeProcess (computing)ParsingScheduling (computing)File formatRandomizationRight angleInternetworkingPoint (geometry)BuildingWritingSlide ruleAnalytic continuationSubject indexingComputer animation
40:06
Software maintenanceVideoconferencingSlide ruleProfil (magazine)SynchronizationMultiplication signYouTubeComputer animation
Transcript: English(auto-generated)
00:00
Thanks, everyone. So, as Noah said, I will be talking about the challenges for maintaining a popular open source project. And I want to start with that this is my own kind of personal experience, so that doesn't necessarily apply to all of the maintainers. And there are huge differences between what people do, like, inside of or, like, as part of their role or just in their
00:21
spare time. So this is kind of my story, and I think it's worth hearing that at a community conference like EuroPython. But first, I think it's been a great event so far, and I would like to give a big hand to all the organizers and volunteers for this great event. So just a little bit about
00:42
myself. I'm a maintainer of Pytest and Cookiecutter. Both projects are fairly popular and widely used in the Python community. I also write, speak, and tweet about these topics. I will have my social handles on the following slides, so you can follow me if you want to hear about these kinds of topics. And I'm currently living in Berlin, Germany, and work for
01:04
Mozilla as a senior test engineer. This is the URL to my blog. I mostly write about Pytest or some goal every once in a while. I'm hackerbroad on Twitter and GitHub. And if you are interested in Mozilla, what we do,
01:24
our products and projects, then come find me after the talk and we can have a chat. So the agenda for today is, first, I want to kind of touch on what it means to me personally to maintain a popular open source project. And I will be using Cookiecutter as an example, but we have faced similar
01:42
challenges or problems in Pytest as well. Then the challenges of a growing community. Then just to highlight some of the frustrations for maintainers, and I will be very careful about not starting to rant about it, but I just want to give you some kind of insights in what happens on a daily
02:02
basis and kind of how you can... I think it's called to die the death of a thousand cuts or something, like what happens on a daily basis and how it can sum up to actually burning out. So I just want to kind of draw your attention to that. And then in the end, I want to give you some practical advice on what helped me personally, I think what also helped other people
02:21
from the Cookiecutter project, and maybe how you can use it for your own projects and life. So the Cookiecutter project is a common line utility, and the idea of Cookiecutter is that you have a common line interface and you feed it a template. It has a certain structure,
02:43
and then this template is being used to create directories and files and also source code for you. So we use Jinja 2 for templating, so those of you familiar with Flask, for instance, will know how it works. And then it's also working on all of the major platforms, so Windows, Mac, and Linux, and on newest version of CPython and also PyPy.
03:06
This is the URL to the project. It's hosted under Audrey's GitHub handle, AudreyR slash Cookiecutter. We use a permissive BSD3 license, so essentially you can do whatever you want to, just don't blame us if your
03:22
servers start to fire or something. We have a big number of contributors actually, so it's around 200 or 180 last time I checked, and there are more than a thousand templates on GitHub alone, and those are just public templates. Since we don't have any telemetry or anything,
03:41
we don't really know how many people actually use Cookiecutter, how many projects there are, but this is a very easy to find number by just searching on GitHub for projects that have a certain file. And we also had multiple talks at community conferences. So there is like some sort of community around the project already.
04:01
These are some of the most popular templates. There is one for just creating a Python package that you can then push to PyPI. There is a Uchi popular template for Django, which is kind of you use Cookiecutter, that template, and you have a production-ready Django app. So that's really popular and is also featured in the two scripts of Django
04:20
books from Audrey and Danny. Both also maintain the project. And then there's also the Cookiecutter Pytest plugin template, which I mostly maintain on Bruno and a bunch of other Pytest talks, and it's kind of the preferred way for how you would start creating Pytest plugins. Yeah, the project in itself is community-driven,
04:43
so it's not like we have a company or anything sponsoring the project. It's really just volunteers. You can talk to us. We use Skitter for chat, and everyone is invited to contribute. This is how you install Cookiecutter using pip from PyPI.
05:01
This is how you would call it. So we have support for some abbreviations. In this case, it's GitHub, and then it's just pytest-dev and then Cookiecutter Pytest plugin. And then Cookiecutter will git-clone the template, and you will be asked a bunch of questions or to provide information about. So these prompts are set up by the template's author.
05:27
And then based on this information, the project will be generated. So in this particular case, we created a Pytest plugin called Pytest Emoji. So I want to touch a little bit on kind of my story with Cookiecutter.
05:43
I think I started contributing maybe four years ago. And first, I just created a bunch of templates for projects that I was interested in, and I kept kind of copy-pasting the same files, the same setup UI code every time. So I created a bunch of templates, and then I heard about this new testing framework, which wasn't really
06:02
new, but it was just new to me called Pytest. And I saw that Cookiecutter had a unit test coverage of 100%, and the tests were really simple, I would say. And I took this on as a challenge to convert the entire test suite of unit...from Cookiecutter, from unit test to Pytest because
06:20
they were really separated, so I could just go ahead and gradually migrate all of the tests. That was very well received by the community. And yeah, I also helped, like, with other problems on the issue tracker and chat and all of these kind of typical things that you do in an open-source project. I also developed a number of features
06:40
and bug fixes, and then kind of things got a bit interesting because we had a number of people complaining that they can install Cookiecutter, and we had no idea what the problem is because we don't have any crazy dependencies or so. It turned out that under certain conditions on specific platforms, on Python versions, PyAML was broken.
07:01
Then we switched to RuAML YAML, which is a fork of PyAML, supposedly better maintained, but the sdist head was just broken or something, so people couldn't install PyAML and RuAML YAML, so they ended up not being able to install Cookiecutter. And YAML is really only used for a very specific feature
07:21
for Cookiecutter, so it was really frustrating kind of to being blocked by a feature which not everyone uses. So as we do as software engineers, when we encounter a problem, we just create a new problem. In this case, it's called Poyo. I read the YAML specification, and I had nightmares from that. So Poyo really only supports what
07:43
Cookiecutter does with YAML. So it's not compatible with JSON. It cannot write to YAML. It's really just getting the user configuration that we use for Cookiecutter and kind of replace PyAML and RuAML YAML, what we used before. Then I also created a project called ginger-to-time, which is a ginger
08:01
extension for retrieving the current date time, which is oftentimes used in templates to, for instance, when you use the MIT license, it always contains the author name and then the year. So a lot of the templates would do some like, please enter the current year. And then people got really upset that, why do I need to provide this? So I created this extension,
08:21
and you can just use a ginger flag or whatever it's called just now, and then we'll insert the current year into the text. And then there's also the project called PyTest Cookies. We had a number of people kind of reaching out to us, hey, my template doesn't work, or I can't use that template.
08:41
So I got frustrated and created a PyTest plugin so people actually write unit tests for the templates and don't constantly create issues on our entry tracker because template authors didn't test creating projects from their own templates. I'm showing this graph not because I want
09:00
to brag about my commits, but because I find it really interesting that for the longest time, GitHub really only valued commits as contributions. And funnily enough, the contributions of all of the maintainers have nothing to do with kind of the commit history. Like we've put in so much time and energy into maintaining the project.
09:22
And what's really only visible to the community and what's being tracked by GitHub was commits. So if you look at that, you can see kind of how I started that was just in the beginning, migrating all of the tests. And then it's just going down and down and down because I just merge pull requests
09:40
mostly, and I think that the merge commit doesn't even contribute to your commit graph, I think, on GitHub. Yeah, maybe it does nowadays, but it's just one commit, but the effort of, like, reviewing code, it takes just so much time. And then PyTest cookies and ginger time. And so, like, part of my commits were even,
10:01
like, in different projects, so it wasn't really visible to what I did on Cookie Cutter itself. So eventually, I asked the team if they want me to become a maintainer so I can use some of the tools that GitHub provides, like labels and milestones and all of these things you can only use if you're a collaborator on the project. And I felt like I had the time back then
10:23
to actually help the project. So they promoted me to be a maintainer, and I also started doing the releases and pushing to PyPI. Yeah, and then the typical stuff, like reviewing pull requests and triaging issues, which takes a lot of time. And I also spoke about Cookie Cutter
10:43
at EuroPython before, PyData, Berlin, and Glasgow, and some other local groups. And then what's also really interesting, because this was always happening just in my spare time, I was starting to explore ways so we can actually get funding for Cookie Cutter because a lot of big companies use the projects.
11:05
So I was kind of keen to see if there's maybe a way so that I can, I don't know, be paid to work on Cookie Cutter maybe a day a week or something. Turns out it's really hard if you have an open source project with people from Los Angeles, South Africa, the UK, and Germany to somehow
11:26
have a legal entity or something where you can actually receive money or do taxes. And I dived into all of this stuff, talked to the awesome people from the Django Goals Foundation, how they did it, and they were facing all
11:41
sorts of struggles to set it up. So this was really exhausting, and no one knew about it outside of the core team. But I think it's worth highlighting that if you actually want to kind of be more serious about an open source project, you will be facing a lot of struggles if it's not supported
12:00
by a company that pays you to do it actually. Yeah, and emails. So I have tried to find out how many emails I got in this time. I think it was, at peak times, it was maybe 40 emails a day. And those emails might be just someone updating their pull request or something really minor, but it's still like you get the notifications all the time,
12:23
and it's outside of business hours. So it's not like a job where you can just put away your work laptop and then forget about it, but you just keep constantly getting emails about all sorts of tiny things. So that doesn't really help with maintaining a healthy work-life balance, I think.
12:42
So I want to get to some of the challenges that we faced because the community grew so quickly. So first, I think it's important to highlight not only for Cookiecutter, but for all projects. You will always attract users at a faster rate than contributors. And then also, the rate at which you
13:03
attract new contributors is also way faster than people who actually have the time, are privileged enough to have the time available to step up and actually maintain a project. So the reality of Cookiecutter is that there are thousands of users which we don't really know because, again, we don't have telemetry or anything. But since there are so many templates
13:23
and we get so many requests, it must be thousands. We have, as I said, 180 contributors and the core team is five people and no one is paid to work on the project or has, like, resources available to actually do it for a specific
13:42
time or anything. So what are the learnings from this? I think, so maybe I should also say about how this section of the talk is structured. So I want to kind of highlight the challenges and then provide you with some of the learnings. So maybe you can take some of these for your own projects. So after each topic, there will be some
14:01
learning section. So I think what's really important is that you should try to make your project really easy to contribute to because there is no way that you can do all the work yourself so you rely on people to step up and provide patches and all these things for you. Then it's really important for
14:20
yourself but also for the wider community to adopt a code of conduct and also enforce it because there will be people with toxic behaviour who are abusive to other community members but most likely to you as a maintainer because you always are the contact person for all frustrations. So it's good to have a code of conduct in place and then also have the
14:43
strength to enforce it. Then always have empathy towards others but also towards yourself. So be kind to newcomers, be welcoming because otherwise you will never kind of help a user become a contributor if you don't really show empathy and try to grow them into the contributor stage. And then write good
15:05
documentation because if you kind of put all of this knowledge and these learnings into documentation, you will spend less time on actually repeating the same kind of stuff. And then lead by example. I think that's really important. If you are a toxic maintainer, there's no way other people will be
15:23
better than you. So be kind, have empathy and be a nice person overall. Project scope. That's an interesting one for Cookiecutter because people came up with all sorts of interesting ideas how they use the project. So we get those emails, yeah, at work we do this blah, blah, blah and it's part
15:43
of our deployment pipeline and this and that. And you will be facing like issues about use cases that you just never intended before. And it's important to listen to those people but it's also important to kind of be specific about
16:02
the project scope and say, well, this is just a common line tool that creates files, directories and source code but it's not like setting up your Kubernetes cluster or anything. It's like just be specific about the project scope and document it. And then in the case of Cookiecutter, it's also really interesting that a lot of the people who encounter problems with templates will raise issues
16:22
against the tool. Yeah, so that happens a lot and I think it's probably could be better in the Cookiecutter documentation kind of to explain the concepts that there are templates and there is this tool and this belongs here and this belongs there but also maintainers of templates kind of need to
16:43
do a better job of showing how to get in touch when there is a problem with the template. Yeah, so about the project scope, encourage your users to build tools on top of your project. So we offer a Python library, so we have a comment line which uses the Python library. So if there is a use case which
17:02
is outside of the scope of the comment line utility, maybe people will just use the library to create a new tool and that's perfectly fine. So I think that's important to encourage people to do. Then always ask contributors to develop automated tests, write good documentation for new features because you don't want to merge some code and then have to kind of write the
17:22
documentation afterwards or write the tests or anything. So each change needs to be kind of like contain all of the things that you require a change to have. And then again, write documentation, describe the project and its scope. Breaking changes. So I mentioned kind of the platforms
17:41
and the Python versions that we support. And there are also people who kind of push CookieCutter to different package managers. So there's, you can install CookieCutter via Conda, via Homebrew, there's a Debian package, there's an Arch package. Like people created all of these different distributions, but then when something breaks,
18:04
they will still come to CookieCutter. And like I have no clue about Debian, so I wouldn't be in a position to even like understand what the problem really is. So again, this is kind of maybe a documentation problem,
18:21
but that's not something that we kind of anticipated when we started the project. So all of the changes that go into the project need to be carefully considered and thoroughly reviewed. Because if there are so many people using your project, you want to be careful about not breaking anything. Because for one, it's the good thing, like the right thing to do,
18:45
not breaking people's stuff just because you're sloppy or because you're a bad person, but also because people will raise issues with you if something breaks. So it's kind of protecting yourself is kind of part of the thing. Yeah, so be careful about adding new features,
19:03
test your projects on the supported platforms and Python versions, write documentation, and also say no. Like if there's someone with a very, very specific use case, you should say no and please build a tool on top of our Python API, for instance. Workflows. As with many projects,
19:25
Cookiecutter, we have asynchronous communication. So Danny Audrey, based in California, that's nine hours time difference to Berlin. South Africa is the same time zone as Germany, and the UK is just one hour. But still, like a lot of the communication will happen
19:40
synchronously over GitHub issues or emails, which makes it kind of hard to decide on specific things. Like if there is a problem and you want to have a discussion, it's really hard to do that if it's not happening in real time. Yeah, so you kind of want to have guidelines for how you want
20:02
to merge code and ensure that the code is actually maintainable, idiomatic Python code, and tested and documented so that in case someone isn't available or just, I don't know, isn't as responsive as usual, you kind of want to have this document so you can rely on that. And then also for the longest time, it was a bit of a problem that GitHub
20:22
didn't really have many tools to help maintainers. Like I think assignees for pull requests or... Yeah, like it was really hard in the beginning to... I think you also... The code reviews were made in a way that you get an email for each of the comments on a pull request rather than submitting one review
20:43
with all of the comments. So if we had a large patch and we had someone reviewing that, I would get 30 emails. And that was just not really nice. So some of the learnings are set up meetings of a chat or video or something
21:02
if you really want to have a discussion. And then be sure to document your decisions on an issue or a pull request or the documentation so that the community understands why you made the decision and you don't get bothered afterwards. Why did you do this? And then walk towards making yourself redundant. So you want to kind of don't want to be the bottleneck for the project.
21:22
So be sure that the code isn't super, super complex and there is just a single person in the universe to understand that code. You kind of want to be sure that everyone can technically step in and do your job in the project. And then for the GitHub, I'm pretty sure it applies to most other platforms
21:44
as well, is kind of try to reach out to other maintainers. So we talked to folks from, I don't know, the JavaScript community and we talked about everyone is having the same problems. So kind of if you group up together, you can actually reach out maybe to the product folks and suggest
22:01
features, which I think helped to some extent. And then what's really important, maintainers are humans. Some people seem to forget that, but in the case of Cookiecutter, we're just volunteers. So like when we review code that's outside of our working hours, for me, that was mostly at night and didn't really help me
22:25
maintain a healthy sleeping schedule. So that's just a very bad idea and people seem to forget that this is the case for a project like this. And then every maintainer had their own reasons why they started contributing
22:40
to a project or why they decided to step up and take on the responsibility of managing the project. And this changes over time. Just to talk about myself, like in the beginning, I was working for a software company. We only worked on proprietary code. So contributing to open source was a way for me to build up a portfolio so that I can show some code when I apply somewhere else.
23:04
So my motivation was never to kind of receive 40 emails a day, but I just wanted to demonstrate that I can actually write good code. And then because I was spending so much time on the project and I really liked the team and I found it useful myself, I kind of grew into this position of a maintainer. And then I felt ownership and responsibility
23:24
over the project, which is why I just didn't step away, even if I sometimes were stressed out or so. But I think it's important to keep that in mind that, like, this is really just people volunteering. So the maintainers for this section...sorry, the learning for this section
23:41
are pretty much stick to best practices so that if you know how to write Python code, you should be able to contribute to cookie cutter. Don't use super special things or crazy dependencies or anything. Make it easy for people to contribute. Then document the process of bringing on new maintainers, which is really important.
24:02
So a lot of the projects don't really have this documented. What do I need to do to actually become a maintainer? And I don't really believe that we have this super well-explained for cookie cutter as well, but I think it's important so people can kind of know what they have
24:20
to do if they really want to be more involved in the project. And then really important, do not tolerate toxic and abusive behavior from community members or users. This is really important and it's hard if the same people keep kind of sending you a nasty email. So it's important for yourself and for the project to exclude those people
24:42
if they really violate the code of conduct. So this brings us to expectations. I think everyone using a project or contributing to a project or maintaining a project has a certain set of expectations and it's really hard to manage that. So you can really please everyone and
25:04
I think it's just important that you also document kind of what you can kind of expect as a user, as a contributor. For instance, saying, yeah, well, we don't offer 24-7 support. So if you break your deployment,
25:21
then that's your problem and don't send us emails. And as you might have noticed in a lot of those sections, I have mentioned documentation and for me, I think that's the major takeaway that if you have good documentation for users, for contributors,
25:41
for maintainers, for template offers, chances are that people will be less likely to ask you the same questions over again and if the documentation is good, people will also read it. So I'm a big advocate for writing good documentation. It's really hard, but I think it's worth doing.
26:02
So I want to touch very briefly on some of the frustrations and then kind of highlight why this is a problem. The first one is bike shedding. So I already mentioned that we had problems with Yammer. And then when we had an issue just debating over what shall we do to kind of solve this Yammer issue? The first comments were, well,
26:22
why don't you use Toml? Then comments, why don't you use JSON? Why don't you use hjson? Why don't you use config parser? Why don't you use blah, blah, blah? And kind of we as maintainers, we just wanted for people to be able to install Cookiecutter. Like we support three key value pairs. We don't care what format that is.
26:44
You can technically just use a text file and parse it. So having people stepping in with a lot of opinions is really hard in those cases to not get frustrated by that. And the Yammer thing is really just one thing.
27:00
Why do you use six for Python 3 compatibility? Why don't you use future? It's much more lightweight. It's just like 2 kilobytes instead of 5 or something. And like, well, we want to support all of these platforms and we don't want to maintain a compatibility layer ourselves. And six has proven to be working, so we don't care. It's 40 kilobytes or something.
27:24
It's a common line utility that you install once. It's not something that you constantly download and install as part of your process, deployment process. And then people oftentimes said, we need this at work. And when someone opens an issue and starts with a sentence, I turn off immediately, mostly,
27:45
because people who use our tool at work are probably the most demanding and they have the least empathy for that we are just volunteers. And that's really frustrating if people use our project during their working time
28:01
and then they demand support from us in our spare time, which was at night for me. So just be mindful about the fact that people are volunteers. And it's not the case for every open-source project, but I think a lot of the very important Python projects in our ecosystem are maintained by just one
28:23
or two people and mostly in their spare time. So it's important to keep that in mind that even if you rely on the tool as part of your job, kind of take this into account and kind of think about the wording. Yeah, this is a very common one. Like someone used our tool in an
28:40
unintended way and somehow we broke their new release or something. And I can't really say I'm sorry. I would rather say, well, you should be a better software engineer and don't rely on, like, the latest master or something. Like, you should pin your dependencies or maybe, I don't know, have a vendor or a tool or something.
29:03
But, like, this is your problem. This is not my problem, really. Then, again, so Puyo is kind of this library that I wrote to parse the YAML configuration. And this is a quote. So someone said, and this Puyo introduction is a great example how direction of cookie
29:22
cutter can seem immature to my eyes from times to times. And that's interesting given that Audrey has multiple degrees from MIT and worked at Microsoft and Danny worked at NASA and they both wrote the two schools of Django books and I feel like I'm experienced enough
29:41
to write good code. So it's interesting when some random keyboard cowboy from the internet tells you that you're very unprofessional in the way that you lead the project. But it's, in this particular case, that person kept repeating the same behavior. So at some point, we actually pointed out that this is violating our code of conduct
30:01
because they're really abusive towards the core team and we didn't have to exclude them, but they kind of decided to step away from the project. So that was good. But without the code of conduct, we wouldn't be able to actually point out that they are actually doing something wrong. So my recommendation is use a code of conduct that you feel less is kind of matching your project and then enforce it for your own sake
30:25
and for other community members as well. Yeah. Can't you simply? Don't even need to say anything about it really. Yeah, no, we can't. Yeah. Something that someone said. So I created a proof of concept
30:47
pull request where I was adding types to cookie cutter variables. So currently, it's really just a variable and it's text. And a lot of templates, they would like to have, say, a boolean variable or a float
31:02
or a string so that when you render your project, you actually have typed variables and can do more advanced things on that. And I had this need as well, so I created a pull request which was kind of ready to merge, but it was more or less just a start for discussion if we actually want to take
31:22
on this extra work of maintaining that going forward. And then we made a decision as a core team that if we do this, we need some real sort of sponsorship because the people requesting this feature were companies building editor or plugin extensions or whatever based on cookie cutter. So they had kind
31:45
of the real interest in this feature. And while we needed it as well, we kind of felt like it was just fair towards the team if the companies would actually help us in maintaining the project. So we started a discussion
32:03
on how can we actually get funding and sponsorship for the project. So some people just said, well, not sure how much sponsorship is needed, but here is a site for allowing the crowd to contribute as I know my organization would be interested in helping. So Danny created a Patreon. He gets $2 a month. I have a Patreon. I get, I think, $51 a month.
32:23
And I get this money from Russell Keith-McGee who used to be the president of the Django Software Foundation. He's a contributor to cookie cutter and I don't want his money because he's been giving so much to the community that I really don't feel like he should be using the money from his spare time
32:42
projects or like he doesn't get any money. So it's his own money which is going into cookie cutter. Carol, she's a PSF or used to be PSF director. Then a couple of my friends donate to my Patreon. I think there are two people which don't have an association with the project itself or friends of mine.
33:02
So it's kind of interesting to see how many people suggest for us to kind of make the work of setting up an open collective or a Patreon or a Kickstarter but then in the end, no one actually contributes to any sort of sponsorship or funding. There is a lot of unseen work.
33:21
So every time at EuroPython, I ran a sprint that was mostly for PyTest. We also made the effort of ordering stickers, kind of just advocating for the project, then exploring all of these ways to get sponsorship, then submitting talks to community conferences. So I try to speak every time, every year at a couple of conferences. So that's a lot of work,
33:43
just writing the proposals and submitting them and then also kind of working on the slides. And it wasn't part of my job back then. Today, I'm fortunate enough that Mozilla actually supports my work on this.
34:02
And then the suggested solutions that come from the community or other folks oftentimes require even more work from maintainers. So the sponsorship is a good example, like why don't you just set up an open collective? So then you spend a weekend on setting up this open collective and in the end, no one actually donates. So it's kind of also quite frustrating if the solutions
34:25
that are suggested to you require you to put in even more work, which is kind of what you want to avoid. And then people don't respect boundaries. So I don't know why, but people sometimes don't create issues
34:43
on our issue tracker, but they send emails directly to us. And in some cases, it's interesting because I don't have my email public on GitHub. Yeah, I have the email because in Germany,
35:00
you are required to have an imprint. So I have my contact details on my personal blog. So someone would be...it's really easy to find out my email. But for some other people who got contacted, they don't have this anywhere public. Outside of the Git commit. So apparently, some people make the effort of cloning a project and looking at the Git log and then using that email
35:21
to contact people and ask for support. And I think that's really shady, and you shouldn't do that. Like, please respect boundaries, especially if the people work on that as part...well, not as part of the job really. So don't do that. And then a realization that I made
35:42
over the course of these years is that at some point, maintaining open-source projects is really just work, which you're not paid for. And you don't have paid time off, and you don't have health insurance, and you don't have working hours. But it really feels like work. So I think it's important to set
36:01
boundaries for yourself. So you can use tools maybe to delay emails to be sent to you outside of working hours or something. For me, that's mostly unsubscribing from the notifications on GitHub, and then I just check the repository if I feel like there is a need for me to, or if I feel like I have
36:21
the resources available to actually work on the project. And then I think it's a general lack of empathy towards other community members, but also maintainers, which is, I think, the underlying problem. So I want to get to the takeaways for the maintainers. So first, set expectations. I think it's
36:46
really important that projects have a clear description. What does a project do? What platforms do you support officially? What does the project not do? So when I started adding it to Puyo, I added this line.
37:00
This is not compatible with JSON, and it cannot write YAML. Once I added this to the documentation, the number of issues that were created decreased drastically. So just like those two sentences pointing out that my project is not the fancy new YAML parser for Python, helped quite a bit in reducing the
37:22
amount of emails that I got. Then work towards making yourself redundant. So use tools like continuous integration, use documentation generator, write simple idiomatic codes, like stick to best practices. Nowadays, we have black-to-auto-format codes. I really like that about Go that I just
37:44
don't have those stupid discussions around whether we should use single quotes or double quotes. Like, use those tools and stick to best practices because it will make your life much easier because you don't have those discussions, which are really pointless. And then say no. Like, if people have some
38:01
really exotic use cases for your tool, don't feel obliged to maintain this as part of your tool, but encourage people to build tools or project on top of your project, if that's possible. Then lead by example. I think it's just important as a maintainer to kind of showcase what kind of behavior you would like to have for
38:23
your community. So don't be snarky or abusive or anything, just like we see sometimes on a Linux mailing list maybe. Be nice to people and have empathy. And then do not tolerate toxic and abusive behavior. So adopt a code of
38:44
conduct and enforce it. This is really, really important if you want to attract more contributors and keep yourself safe from toxic members. And then allow yourself to take breaks and even walk away. So I think it's important to keep in mind that as a volunteer,
39:02
you always have the option of just taking a break and be absent for days, weeks, months, and maybe even forever. That's a perfectly valuable solution. Try to kind of document the process of bringing on new maintainers if you care about the project so that the project in itself doesn't die.
39:23
But since it's also open source, you're not really the owner of the source code, so just kind of keep that in mind that it's out there. Just put like mechanisms in place that you can go away. So for instance, if you rely on PyPI releases, be sure to add more index maintainers to the project.
39:43
And then take care of yourself. I think that's the bottom line for me as a maintainer and to other maintainers. Maintain a healthy work-life balance and open source is work at some point. Don't sacrifice your sleeping schedule
40:02
for reading emails from random people on the internet with opinions. And that's it. Thank you so much. I will publish my slides later.
40:21
That's my speaker deck profile. I will push them later on. Thank you. Okay. And the speaker said that we don't have the Q&A, so if you have any question, please come here briefly. And by the way, I think the speaker gave us many tips or advice for contributor and maintainer and are really useful.
40:43
So if you have a question, please review the video on YouTube again. And next time, we are giving a warm welcome to Mr. Dwaafar again. Thank you.