## Theme ## Takeaways 1. Juliet is a global maintainer of many different open source packages. 2. An incidental maintainer is someone who takes over the maintenance of projects that were on the verge of being abandoned but are still widely used. 3. The process of becoming an incidental maintainer often starts when a dependency in a CI system fails, for example, it is not ready for the next PHP version. 4. The vulnerability of open-source projects to security threats like the XZUtils attack. 5. The lifecycle of open-source projects, from enthusiastic start to common abandonment. 6. The personal story of becoming an accidental maintainer for the critical B2B CodeSniffer project. 7. Reasons for project abandonment are often related to life events and health issues. 8. How corporate 'help' without proper funding can lead to maintainer burnout. 9. Strategies for resurrecting an abandoned project, including forks and transferring ownership. 10. The definition of 'maintaining' as keeping things running, not just fixing bugs. ## Highlights - ` "This is how vulnerable open source is, how vulnerable your dependencies are when they're depending on volunteer maintainers."-- Speaker 2 ` - ` "Funding is not optional. Funding is not marketing. Funding is part of your IT project."-- Speaker 2 ` - ` "If you rely on open source, you need to fund open source."-- Speaker 2 ` - ` "criticise the code. Explain why you're not accepting it and give them possibly a path forward on how to get the contribution which would be accepted."-- Speaker 2 ` - ` "It is a kindness to shut things down early, otherwise you leave people with a hope and if you leave people with hope and then shut it down after eight months, that's far more crushing than if you shut it down quickly."-- Speaker 2 ` ## Chapters & Topics ### Being an Incidental Maintainer > An incidental maintainer is someone who takes on the responsibility of maintaining open-source projects that are on the verge of being abandoned or have been practically abandoned, despite being heavily used by millions of people. This is in contrast to projects that a person creates from scratch and deliberately chooses to maintain. * **Keypoints** * These are projects that were on the verge of being abandoned or were in practice abandoned. * They are heavily used, with millions of users. * The need for maintenance arises because someone needs to take responsibility for them. * The trigger for an individual to become a maintainer is often a personal annoyance or a technical failure they experience, such as a CI system failing due to a problematic dependency. * **Explanation** The journey to becoming an incidental maintainer often begins when a developer encounters a problem in their own work. For instance, a continuous integration (CI) system might fail because a dependency is not functioning correctly or is not compatible with an upcoming software version, such as a new PHP version. In an attempt to resolve this, the developer might try to fix the issue, but the initial patch could fail, leading them to become more involved in the project's maintenance. ### Vulnerabilities in Open Source Maintenance > Open source is highly vulnerable, especially when relying on volunteer maintainers. Community pressure can lead to unvetted individuals gaining maintainer status, creating significant security risks. * **Examples** > A state-sponsored, long-term attack on the XZUtils open-source project that occurred over a two to three-year period. If it had succeeded, it would have created a backdoor in every single Linux server in the world. * The attack highlights the risks associated with how maintainers are added to projects, especially under community pressure without full vetting. It demonstrates the vulnerability of dependencies that rely on volunteer maintainers. ### The Lifecycle and Abandonment of Open Source Projects > Projects typically start with enthusiasm, mature with user adoption, may wane in maintenance, and are often abandoned. Most projects go directly from the initial enthusiastic phase to abandonment. Abandonment becomes problematic for projects with a large number of dependents. * **Keypoints** * Phase 1: Enthusiastic start (experimenting, solving a personal problem). * Phase 2: Maturation (adopted by users, becomes well-rounded). * Phase 3: Waning (less frequent maintenance). * Phase 4: Abandonment. * The primary reason for abandonment is 'life happens' (e.g., family commitments, job changes, health issues). * **Examples** > The speaker became an accidental maintainer of B2B CodeSniffer, a project with 300,000 to 500,000 dependent projects, after the original maintainer became unresponsive and abandoned it after six months. The speaker had been a contributor for about eight years. * This illustrates how a critical project can be suddenly abandoned, forcing a contributor to step up to prevent it from failing, highlighting the 'too big to fail' problem. ### Maintainer Burnout and the Role of Corporate Funding > Maintainer burnout is a real issue, often exacerbated by how companies try to 'help'. When a maintainer requests funding to dedicate more time, companies often assign inexperienced people who submit low-quality pull requests. The maintainer gets overwhelmed coaching these contributors, which takes more time than doing the work themselves, leading to burnout and project abandonment. * **Keypoints** * Maintainers request funding to balance open source work with their job. * Companies respond by assigning inexperienced developers instead of providing direct funding. * These developers submit low-quality PRs. * Community pressure forces the maintainer to engage, but coaching is time-intensive. * This cycle leads to maintainer burnout and abandonment. * **Special Circumstances** * If encountering a maintainer asking for help or funding, how should it be addressed?: Companies should balance code contributions with direct financial funding, rather than just assigning inexperienced developers to the project. ### Succession Management for Open Source Projects > To ensure the long-term survival of a project, especially as original maintainers approach retirement age in the next 10-15 years, a deliberate succession plan is necessary. This involves identifying and coaching the next generation of maintainers. * **Keypoints** * Document processes, expectations, and contribution guidelines (including non-code contributions). * Identify potential candidates for succession. * Approach candidates to gauge their interest. * Build trust with candidates before granting permissions to avoid security risks. * Promote trusted individuals to committer or maintainer roles. * Coaching new people requires more time and energy than doing the work yourself, so funding is essential for this process. * **Considerations** * Have a separate GitHub organization for the project, not a personal account, to allow for multiple owners. * Ensure multiple people have access to critical infrastructure like domains, hosting, and funding platforms. * The speaker has arranged for a trusted colleague of 13-14 years to have backup access for the CodeSniffer project. ### Practical Lessons for Maintainers > The speaker shared several practical lessons for maintaining an open-source project, focusing on sustainability, transparency, and community management. * **Keypoints** * Use a dedicated GitHub organisation to enable multiple owners and improve succession. * Expand the 'contributing.md' file to guide new contributors, including non-code contributions. * Use pull requests for all changes to protected branches to increase transparency and create review opportunities. * Expand Continuous Integration (CI) and Quality Assurance (QA) with automated checks to keep the maintainer honest. * Signal where help is needed using labels like 'good first issue' or 'help wanted'. * Close unacceptable pull requests quickly (e.g., within a day), but do so kindly, criticising the code, not the contributor, and offering a path forward. * Say 'no' to feature requests that are not well-defined to avoid future support burdens. * Maintain off-GitHub contact with contributors to keep perspective and avoid tunnel vision. * Stick to your roadmap to ensure long-term goals are met without being derailed by random requests. * Pace yourself and don't be afraid to delay features by saying 'yes, but later'. ### Managing Technical Debt and Code Quality > The speaker discusses the challenge of managing a codebase with a lot of technical debt. While working to reduce it, new contributions can sometimes introduce new debt, for example, by not including tests. This creates a dilemma for the maintainer. * **Keypoints** * It is difficult to expect contributors to have the same coding standards or experience as the maintainer. * Finding a balance for what is 'good enough' is a constant struggle. * Ultimately, the responsibility for the codebase stops with the maintainer. * A familiar codebase, even if old and patched, can feel like an 'old coat' that is comfortable and familiar to the long-term maintainer. ### Open Source Project Maintenance and Progress > The speaker provides an update on the status of the project, highlighting significant progress while also pointing out challenges in sustainability. * **Keypoints** * Since taking over in December 2023, there have been 25 new releases in less than three years, whereas the previous 25 releases took over six years. * Over 850 PRs have been merged. * Over 6,000 new dependents have been added to the repository. * The number of proposers has grown from around 200 to 330. * A major concern is the contribution imbalance: over 60% of the contributions and time spent on the project this year have been by the speaker. * The speaker feels this balance is wrong for a project with around 300 dependencies and an average of 60 individual and company contributors. * **Considerations** * Know your dependency chain and identify all the places you want to fix. * Do not just look at your proposal JSON or package JSON; also consider action runs in your CI and other tools. * Keep track of all your open-source dependencies. * Start investigating the maintenance status of the projects you depend on. * Know where your risks are and start contributing to those projects. ### Handling Pull Requests (PRs) Effectively > A discussion on the best practices for handling pull requests, particularly those that are not likely to be merged. * **Keypoints** * Closing PRs early is a kindness to the contributor. * It avoids leaving people with false hope. * A delayed rejection is more damaging than a quick one. * Always provide an explanation for why the PR is being closed. * Encouraging future contributions is a positive action, even when rejecting a specific PR. * **Explanation** It is considered a kindness to close PRs early. Leaving a contributor with hope for an extended period (e.g., eight months) before closing the PR is far more 'crushing' than a quick rejection. The speaker tries to close PRs within an hour of them being opened. It is crucial to explain the reasoning for the closure. The feedback received suggests this approach, while difficult, is appreciated by contributors. Even generic feedback that encourages future contributions is important. ### How to Contribute to Open Source > Guidance on how to find and start contributing to open-source projects that need help. * **Keypoints** * Use 'thanks.dev' to discover projects seeking funding. * Look for a 'contributing' file or tab on a project's repository page to see if they are looking for help. * Look for issues labelled for new contributors. * Open an issue to discuss your idea before starting work on a PR to get feedback and direction. * A good way to start contributing is to help answer questions in the project's community forums or mailing lists. * **Explanation** To find projects that need financial support, a resource like 'thanks.dev' can be used. To find projects that need code contributions, you should look for a 'contributing' file or tab on the project's main repository page. Projects often have labelled issues for newcomers. A recommended first step is not to just open a PR, but to open an issue first to discuss the proposed change. This allows for a discussion to ensure the contributor is going in the right direction and prevents them from wasting time on work that might be rejected. Another way to start is by helping other users in forums by answering questions. ## Assignments & Suggestions * Look up the XZUtils attack after the talk. * Do not be the company that contributes low-quality PRs instead of funding; balance contributions with funding. * Ambassadors should take the message to their companies that if they rely on open source, they need to fund it. * Have conversations about funding within your companies. * Know your dependencies, know where your risks are, and start contributing to those projects. ## Transcript I love all about building a website that could operate very quickly, very quickly, and the talk itself can turn into a website that can demonstrate all the principles that you talk about. And it's lightning fast, accessible, and true delight. So, for those of you who don't know him, he runs Seth Studio, he also runs a favorite blog of mine, where he inspires others to contribute things that they know. Designing for the moment, things that we've used for decades of experience, like tables, they don't have to be, you just like lean in and give us for free now. You can have a really good experience both like making a table that's pleasing to use, as well as giving experience. Today, he's going to talk to us, we can get the core writing, working on a web that's above working, generating things that are non-performant, and difficult to work around, and he's going to stay with us very shortly. So, please give Eddie a round of applause. I haven't made this slide out here, I haven't done WordPress since before the Google thing, because I called it Google, I didn't know how to do WordPress. Alright, let's begin. This is our game, so we can't play out of our CSS, so here's what CSS talks about. Well, let's just pretend, right? Let's say we want to get better at adding your value. Do you read the story of coding challenges popping? All of us think it's a very good thing to do. A little bit of a curveball. I have to admit, though, really, in general, it's down to more than coding. It comes down to how you approach everything else, like communication, giving and receiving feedback, and finding... So I've been doing this for a while now, but the thing is, it's getting more and more... But what happens in that time is core skills. People think of us as very quiet. And I've spent a large chunk of the world with corporations, and in sports all the way, and in all of us, and improved those core skills to be overarching. So back in the battle there, we had this designer designing pictures of websites, and then handing them off to developers, who were trying to do a website, a real website, with valuable pictures. the same pixel by taking that picture, but even during this period where we could probably make a reasonable assumption on the user that the pixel that we designed will not be able to hang out with the printer, that's why printing is finalised, and all of us all can do that. unless we need to print. The printer will arrive and it will actually light up the screen and the public will see the pattern. For Australia, the design tools have progressed a lot, but I'm tired of having my machine stuck and not being able to get it to work. tools like fitment and the encourage hand css the language is also with the two but what's not. great is that you're really starting to build your hand opportunities. so skill set values new syntax abilities as a language and i know it's having a lot of my experience but i see almost no material out there and you're starting to see a lot of demos. unfortunately thanks to the algorithm. We get a lot of content from the Actions League in our group. You know, the type of YouTube thumbnail I listen to all the time, saying, Will you produce a third one? And again, if I don't produce a third one, I do worry about what it's having on the industry as a whole. So what we're like, we're all built about it, and it's not all our work and all of it. Tools and gears and all of it. I'll tell you what, there's a certain problem that design can have. So that's what's happening now, and the last people wanted to come back to school, but it's still a big problem, and not the impact of the problem. And I think it's going to be harder and harder to be clear. It's not all doing the right thing, and I haven't done it in a few times, but it's not doing the right thing, but it's really helping to say, I don't think I'm going to use that word. Design cannot be focused on tools. I'm going to go away. You might as well learn to install them. And if I also go away, what I'm trying to say is, hopefully, at the end of this session, you will have a delightful show. Yeah, even if it wasn't 90% or 100%. All right, so I've got a shot. What I'm going to do is I'm going to be there with you. And one of the things that I think... It's a critical skill, in fact it's critically needed when we're in a region. So I would like to say that we're a team of all-vacants. Our primary mode of treatment is blood. And as you know, we're all in the same time. We're all all-vacants. We all work hard. We also work to fight. So for example, clients in India, you can always do that. And when you're at the same time, it's there for the best, and then you're free once you get off the call. So it's best to be tired at times, but if you can't do it right, So let me give you the principles now. The first thing is you can go and watch a lot of movies and stuff. There's no need to fill a content. Try not to reach in-person Korean models. People have that as a point. When you're asking, don't ask. If you ask them multiple questions or ask them multiple things, it's likely you won't actually get the answers they were looking for. If you need to know multiple things, let your colleagues know that they know all of the answers. This is a really important thing. Thank you very much for your time, and I'll see you in the next one. I don't know what you want to do, or you might need principles for all you know. First of all, I think I've got what's wrong here. I think I've got what's wrong here. You're not wrong. I need you to pick the colors of the design that we need. It's quite, and design is our world. Once it's not there, even if you're in it, you should never forget about it. You're not allowed to. So, tell me, for this time, it's quite, and then you can call it on. You can let me know that it's not part of my job. It's quite, and it's fun. If you're really happy about it, I'm here to explain to you. I'm sorry, but I'm going to go on. And then that goes back to how I got my idea. Thank you very much. Alright, I'm a boomer, but I know it's a real problem with people coding. I said this is a good age. So, hi designer, I hope this email finds you good. I hope you had a fantastic week. The family and I went for the project. It's like, you can review the emails that you love and develop. And then develop them. We all have them. Doing this team. Nice pop-up. I can't talk more about the weekend without the actual issue, I told the designer to go. find it for themselves. A number of people's inboxes are generally rammed full of emails. Be a good colleague and make your response is better. Yeah, it just means people require it. The colour contrast issues are the latest brand design. We are on smaller tests. The colours don't conform to a single layer, which is a requirement for this book. We've really helped you to colour urgently, and we need to support you. Now, I know it's going to be a lot of research. The first exact understanding is the silver medium. Another point. you're more likely to design it but if i saw that initially and i've seen the video it's a good way. so let's have a look at feedback is quite often a warship to the designers it doesn't mean that too because getting feedback right will include this simpler. What we want to be able to occur in a way, you come back to a review, it's communication, review, quality of feedback, getting into that almost, dealing with that and giving feedback is super important. Now, I don't think this is that important, but I've still got it. So the later principles of presuming knowledge when providing feedback to a designer or another stakeholder like a project, this is a stunning example. There's a hero at the top, and it's God. And in the real world. So I've come to the designer and I've said, we shouldn't use a slide on that page because. it's such a tired old show. So it's a client, yeah, the designer's going to come back and say, well, it's what the client wants, it's what the sign-up says, and you've got to take the best ones. And it's got to know how to, all of your changes can sign up. Because what you're getting there is you're basically accusing them of the cost of it. So any chance of making that positive, this is how I've heard the designers looking at it, there's one section that I'm quite concerned about and would like to understand the decision. on, with the homepage hero slider, I've got concerns about potential accessibility problems. I get that it really feels like considering their departments are so important, they've. not produced content for them. So, exactly what I said, they've produced a background 3.2, which is an ideal, to which I have a problem that they might not choose the right colors of color contrast for each, slide, especially if it's a semi-right, you know that that could change really quickly. Maybe we should get some data to support the service. It would be worth looking at what the average... We couldn't argue, the user is likely never going to shout, the problem is they're still promoting. So what a designer doesn't need is a common mission. Developers are in a really strong position to provide that and they've generally got. raw understanding of it. Remember, not competition. So let's imagine, so let's imagine for a moment that a new designer... The designer came up with an icon, followed by four columns, one column for each department, each column on a tiny officer on a small screen. So, even though this is a picture I can imagine you, the problem is, in fact, all the ideas on the slide are the same. The client doesn't know what he does, useless. What's the designer expecting to do with that? In these situations, it's a solution. So I got server feedback, but this time I got my server back. Yeah, I struggled to get this working though because I have to rearrange the content inside JavaScript. The problem with that is that JavaScript will fail, and or not fail, is why. If JavaScript does work, and if the web and DOM is as good as it's done, well, that can be quite clunky. So the designer can say that the reason they want it to run, is because they want to write about it on the web. The randomness of each department is important to each other, and the normal one department can be prioritised. It's really for what you want. What do you feel you want? How high are you? How low? So it starts with sharing to me the consequences when a CMS site is built. This means it's built at once, and no pages are set. But what if they change your view of the content in the CMS quite regularly, and trigger a rebuild at the site? You'll come back with this good idea, but in fact they're really quite lazy, as well as demanding. You've all been there. So how do I actually set a site to rebuild every hour? Just rebuild, randomise the idea, have work-like work required, and what they want next. To see how much more productive, not only have we avoided implementing a slider in the first place, but we've also developed a nasty JavaScript that will almost serve. This is the trick of being a user-to-member. I know every project has challenges. You don't want to know how the point of making it collaborate will likely get your designers, want the best of your users to achieve that, right? So, imagine you run out of 100, but I think this is more than enough. Time management people think it's in my statuses and thoughts, but all this stuff is just abstract. Really, it's tempting when you're deep in the woods, and yeah, that happens a lot. All of this, the compromises, you see them all through the land. Then there's chasing the pack, not getting lucky. My mind immediately just generated it. I'm thinking down the line of a very large corporation, chasing air, the desperation not to be left behind. but it's also not just humorous, but also dangerous work, such as this Google search recommending things, but we're not going to ship up these large numbers on Google and Commonwealth. So let me just tell you a story, all of it. So go back to 2019, when I was a freelance in the design system of cruise travel. Aside from the free deals, the middle of cruise travel itself by themselves is a resoundingly horrifying project. instead of the usual steps of research discovery analysis and thorough because of a very tight. deadline we just got on and the list that's so looking is extremely we have nine and they're very limited so the option that would be more sort of inconsistent very exposed with one of those inconsistencies multiple layouts not to mention the various conflicts and technology obviously. people not agreeing with i couldn't i didn't i went full speed so in my mind we're getting done. But the damage was insane. We had not one, not two, we had three great systems. We had a concept so fragile that it was something that was inconsistent. Why am I telling you this? I want you to learn from my mistake. Because the reason I say it is not bad working in this industry. And the vast majority of it is entirely wrong. Taking one step, slowing the process, clear your mind. Because as the old saying goes, slowest we miss it is less. That's by design. With a slot like this, you can just focus on it. CSS is really important and scalable from there. But what's more important is the core skills. It's why this is called the core of how you can follow. Without all that, everything will come in well. You can introduce that question a lot. But you know, because there's not such a standard in the world, and you might be worried about that. You can introduce that. The main thing is keep battling, invest more time, it will be smaller. Don't get hung up on the tools. Shoulders are going to get too far still. It's all about deciding on the direction you want to go. Get the polymer right, don't misanalyze. Thorough approach is the only thing. all right so i hope you found it's actually all content. this is actually one of the modeling costs that we do all this. real quick the client is super upset