Keynote - The art and science of tending open source orchards Keynote

Speaker 1 [00:07]

I lead open source program at open teams focusing on widening contributor pipeline and bringing funding to more open source projects. I also, as you heard, contribute to quite a few open source initiatives and projects in the scientific Python ecosystem and broader open source. So it's fair to say I live and breathe open source. So with the history of free and open source software, we have gone through quite a few metaphors for it. From homesteads in Noosphere, to poppies, to roads and bridges, to gardens, forests and orchards. Regardless of the preferred comparison, open source veterans researchers and pundits agree that behind every thriving open source project is a community of dedicated users and contributors. Because community is only as strong as its members' commitment to it. And today, I would like to share some of my reflections and insights into the art and science of fostering strong and resilient open source communities. And to make it a little more fun and relatable, I will use orchards as a metaphor for them. Just like in open source, most of growth and development in orchards happen in the open. And there are, of course, fruits of labor. and I go way back. My home country, Ukraine, is blessed with many gifts of nature, including fertile soil. The house where I grew up had about an acre of land where my parents and grandparents grew a wide variety of vegetables. We had a few rows of grapevines, too. But my favorite part was an orchard with mostly cherry trees. As a matter of fact, my very first money was made by picking cherries and selling them at a farmer's market at the age of nine years old. Who knew that 30 years later, I will be still cherry-picking, get cherry-picking for a living? In preparation for this talk, I went through all my family photo albums that I brought from my last trip to Ukraine, hoping to find photos of me in the garden and orchard. Believe me, I spent a lot of hours in that orchard. I had no luck. Cameras were not as ubiquitous in those days. However, I uncovered a photo of my mom with her sister pulling weeds in our family garden when she was about 10 years old. So the younger person on the photo is my mom. And that photo reminded me of the issue trackers of some mature Python libraries. Before we dive into the art and science of tending open source orchards, and by the way, any human activity is in part art and in part science, I'd like to mention that just like there are different species of trees, there are different types of open source projects. And in this talk, I will be referring to community-owned open source projects. This type of software projects are developed and maintained by contributors from multiple organizations, and independent volunteers, and where, to the maximum extent possible, decisions about project direction are made by community consensus. Oops. I heard that internet in Berlin sometimes is not great, so maybe this is one of those instances. All right. So, I'm going to give a shout out to several projects that are community-owned, and for some reason we cannot see them, but here we go. NumPy, Xar, AstroPy, Scikit-learn, Scikit-image, CondaForge are examples of community-owned open source projects. Also in this talk, I am not trying to convince you about the benefits of open source. Even though I'm obviously a believer. Something tells me that I'm not the only one in this room. Please raise your hand if you have contributed to open source at least once. Great. Keep your hand up if you regularly contribute to open source. And continue keeping your hand up if you're an open source project leader. We have about a dozen, maybe more, great. It's truly exciting for me to see so many open source contributors in this audience. Let's get back to the art and science of community building in open source. Why does it matter? I started my journey in tech close to 20 years ago. And early in my career, I was naively convinced that the quality of code determined the success of software. It is certainly true, but to a degree. Yes, software must provide solutions. Ideally, it should be a useful piece in a larger solution to a larger problem, part of a tool chain. However, it's the people, the community, the culture of the community that determine the destiny of software, especially in open source. And when we talk about the open source community culture, what we really mean is the sum of values, moral and ethical, technical infrastructure, social infrastructure, which serve as glue in onboarding and supporting users and contributors to an open source project. In practice, for an open source project to have a good culture means designing and providing a positive user and contributor experience. So how can you support the community of users and contributors to your open source project? Just as preparing fertile soil is essential for a healthy orchard, deciding on governance at the constitutional, collective and operational levels, software licensing, how your software can be used, putting in place a code of conduct and infrastructure around it to ensure a welcoming and friendly environment in online and brick and mortar spaces of your community, and any concerns I address as they arise, deciding on all of the above is crucial for giving your open source project the best start. In my observation, many inexperienced open source authors hesitate to make these decisions early on in fear that the introduced policies will not anticipate the needs of the growing community. It's true, a contributor community of your project grows exponentially, most likely you will need to review some of your policies to serve the needs of the new members. However, to get to the point of growth, you really need to make these decisions early in the project's life cycle. And here's a public announcement and a fresh case study for you. NumFocus, their organization that needs no introduction in PyData events, is currently in the process of reviewing and adopting a new code of conduct and establishing a code of conduct working group. Having experienced significant growth in the past decade from four to over 140 projects, well done, NumFocus, the needs of the non-focused community have changed and the non-focused leadership is responding to them. And when it comes to governance and policies make sure to outline how your contributors can progress to leadership roles if you'd like your contributors to stick around and take on more responsibilities. You also need to think about leadership succession and rotation. Being a team lead or a core team member shouldn't be a lifetime position. For an open source project to grow, great documentation is key. Once you reach the better stage in your project's development, invest your time in good documentation. Ideally, it should come in a variety of formats. streams, user tutorials, contributor guidelines, YouTube videos, and even comics. For an open source project to thrive, it needs contributors with a variety of skills. Technical writing, user research, graphic design, web development, dev rel, community building, fundraising, event organizing. By the way, events like this are a great fertilizer for an open source orchard. Thank you to all the volunteer organizers of this conference for helping the PyData SciPy ecosystem thrive. To signal to newcomers of your project that there is work to be done outside of the codebase, include all these project needs in the readme on GitHub and project's website, and here's how we did it in NumPy, one of the projects I contribute. Just as saplings need care and attention to grow, newcomers to the community require support and mentorship. Timely responses to usage questions, timely and thoughtful code review nurture your future community champions, active contributors, and core team members. Timeliness is important, but even more important is providing a safe, psychological environment for learning. Unlike on a commercial dev team where you can hold four rounds of interviews to choose who joins your team, you can't screen contributors to your open source project. Some of them will be seasoned developers who will help you take your project to the next level. You will also have less experienced developers who will need your guidance. We're all new and inexperienced in something. Threat-based parallelism and recursion might be easy for you, but how about Kubernetes or cryptography? If you want this orchard to grow, it will take a lot of patience. Hopefully, the people you mentored will pay it forward by mentoring other newcomers. Introducing a team of mentors also can help. I started one for NumPy two years ago, and these are the people that I asked to help with in-person and virtual newcomer sprints and also hosting newcomer's hours. Speaking of sprints, this is something I highly recommend to every new open source project that aspires to grow its user and contributor base. These sprints are a great way to connect with your users and potential contributors. And the feedback in real time will help you identify gaps in your documentation and overall developer experience. I would like to give shout out to several projects in the Python community that have been hosting excellent sprints for newcomers for several years now. Pandas. Scikit-learn and PyMC in partnership with Data Umbrella. Matplotlib. SciPy. You can't even see sci-fi. I can see it. But you see hypotheses. So why do people contribute to open source? Why do they decide to contribute their discretionary time to something that is hard, time-consuming, and can be stressful at times too? And how do they decide which project to contribute? I spent some time researching this topic in the past five years. My findings are a combination of qualitative research and the analysis of the data collected through the NumPy user surveys. Contributors' motivations widely vary and also evolve. Many start contributing to fix something that will help them in their day jobs. And if they had a good experience, they will return. This brings us to contributor retention. This topic comes up pretty often in my conversations with long-term maintainers. All maintainers who dedicate time to mentoring members of their community hope that their mentees will stick around. But as it happens in many volunteer-powered organizations, not all of them do. Contributor churn is a part of the process. To make it less painful, invest your time in the project's documentation. If a contributor didn't read it, you have something to point them to or simply copy-paste from. What makes volunteer contributors stay with your project? Friendly and welcoming community, timeliness in communication, opportunities for professional development, to get better at something they're actively working on, to get better at something that they don't get to do in their current job, take on leadership roles. Community events such as sprints, workshops, webinars, meetups, conferences, our brains are hardwired to motivate us toward connection and belonging. It's how we survive and thrive. Recognition. Early in this presentation, I made a point that the culture of the community determines the destiny of the open source software. Much of a community's culture is defined by what happens outside of the code base. Engaging in discussions on the issue tracker, mailing list, Discord and Slack channels, hosting sprints and discussions at conferences, educating users and developers through presentations at events, engaging and educating potential funders. This essential work on community building and project sustainability is often invisible, particularly because the contributions are relatively hard to track. If you wish for your contributors to stick around, you need to think of the ways to recognize all the contributions. As you can tell, there is a lot of work outside of improving and maintaining your software code base for this orchard to thrive. Experienced open source horticulturists will say writing code is the easiest part. Watching your open source project grow is very exciting but also can get overwhelming. So let's talk about gardening tools. There is no definite consensus among open source project leaders and researchers on how much of the tasks and processes are optimal to automate in project maintenance. So this is my findings and my recommendations. I recommend automating processes to make space for interesting, insightful, and fun conversations in your community. Where do you automate? Use linters. Linters help make your code more readable, maintainable, and overall of better quality. It's a great way to educate newcomers to your project about your code style preferences and reduce discussions on aesthetic choices during code reviews. If you're hosting your project on GitHub, take advantage of saved replies. When commenting on an issue or pull request, you can add the saved reply that you've already set up, and the saved reply can be the entire comment, or if you want to customize it, you can add or delete parts of it. My rule of thumb is if I hear the same question three times, I will create a saved reply and also consider adding it to the project documentation. I must say this is more of a semi-automation. GitHub project boards. They are a great tool to organise your work and your team's work. Use all contributors bot. This bot allows adding anyone as a contributor to a repository without the requirement of an actual code commit. For example, code review feedback and comments and the issue triage are important and valuable contributions to any project, but invisible on the GitHub contributions scoreboard. Custom bots, including GitHub actions. For this one, I'd like to highlight the peer review bot created by PyOpenSci, an open source initiative that facilitates the open peer review process to help scientists to get credit and recognition for the work they've invested in developing scientific Python software. Peer review of software takes significant time, and the PyOpenSci process is fully volunteer-led. So the PyOpenSci team has developed a bot leveraging the tooling developed and used by the Journal of Open Source Software and our OpenSci to streamline the peer review process for their editorial team. What should you automate? Don't close inactive PRs with bots. Contributors really don't like it. Community engagement. Many communities like using welcome bots. They could be used to point newcomers to the community events calendar or the best communication channels for newcomers, but I wouldn't use them as the only way to greet newcomers. Human interaction is what fosters a sense of community. Sensitive discussions, including conflict resolutions. Very few people truly enjoy doing this work, but no, you can't delegate it to a bot. And a few final observations on the art and science of tending open source orchards. You will need to get comfortable with a certain level of chaos. Keep in mind, you are working with volunteers, deadlines will be missed, you should still set them. There will be bad actors, hopefully not at the level of XZUtils, but you never know. You still need to learn how to develop trust with total strangers. Contributors will go quiet, sometimes in the middle of working on something fairly important to you. They might come back in two years and become your community champion. Never hold a grudge. Stay open and stay transparent. Discussions and decisions should be transparent to all of your community members as much as possible. If you are new to this, I promise it will grow on you. I was one of them. Practicing transparency is essential for your community members to trust your leadership. And just like for any gardener, there is always work to do in an open source orchard. Refactoring code, solving technical debt, updating documentation, supporting newcomers, supporting active contributors, supporting core team members. Yes, it's a lot of work. But what a joy to watch this orchard grow. Thank you so much for having me.

Speaker 2 [21:23]

Well, thank you, Inessa, for this nice walk through the orchard of open-source software development. I'm not surprised that we didn't hear about apples at all. So there's a couple of questions that are coming from the audience. So the first one would be, how would you define a sprint in the context of an open-source project?

Speaker 1 [21:43]

I was expecting that question. I'm guessing it's coming from somebody who is fairly new to open source. Sprints are events, usually a day-long event, but sometimes they span over several days, where you get together in one room. It can be also a virtual event, where you work together on the same set of issues or on anything that is currently on the issue tracker. Think of it as a coding session and a bit of pair programming session. And there are two types of sprints, development sprints, where usually you will find more experienced contributors. And then there are newcomer sprints where people with some coding skills join, but they're usually very unfamiliar with your code base, so you will have to show them around.

Speaker 2 [22:49]

Thank you. Another question, very highly rated here on our review on Slido. So what is your opinion on large companies investing into open source communities, like, for example, when Microsoft took over GitHub?

Speaker 1 [23:12]

It really depends on what happens after the acquisition. If the initial promise to the contributors is capped, I don't see a problem with that. I think it's great to have sustainable funding for the open source project. Where it gets problematic is that a product was a software, where an open source software was built with the labor of volunteers, and then there is a change in licensing, and the same volunteers cannot use this project for free.

Speaker 2 [23:58]

Thank you. The next question is somewhat along the same lines. So increasingly, commercial entities like, for example, Meta, are dedicated developers to impact open source. How would you nurture this flavor of the orchard?

Speaker 1 [24:18]

I think it's important to establish guardrails for the corporate entity. It really depends. But let's say there is a community-owned project and corporation wants to have this project to be sustainable. Great. however it is very important for the governing body of this open source project to communicate to the corporation is that it is still it remains community owned and meaning that they cannot, the corporation cannot steer the development of the project multiple stakeholders should be involved in developing the roadmap developing new features still should remain community-owned.

Speaker 2 [25:17]

So the next question is a more practical one about the management of open source development. And I think we all know a person like that. So do you have any advice how to manage strong personalities in an open source development setting without being discouraging?

Speaker 1 [25:37]

Well, strong personalities happen. This is what you get when you get a lot of brilliant, outspoken people in one room. I think that's why we need code of conduct, and also we need to remind the people with strong personalities that this is a community project, and if they don't want to respect other people's opinion, maybe they should start their own project where they decide on the rules.

Speaker 2 [26:10]

OK, so sometimes it's not about those strong personalities finding a new project. There's a very relevant question. I mean, when you asked about it in your seminar just now, lots of hands went up. But there are still developers who don't contribute to open source. So the question is, let's say I want to contribute to open source now. How do I start or find a project to work on?

Speaker 1 [26:32]

I get this question a lot. I would say start small. Start contributing. Think of the open source projects that you currently use. Most likely quite a few of them will be open source. Most likely they will be looking for contributors. I see that the best contributors are those who are pretty confident users of the software. Also, if you're very new to coding in general, consider, evaluate your skills. Everyone has strengths. And see which community you like and contribute the skills that you have. Maybe you have great graphic design skills or you're good at writing and maybe could help with educational materials and technical documentation.

Speaker 2 [27:27]

Yeah, maybe note for myself here, go and have a look at those larger projects. There's a lot of them that tag their issues as good first issue to work on. Try to pick one of those just to get into the flow of, you know, actually creating a pull request. And it's all go from there. The next question from the audience is actually for the audience as well. So the question is, who in this room contributes to an open source community and your boss is paying for you as part of a training budget or something like that? Maybe a quick show of hands.

Speaker 1 [28:02]

We didn't get even a dozen

Speaker 2 [28:05]

It looks like it's not that common, actually. OK, another very relevant question for open source projects. So do you know of anyone who is providing any help on the legal side for open source projects? For example, licensing, but also setting up the legal entities that run them.

Speaker 1 [28:23]

Do I know anyone? Yes, I do. There are lawyers in the EU and the US who specialize on licensing. I can connect them to you. Please reach out after the talk. It is a very important topic, and you need to make this decision early on.

Speaker 2 [28:45]

Excellent. The next most popular question is sort of similar, but along a different vein. So is there an entity that can provide feedback on how to improve an open source project for the community?

Speaker 1 [28:57]

Is there an entity? Yes, it is. One of the projects I work on and started is called Contributor Experience Project. And please reach out again if you have questions. Also, if you're working on something in your community that you're proud of, please share. I'm always on the lookout for good ideas and case studies.

Speaker 2 [29:23]

I really like the next question. So in the wake of the supply chain attack on the XZ project, how do we deal with trust issues in connection with working with strangers on open source projects?

Speaker 1 [29:38]

Yes, I've been thinking a lot about it after the latest incident. I think it will be important to reveal your identity. I know some developers, for various reasons, prefer to be anonymous. I think if you want to rise in leadership, you will have to be prepared to reveal your identity because quite a few people are nervous after ex-Utils incident.

Speaker 2 [30:14]

Quick note for myself right this attack could have been carried out in proprietary software as well But it was discovered because it was open source

Speaker 1 [30:21]

I fully agree with that.

Speaker 2 [30:24]

Okay, so you've talked about maintainers and maintainer fatigue, right? The next question is how do I communicate that I don't want to maintain a project anymore if there's nobody else to pick it up?

Speaker 1 [30:38]

You still have to communicate it to your community. I really like the... comparison of open source, open source projects to orchards because here's the thing. Your orchard can go with no maintenance for some time. Sure, it will get wild and bear less fruit, but it can continue for some time. So it's okay to step down, step away, even if you don't have a successor. I think mental health and And health in general is priority. After all, it's just code.

Speaker 2 [31:31]

Okay, so you sort of touched on this earlier, but maybe you can expand on it So what is your opinion of generated code or PR descriptions by Jenny? I is that a do or don't for the automation of some processes

Speaker 1 [31:44]

Great question. Somehow I knew it was coming. I haven't experimented much with generative AI. Not yet. But I don't want to be a Luddite in this room. I think there are definitely applications for generative AI to ease the burden of maintenance. And like good scientists we are. we need to experiment. So not a definite answer. Let's see what we can do.

Speaker 2 [32:24]

Excellent. So if you're working on open source software, how do you approach cultural differences in communication? For example, Europeans versus US versus Asia, Asia Pacific, I suppose, Africa, South America. How do you deal with this?

Speaker 1 [32:42]

There will be definitely differences, and you need to keep it in mind as a community manager, as a project leader. I would say at the core, we share similar values. Being respectful to somebody's opinion, regardless of their standing in the community, whether they've been contributing for a year or 10, is important. And it gets difficult at times. And I really don't have a good answer for it. I think that's why we have open source projects sprouting out in different countries. And depending on what country the post-maintainers are in, you might have a slightly different culture. but I think at the core we want the same we want to be appreciated for the work we do we want to be treated respectfully friendliness and welcomeness has no borders

Speaker 2 [33:51]

Excellent. And with that, I would like to thank the audience for this wonderful Q&A question sessions after this keynote. And please join me in thanking Inessa for her wonderful seminar.