Author name: ITMAITY

Maintaining an open source project can be a big responsibility. But it’s not one you’re obligated to bear forever. Maybe usage has declined thanks to a better solution. Maybe technology has evolved to the point that it’s easier to start over with a new project than adapt an old project to a new ecosystem. Sometimes it’s time to move on, even if that means deprecating a project. Brett Terpstra, a front-end developer, maintains more than 100 GitHub repositories and has had to retire more than a few. “Projects that rely on APIs and other outside applications often require more work than is worthwhile once things start to break,” he explained in a Q&A. “Historically, those are the projects that get retired the fastest.” Whatever your reasons, you want to sunset the project gracefully to protect your reputation and do right by your users. Here are some insights from maintainers who have navigated the process about what you should and shouldn’t do when it’s time to deprecate a project. Don’t: Keep maintaining something for too long The one thing Olga Botvinnik, a computational biologist, would tell her younger self is that she should have sunsetted her Python data visualization package prettyplotlib sooner. She didn’t want to abandon the project, but she had started it as part of her PhD work, felt like updating it to support Python 3 would be daunting, and was interested in moving on to other projects. Besides, another Python visualization library called Seaborn was becoming increasingly popular.  “Even if I’m immediately done working on a project, I leave the 30-day window open to take care of issues and help users transition.” – Brett Terpestra, front-end developer Botvinnik thought Seaborn was better in some ways, and more polished. So she made the decision to deprecate prettyplotlib and spend her time contributing to Seaborn instead. “One of my mentors told me that knowing when to end a project is just as good as finishing it,” she says. “That made me feel a lot better about letting it go.” Do: Leave the door open for someone else That said, you shouldn’t deprecate a project without considering other options, like handing it to another maintainer. Terpstra has deprecated many projects, but he always looks for someone else to take them over first. “There are different degrees of sunsetting,” he says. In some cases, a project is so simple that it doesn’t need much maintenance. In that case, you can just make a note that you don’t often update the project while leaving the door open for new contributions. Of course it’s not always appropriate to hand off a project to another maintainer. Ben Johnson, maintainer of the SQLite recovery tool Litestream, opted to retire BoltDB and point people towards a fork called BBolt rather than have someone take over the original. “My name and reputation were pretty closely tied to the project at the time,” says Johnson. “I was the BoltDB guy. I didn’t want to put my reputation in the hands of someone else.” Don’t: Pull the plug without notice Terpstra gives at least a month’s notice before retiring a project. “Even if I’m immediately done working on a project, I leave the 30-day window open to take care of issues and help users transition,” he says. “One of my mentors told me that knowing when to end a project is just as good as finishing it. That made me feel a lot better about letting it go.” – Olga Botvinnik, computational biologist Once you’ve made the decision to deprecate a project, you need to let users know and, if possible, suggest alternatives. “I spread word through a blog post and a tweet announcing that I wasn’t going to actively fix bugs anymore and pointed people to Seaborn instead,” Botvinnik says. Do: Keep the code online Instead of deleting your project, it’s almost always best to archive it instead. Archiving a project makes it read-only and communicates to users that it’s no longer maintained. Everything from issues and pull requests to milestones and permissions become read-only. But you can always unarchive a project if you later decide to work on it again. Deleting your project could have unintended consequences. “Anyone thinking about taking their software offline should consider whether they might be creating reproducibility problems for people in science and academia,” Botvinnik points out. Keeping it online means that even if you couldn’t find someone to take it over before you deprecated the project, someone else could come along later and fork it—or at least find something useful to reuse. That said, if you believe your code is actively harmful, it might be best to take it offline. For example, software with dangerous security vulnerabilities that put users at risk. Take this with you Ultimately, open source projects are living entities—born from passion and sustained by community. Knowing when and how to let go is not just good stewardship, it’s an essential part of the open source lifecycle. Get started contributing to open source now. The post Dos and don’ts when sunsetting open source projects appeared first on The GitHub Blog. ​ Maintainers, Open Source, community, open source The GitHub Blog

When it comes to design systems, every organization tends to be at a different place in their accessibility journey. Some have put a great deal of work into making their design system accessible while others have a long way to go before getting there. To help on this journey, many organizations rely on accessibility annotations to make sure there are no access barriers when a design is ready to be built.  However, it’s a common misconception (especially for organizations with mature design systems) that accessible components will result in accessible designs. While design systems are fantastic for scaling standards and consistency, they can’t prevent every issue with our designs or how we build them. Access barriers can still slip through the cracks and make it into production. This is the root of the problem our Accessibility Design team set out to solve.  In this two-part series, we’ll show you exactly how accessible design system components can produce inaccessible designs. Then we’ll demonstrate our solution: integrating annotations with our Primer components. This allows us to spend less time annotating, increases design system adoption, and reaches teams who may not have accessibility support. And in our next post, we’ll walk you through how you can do the same for your own components. Let’s dig in. What are annotations and their benefits?  Annotations are notes included in design projects that help make the unseen explicit by conveying design intent that isn’t shown visually. They improve the usability of digital experiences by providing a holistic picture for developers of how an experience should function. Integrating annotations into our design process helps our teams work better together by closing communication gaps and preventing quality issues, accessibility audit issues, and expensive re-work.  Some of the questions annotations help us answer include: How is assistive technology meant to navigate a page from one element to another? What’s the alternative text for informative images and buttons without labels? How does content shift depending on viewport size, screen orientation, or zoom level? Which virtual keyboard should be used for a form input on mobile? How should focus be managed for complex interactions? Our answers to questions like this—or the lack thereof—can make or break the experience of the web for a lot of people, especially users with disabilities. Some annotation tools are built specifically to help with this by guiding designers to include key details about web standards, platform functionality, and accessibility (a11y).  Most public annotation kits are well suited for teams who are creating new design system components, teams who aren’t already using a design system, or teams who don’t have specialized accessibility knowledge. They usually help annotate things like: Controls such as buttons and links Structural elements such as headings and landmarks Decorative images and informative descriptions  Forms and other elements that require labels and semantic roles  Focus order for assistive technology and keyboard navigation GitHub’s annotation’s toolkit One of our top priorities is to meet our colleagues where they’re at. We wanted all our designers to be able to use annotations out of the box because we believe they shouldn’t need to be a certified accessibility specialist in order to get things built in an accessible way.  To this end, last year we began creating an internal Figma library—the GitHub Annotation Toolkit (which we aim to release to the public soon). Our toolkit builds on the legacy of the former Inclusive Design team at CVS Health. Their two open source annotation kits help make documentation that’s easy to create and consume, and are among the most widely used annotation libraries in the Figma Community.  While they add clarity, annotations can also add overhead. If teams are only relying on specialists to interpret designs and technical specifications for developers, the hand-off process can take longer than it needs to. To create our annotation toolkit, we rebuilt its predecessor from the ground up to avoid that overhead, making extensive improvements and adding inline documentation to make it more intuitive and helpful for all of our designers—not just accessibility specialists.  Design systems can also help reduce that overhead. When you audit your design systems for accessibility, there’s less need for specialist attention on every product feature, since you’re using annotations to add technical semantics and specialist knowledge into every component. This means that designers and developers only need to adhere to the usage guidelines consistently, right? The problems with annotations and design system components Unfortunately, it’s not that simple.  Accessibility is not binary While design systems can help drive more accessible design at scale, they are constantly evolving and the work on them is never done. The accessibility of any component isn’t binary. Some may have a few severe issues that create access barriers, such as being inoperable with a keyboard or missing alt text. Others may have a few trivial issues, such as generic control labels.  Most of the time, it will be a misnomer to claim that your design system is “fully accessible.” There’s always more work to do—it’s just a question of how much. The Web Content Accessibility Guidelines (WCAG) are a great starting point, but their “Success Criteria” isn’t tailored for the unique context that is your website or product or audience.  While the WCAG should be used as a foundation to build from, it’s important to understand that it can’t capture every nuance of disabled users’ needs because your users’ needs are not every user’s needs. It would be very easy to believe that your design system is “fully accessible” if you never look past WCAG to talk to your users. If Primer has accessible components, it’s because we feel that direct participation and input from daily assistive technology users is the most important aspect of our work. Testing plans with real users—with and without disabilities—is where you really find what matters most.  Accessible components do not guarantee accessible designs Arranging a series of accessible components on a page does not automatically create an accurate and informative heading hierarchy. There’s a good chance

In part one of our design system annotation series, we discussed the ways in which accessibility can get left out of design system components from one instance to another. Our solution? Using a set of “Preset annotations” for each component with Primer. This allows designers to include specific pre-set details that aren’t already built into the component and visually communicated in the design itself.  That being said, Preset annotations are unique to each design system — and while ours may be a helpful reference for how to build them — they’re not something other organizations can utilize if you’re not also using the Primer design system.  Luckily, you can build your own. Here’s how.  How to make Preset annotations for your design system Start by assessing components to understand which ones would need Preset annotations—not all of them will. Prioritize components that would benefit most from having a Preset annotation, and build that key information into each one. Next, determine what properties should be included. Only include key information that isn’t conveyed visually, isn’t in the component properties, and isn’t already baked into a coded component.  Prioritizing components When a design system has 60+ components, knowing where to start can be a challenge. Which components need these annotations the most? Which ones would have the highest impact for both design teams and our users?  When we set out to create a new set of Preset annotations based on our proof of concept, we decided to use ten Primer components that would benefit the most. To help pick them, we used an internal tool called Primer Query that tracks all component implementations across the GitHub codebase as well as any audit issues connected to them. Here is a video breakdown of how it works, if you’re curious.  We then prioritized new Preset annotations based on the following criteria: Components that align to organization priorities (i.e. high value products and/or those that receive a lot of traffic). Components that appear frequently in accessibility audit issues. Components with React implementations (as our preferred development framework). Most frequently implemented components.  Mapping out the properties For each component, we cross-referenced multiple sources to figure out what component properties and attributes would need to be added in each Preset annotation. The things we were looking for may only exist in one or two of those places, and thus are less likely to be accounted for all the way through the design and development lifecycle. The sources include: Component documentation on Primer.style Design system docs should contain usage guidance for designers and developers, and accessibility requirements should be a part of this guidance as well. Some of the guidance and requirements get built into the component’s Figma asset, while some only end up in the coded component.  Look for any accessibility requirements that are not built into either Figma or code. If it’s built in, putting the same info in the Preset annotation may be redundant or irrelevant. Presets can account for rare use cases While building a Preset annotation for the TextInput component, we found that implementations may use an icon alone or have a hidden input label. With GitHub’s global search or filter inputs, the magnifying glass icon alone can act as the visible label, but the fields still need an accessible label for assistive technology users. Coded demos in Storybook  Our component sandbox helped us see how each component is built in React or Rails, as well as what the HTML output is. We looked for any code structure or accessibility attributes that are not included in the component documentation or the Figma asset itself—especially when they may vary from one implementation to another.  Code attributes a designer may not see or set Storybook helped us craft our TextInput component’s Preset annotation by showing some important attributes that don’t get any mention elsewhere. The type attribute is to the value of text. by default. Depending on the purpose of the field, an input’s type could also be search, email, number, tel, date, or time. This should be set intentionally so that users are able to use the most appropriate virtual keyboard. Component properties in the Figma asset library Library assets provide a lot of flexibility through text layers, image fills, variants, and elaborate sets of component properties. We paid close attention to these options to understand what designers can and can’t change. Worthwhile additions to a Preset Annotation are accessibility attributes, requirements, and usage guidance in other sources that aren’t built into the Figma component.  What’s missing from the TextInput’s Figma component When a TextInput is added to a design, the Figma component comes with many customizable options. There is an inputTextType property, which is about visual design and typography, not the type of form input. It’s possible to set the value of the Label and input field in Figma’s sidebar, but because it’s hidden by default, there’s no option to set the text of an error validation message. We can’t assume that every design delivered in Figma will come with examples of a form showing all of its error states, so these error messages may not get the attention they require. If this message can’t be built into the component as a text property, it can be added to the Preset annotation. Other potential sources  Experiences from team members: The designers, developers, and accessibility specialists you work with may have insight into things that the docs and design tools may have missed. If your team and design system have been around for a while, their insights may be more valuable than those you’ll find in the docs, component demos, or asset libraries. Take some time to ask which components have had challenging bugs and which get intentionally broken when implemented. Findings from recent audits: Design system components themselves may have unresolved audit issues and remediation recommendations. If that’s the case, those issues are likely present in Storybook demos and may be unaccounted for in the component documentation. Design system audit issues may

Open source software (OSS) is everywhere—it’s the lifeblood of the modern software ecosystem. Ninety percent of companies use open source1, 97% of codebases contain open source2, 70-90% of the code within commercial tools comes from open source3, and the value of OSS globally is estimated to be $8.8 trillion4. At GitHub, we love open source—and we’re so honored to host so much open source code that we famously preserved it in the Arctic. But in the same way that your office microwave doesn’t just magically get clean and your favorite park doesn’t have self-mowing grass, open source software doesn’t just happen.   We’re surrounded by human-maintained infrastructure and resources that, in our busy lives, can be easy to take for granted. This is why we started Maintainer Month—a time to thank the open source software maintainers that keep projects healthy. This May marks the fifth annual Maintainer Month, and there are lots of treats in store: new badges, special discounts, events with experts, and more. In addition to the fact that the device you’re reading this on functions–thanks, open source maintainers! Maintainer Month events and livestreams There are over 25 events and livestreams scheduled during Maintainer Month, so head on over to the schedule to see them all or add your own! Everyone is welcome at these events—whether or not you’re ready to call yourself a software maintainer. Here are a couple of our favorites, since they tackle thorny issues:  What maintainers need to know about open source licensing, SBOMs and security: May 6, 2025Join our colleague Jeff Luszcz from the GitHub Open Source Programs Office as he reviews what every maintainer should know about these topics in the ever-evolving landscape of 2025. We get so many questions about this, and Jeff is the expert! The CRA and Open Source: What Maintainers Really Need to Know: May 27, 2025Feeling stressed about the European Union’s new Cyber Resilience Act (CRA) regulations? We can help! Come to this stream with the Eclipse Foundation’s Cyber Resilience Working Group, where they’ll talk about resources and practical information for maintainers navigating these changes. 🎁 Meet the 2025 Partner Pack This year, we’re launching the new Maintainer Month Partner Pack—a bundle of perks, tools, and resources from organizations that truly believe in open source. Think of it as a care package for the folks behind our digital infrastructure. Here’s just a taste of what’s inside (and it’s available to all maintainers): Arachne Digital: Free tailored threat report with steps to defend your project Boot.dev: One month of free premium access to backend dev courses CNCF: Discounts on select cloud native training (Kubernetes included!) DevCycle: A full year of the Developer plan, free for maintainers JSConf North America: Special discounted tickets for Maintainer Month Linux Foundation Education: 25% off the full course catalog Mockoon: Free Mockoon Cloud account to build, test, and mock APIs faster Sentry: Access to their open source plan for monitoring and performance TODO Group: 20% off the CODE certification for enterprise open source Web Summit: Discounted tickets to Vancouver & Lisbon for OSS contributors …and we’ll be adding more throughout May.  👉 See all current offers and partners here. Some partners are offering extra perks for members of our private Maintainer Community—a vetted space to connect, share, and support each other. If you maintain an open source project, you can request to join our Maintainer Community. Security: a new challenge Security is kind of a big deal, which is why you hear about it all the time. This is why we’re excited to launch new security guidance on opensource.guide to help maintainers strengthen the trust and resilience of their open source projects. We’ve pulled together practical advice and tools you can start using right away to make your project safer for everyone who relies on it. Because building great open source software isn’t just about what your project does—it’s about how you protect the people who use it. The new Open Source Guide on Security Best Practices for Your Project will walk you through the basic considerations for software security, including how to: Secure your code as part of your development workflow Avoid unwanted changes with protected branches Set up an intake mechanism for vulnerability reporting Looking to improve security on your project with expertise and community? Apply to the GitHub Secure Open Source Fund.  You don’t have to secure your project alone—we’re here to support you. The GitHub Secure Open Source Fund provides a combination of funding, training sessions with experts, and access to researchers and community to get your project more secure. We’re completely serious, we will give you money ($10K) to improve your security practices!  Apply to the GitHub Secure Open Source Fund > 🔒 Security Challenge: Level up during Maintainer Month Ready to boost your project’s defenses—and your own skills? This May, take the Maintainer Month Security Challenge, which features three hands-on GitHub security skills while allowing you to snag a voucher for GitHub Advanced Security certification (hello, career boost!). In just a few hours, you’ll pick up real techniques to protect your project—and show the world you’re serious about security. Let’s build a safer open source together. Join the Security Challenge > 🔧 How to get involved throughout May and beyond Explore the Partner Pack: maintainermonth.github.com Join the Maintainer Community: maintainers.github.com Want to contribute an offer? Email us at maintainermonth@github.com Share your story: Tag #MaintainerMonth on social media to help us celebrate the humans behind the code! Read more about what’s happening with open source. 1 GitHub. 2022. “Octoverse 2022: The state of open source software.” https://octoverse.github.com/2022/. & OpenUK. 2021. “State of Open: The UK in 2021.” https://openuk.uk/wp-content/uploads/2021/10/openuk-state-of-open_final-version.pdf.  2 Blackduck. 2025. “Six takeaways from the 2025 “Open Source Security and Risk Analysis” report.” https://www.blackduck.com/blog/open-source-trends-ossra-report.html. 3 The Linux Foundation. 2022. “A Summary of Census II: Open Source Software Application Libraries the World Depends On.” https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on. & Intel. 2025. “The Careful Consumption of Open Source Software.”  https://www.intel.com/content/www/us/en/developer/articles/guide/the-careful-consumption-of-open-source-software.htm.  4 Harvard Business School. 2024. “The Value of Open Source Software.” https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148.  The

If you have opened Copilot Chat in VS Code lately and didn’t notice the tiny dropdown hiding at the bottom, you’re not alone. It’s easy to miss, especially when you’re heads down trying to get something shipped. That little menu is where you can switch between ask, edit, and agent modes—three ways you can integrate Copilot into your workflow. But here’s the thing: Each of these modes does something pretty different. And depending on what kind of developer you are, how much context you have, or how much control you’re comfortable giving GitHub Copilot, you might have a very different experience with each one.  I’ve been using all three in different ways, from building apps and testing ideas to playing with frameworks I haven’t touched in a while. I’ve also spent time talking to other developers about what’s working for them.  Below is what I’ve learned so far. This isn’t the manual (for that, look at the VS Code documentation). It’s more of a guide for how to think about these tools, as you navigate where they fit into your own workflow. Ask mode: The quick gut check Ask mode is the simplest of the three—and if you are a long-time user of GitHub Copilot, it might be the only time you’ve thought about bringing up the Chat window.  Here’s how it works: You highlight some code, type a question into Copilot Chat, and it generates an answer. It might explain what the code does, suggest how to test it, give you a code snippet that implements what you are asking about, or remind you how to handle a particular edge case.  Ask mode is fast, helpful, and focused entirely on answering your programming question without touching your code. You can stay in your editor and ask questions that Copilot can answer using all the context of your current editor environment. Think of it like a quiet little whisper in your editor saying, “Hey, here’s what I think this means.” And it’s not just about your code. You can ask it anything related to programming—like how to use a certain library, how to structure a SQL query, and even which search algorithm is more efficient for a given dataset.  Need help styling something with Tailwind? Want a refresher on closures in JavaScript? Curious how to debounce an input in React? Copilot can help with that, too. There’s no project commitment, no architectural decisions, and no code changes. Just answers, right when you need them. It’s the lowest-friction way to get unstuck when a question is standing in the way of you and building what’s next. Edit mode: You’re still in charge, just moving faster Edit mode in VS Code is where things start to get more interesting. It lets you pick any number of files in your project you want to change and describe the update in natural language. Then, Copilot will immediately apply inline, review-ready code edits across those files.  Edit mode is perfect when you know what you want to do but don’t necessarily want to write it all out yourself. You highlight a block of code, type in an instruction—perhaps something like “add error handling” or “refactor this using async/await”—and Copilot rewrites the code for you. But (and this is important) it doesn’t save anything without showing you the diff first. That’s what makes edit mode so reliable. Copilot does the work, but you get the final say. You’re not handing over the reins. You’re speeding things up while staying fully in the loop. You can also bring custom instructions into edit mode if you want to level it up a bit. It’s a way to teach Copilot how you and your team like to write code, including your style preferences, how verbose or concise you want it to be, what your team’s standards are, how formal or casual you want it when it explains things, and even what language you want your comments written in. Setting up those preferences is like giving Copilot a playbook ahead of time—so when you say “clean this up,” it already knows what “clean” actually means to you. I’ve found myself reaching for edit mode when I’m deep in a brownfield app and don’t want to touch the rest of the system, or when I’m just trying to get through a handful of small but annoying improvements with surgical precision. It’s not trying to redesign your architecture. It’s not going to rename things you didn’t ask it to. It’s just here to make the thing you’re working on better and faster, with less mental overhead. Honestly, once you get used to it, it’s hard to go back. Agent mode: A lot of power, when you’re ready for it Now let’s talk about Agent mode. Agent mode lets you hand it a high-level prompt and then watch as Copilot autonomously plans the steps, selects the right files, runs tools or terminal commands, and iterates on code edits until the task is complete. It is by far the most powerful mode in Copilot Chat—and also the newest, which means for a lot of people, it’s still the least familiar. Agent mode can reason across your entire project, take multi-step actions, and hold onto a significant amount of context across a session. You can ask it to build features, fix bugs, create files, clean up routing logic, or even scaffold an entire section of an app based on a single prompt. At first glance, agent mode can look like an expanded version of edit mode—and in some respects, it is. But there’s a crucial distinction: Instead of only rewriting the lines you specify, agent mode analyzes related code, identifies additional changes that may be required, and applies them across the project to keep everything consistent. Another key distinction? Agent mode applies edits automatically rather than waiting for explicit approval, while still surfacing any potentially risky commands for review before they run. The workflow is closer to a continuous-edit “driver” model: The developer defines