![\"Hacktoberfest](\"https://openresource.dev/images/hacktoberfest-1.png\")
(full size)The Cyber Resilience Act (CRA) is the EU law that makes companies responsible for the security of the software they sell, including the open-source parts. If you maintain a project for free, it almost certainly does not apply to you. If a company ships your project in a product, it applies to them, and they will start asking you questions. Here’s what the law says, in the order you’ll be asked.
\nTwo texts answer almost everything: the regulation itself, Regulation (EU) 2024/2847, and the Commission’s guidance of July 27, 2026, whose third chapter is about open source, with 22 worked examples. The guidance is an 84-page PDF; the links below point to the copy kept by the Eclipse Foundation’s ORC working group, which has an anchor on every paragraph and example. The guide’s chapter on security for maintainers has the three-bullet version.
\n\n\n[!WARNING]\nThis article explains the text; it doesn’t replace someone who can read your situation. If you sell anything around your project—a paid edition, binaries, support bundled with access—ask a lawyer before December 2027. If your project belongs to a foundation, ask the foundation: it’s the steward, and the CRA is its question first. For everything else, the OpenSSF brief guide and the ORC working group’s CRA FAQ answer the common cases and link the official texts.
\n
The CRA covers products “made available on the market”, which means supplied “in the course of a commercial activity” (recital 15). For open source, the guidance turns that into three questions.
\nThe guidance’s examples, sorted by the role they end in:
\nNo obligations
Steward (Article 24)
Manufacturer (Article 13)
If you maintain a project as part of your job and your employer publishes it without selling it, your employer is probably its steward (Examples 25 and 29). The obligations are the company’s, not yours personally: the cybersecurity policy is a question for your manager.
\nWhat makes you a manufacturer is putting the software, or its fixes, behind a payment. How the work was funded doesn’t count (recital 18).
\n| Not monetized: no obligations | \nMonetized: manufacturer | \n
|---|---|
| Donations, even above your costs, reasonable living expenses included (para 61) | \nReleases or security updates only for donors (Examples 21 and 22) | \n
| A company paying you to build a feature that everyone gets (Example 23) | \nA price for the software or its binaries (para 51) | \n
| Consulting, training or support sold next to free downloads (Example 18) | \nA paid edition with support bundled in (Example 17) | \n
| Sponsorships, grants, bug bounties (para 63) | \nUse conditioned on personal data for ads or analytics (Example 16) | \n
| Regular releases (recital 18) | \nA free app through which you sell other services (Examples 14 and 15) | \n
Open core splits in two: the paid version is placed on the market, the free community version is not (para 52). A company that publishes both is the manufacturer of one and the steward of the other (para 53).
\nThe reporting deadlines are short: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours, and a final report within 14 days of a fix being available (Article 14). Stewards report only from December 11, 2027 (the Commission’s reporting page), and so does the rule that matters most to you as a maintainer, the duty to report upstream, which is part of Article 13.
\nA steward’s obligations fit in Article 24: a documented cybersecurity policy that fosters secure development and vulnerability handling, cooperation with market surveillance authorities when they ask, and reporting only as far as the steward is involved. A foundation that only handles branding and donations isn’t required to report anything; one that runs the forge or the signing keys reports incidents on that infrastructure; one that employs the developers reports actively exploited vulnerabilities too (paras 79 to 82).
\nStewards can’t put a CE marking on the software (recital 19), and they can’t be fined under the CRA (Article 64(10)). Being a steward is per project: a foundation can be the steward of some of the projects it hosts and nothing for others (para 78). If your project is joining one, the guide’s chapter on governance covers when a foundation makes sense; ask the foundation how it handles the CRA before you join.
\nA manufacturer meets the security requirements of Annex I, and from December 11, 2027 that includes:
\nFines for manufacturers go up to €15 million or 2.5% of worldwide annual turnover (Article 64(2)). That number explains the tone of some of the emails you’ll get.
\nThe guide’s chapter on vulnerabilities in what you ship covers the same obligations from the manufacturer’s desk, before the emails are sent.
\nNone of this obliges you to do anything. A maintainer whose project isn’t placed on the market bears no obligations toward the companies that integrate it (para 87). What changes is your inbox.
\nVulnerability reports. The guidance asks manufacturers to report through your security policy or reporting channel when you have one, to skip reports when they can confirm you already know, and to check public databases and your advisories first (para 223). A SECURITY.md with a private channel decides where those reports land and how they’re written. The security chapter has a template and the four settings that go with it.
Patches. A shared fix should come under a license compatible with yours, and follow your guidelines for sharing fixes if you have some (para 227). The manufacturer doesn’t have to get it merged (para 228), and you don’t have to merge it.
\nQuestionnaires and “please sign this”. The OpenSSF CRA guidelines for maintainers list what to expect: security questionnaires, supplier onboarding, compliance declarations. Their advice, as of October 2026, is not to sign anything that takes on CRA compliance, certifies a downstream product or guarantees the absence of vulnerabilities. That’s the OpenSSF reading, not the law’s text, but it matches the regulation: the obligations stay with whoever places the product on the market.
\nDue diligence questions you can answer in advance. Two of the checks the regulation suggests are public: whether you ship security updates, and whether your releases have known vulnerabilities. A supported-versions table in SECURITY.md, published advisories and a changelog answer both without a questionnaire.
When a request goes beyond that, the answer can be “no”, or “yes, under a support contract”. Saying No has the replies. A support contract next to free downloads doesn’t make you a manufacturer (Example 18).
\nAs of October 2026:
\nThe regulation also lets the Commission set up voluntary security attestation programs for open source, which anyone could fund, including the companies that depend on a project (Article 25). If one appears, it would answer due diligence once instead of questionnaire by questionnaire.
\nSECURITY.md, the private reports and the advisories that answer most of the questions above.Every October since 2014, Hacktoberfest has asked developers to send pull requests to open source projects and get a T-shirt for it. It made hundreds of thousands of first contributions happen, and some years it also left maintainers with waves of low-effort pull requests to sort through. On August 19, 2026, its new organizers dropped the rule that defined it: pull requests no longer count. This is what Hacktoberfest is in 2026, how to take part whether it’s your first Hacktoberfest or your tenth, and what twelve years of it taught open source.
\nHacktoberfest is a free, month-long event that runs every October. DigitalOcean launched it in 2014 with a simple deal: open four pull requests on GitHub during the month, get a T-shirt. 676 people registered that first year and 505 completed it. By 2018, 106,582 had registered; by 2020, 169,886. Over twelve editions, DigitalOcean counts more than 2.4 million accepted pull and merge requests sent to open source projects.
\n\nIn 2026, Major League Hacking (MLH) and DEV run the event, with DigitalOcean as presenting partner. The theme is “AI belongs to everyone”, and the month is built around 300+ one-day, in-person events called Fests, an online program of challenges and livestreams about open-source AI, and virtual stickers that turn into a real sticker pack in the mail. Anyone aged 13 or older can take part, and it costs nothing.
\nWhat it is no longer is a pull request counter. To understand why that matters, and to read the labels and contributing guides projects still carry, you need the old rules first.
\nFor eleven editions, the event was a checklist, and projects wrote their contributing guides, labels and issue templates around it. Those are still there, so a newcomer in October 2026 meets both sets of rules at once.
\nUntil 2025, you registered on hacktoberfest.com with your GitHub or GitLab account and opened your pull requests between October 1 and October 31. A pull request counted when the repository carried the hacktoberfest topic, or when a maintainer put the hacktoberfest-accepted label on it, and when it was merged, approved or labeled as accepted. It then sat in a seven-day review window during which a maintainer could still mark it spam or invalid. Two spam pull requests and you were out. The count went from four to six in 2025.
\nThe reward moved too. The T-shirt ran from 2014 to 2022. For the tenth edition, DigitalOcean replaced it with a digital badge from Holopin and a tree for the first 50,000 people to get a first pull request accepted: producing over 50,000 T-shirts and shipping them around the world had taken most of the program’s budget, and in many countries the customs fees cost more than the shirt. In 2025 a limited T-shirt came back for the first 10,000 people with six merged pull requests.
\nThe announcement came from Jess Lee and Ryan Swift on August 19, 2026, on MLH’s blog. The format had started to work against the people it depended on. Maintainers, they wrote, “began to burn out under the volume of low-effort, box-checking pull requests”, and AI tools made it trivial to generate one without generating any value.
\n\nThe FAQ answers that question in one sentence: pull requests and merge requests no longer count toward rewards, because the organizers are “listening to maintainer feedback and no longer actively incentivizing PRs”. The same answer encourages you to work on open source anyway. Three things replace the counter.
\nFests. A Fest is a one-day, in-person event hosted by a local organizer: either a Hack Day, a mini-hackathon with workshops, prizes and MLH funding, or a Meetup, with less structure and no prizes. On October 1, 2026, the directory listed 382 of them: 284 Hack Days, 54 Meetups, 33 MLH member events and 9 pop-ups, 146 of them in India.
\n\nAn online program. DEV runs a Weekend Challenge from October 2, then four weekly Open-Source AI Challenges starting October 5, 12, 19 and 26, with cash prizes. MLH runs Global Hack Week from October 9 to 15: daily workshops streamed on Twitch, mini-events on the MLH Discord, and social, technical and design challenges that earn points. The suggested projects are things like writing your first skills.md, building an open source agent, or fine-tuning an open-weight model. The launch livestream is on October 1 at 15:00 UTC.
Stickers. Signing in to My Hacktoberfest with a MyMLH account and adding your address earns the first two virtual stickers. Every activity earns another: a livestream, a challenge submission, a Fest check-in, joining the Discord. At three, a real sticker pack is mailed to you, 8 to 12 weeks after the month ends. At ten you get a holographic one, and at fifteen you enter a raffle for T-shirts and Arduino boards. T-shirts are otherwise handed out at Fests only, and not guaranteed.
\n\nHost a Fest. Anyone can apply with a description of their community and a format. A Hack Day comes with MLH funding for food and prizes, swag for the participants, help with the program and a listing in the directory; a Meetup gets the swag and the listing. Confirmation is rolling, within a week of a complete application.
\nReview and mentor. A Fest full of first pull requests needs people who can read a diff and explain a review. If you maintain a project, the chapter on reviewing pull requests is the job description.
\nRun your own October. The official counter is gone, but nothing stops a project from running its own. Kestra does, with two tracks, a podium per track, and merchandise for every merged pull request. Its rules are the ones that keep such a program healthy: the issue must be linked from the pull request, you ask to be assigned before you start, and only two of your pull requests can be open at a time. Meilisearch has tagged eligible issues and offered swag for years, and answers fast; that is how Bruno Casali went from a Ruby integration contributor in 2021 to the team’s lead, with a job offer ten days after his first pull request.
\n\nDecide whether your project opts in. The topic no longer summons a badge, so the October wave should be smaller; it won’t be zero, because tutorials, lists and a decade of habit still point newcomers at it. If you want them, do what Jessica Wilkins did for freeCodeCamp’s quiz site in 2022, when she merged 356 pull requests in the month: issue templates with required fields, issues written with the expected code in them, a contributing guide rewritten for beginners, labels for hacktoberfest, first-timers-only and spam, and saved replies so the hundredth answer is as kind as the first. If you don’t want them, remove the topic, say so in the contributing guide, and use the limits: since June 17, 2026, GitHub lets a repository cap how many pull requests a user without write access can have open, and interaction limits can restrict new accounts for a day or a week. Saying No has the replies to save.
\nHacktoberfest is where a lot of people’s first pull request happened, and the numbers are not small. In 2018, 46,088 people completed the challenge. In 2021, 294,451 pull requests were accepted by maintainers. In 2019, 673 in-person gatherings took place in 393 cities and 73 countries. In DigitalOcean’s 2023 survey of 1,237 participants, 78% were positive about the event after the T-shirt was gone, and 59% of the maintainers said it had benefited their project.
\nIt gave projects a reason to do the work that makes any contribution easier: write the issue properly, label it, answer within the day. The freeCodeCamp quiz site went from 694 to 1,171 questions in one October, and from 42 to 109 stars; the templates and the labels outlived the month. Meilisearch found a team lead. A deadline and a shared occasion do move people: in the same survey, the reasons given for not finishing were time and motivation, not spam.
\nAnd for a newcomer, the event solved the question that stops most first contributions: where do I start? A topic, a label, a month and a thousand projects that had agreed to be patient.
\nThe deal rewarded the count, and the count is easy to fake.
\nAdded “awesome” to the README, please merge for Hacktoberfest 🙏
Closing. This isn’t a contribution, and the repository didn’t opt in. Labeling it spam.
Why so rude?? I just need 4 PRs
Invalid pull requests went from 1,861 in 2017 to 11,083 in 2018, 2.7% of the total. In 2020 the wave broke. On September 30, Domenic Denicola, who maintains the WHATWG HTML standard, counted 11 spam pull requests closed before the event had started, arriving at about four an hour, and called the event “a corporate-sponsored distributed denial of service attack against the open source maintainer community”. Drew DeVault’s Spamtoberfest came out on October 1, and the story ran in The Register and InfoQ. On October 3, DigitalOcean made the event opt-in, three days in. Its recap counted 621,104 pull requests that month, 9,598 flagged as spam or invalid, and 172,599 sent to repositories that had never opted in.
\nThe second problem was quieter: repositories built to be contributed to. “Add your name to the list” projects collected hundreds of one-line pull requests and gave their authors four accepted ones in an afternoon. In 2021 DigitalOcean started excluding repositories that encouraged low-effort contributions; in 2023 the organizers still counted 39,859 pull requests sent to excluded repositories, 14.91% of everything they tracked. The same pattern runs outside October: in February 2024, a Git tutorial with 1.4 million views used the Express.js repository as its live example, and hundreds of practice pull requests landed on its maintainers, each one a notification to the repository’s 485 watchers.
\nThe third problem is the one that ended the counter. From 2023, a pull request could be written by a tool in seconds, with a convincing title and a description that read well. The organizers’ own mission page says it: AI tools make low-effort pull requests easier than ever to generate, and maintainers face unprecedented volume and noise. The guide’s chapter on contributing with AI tools lists the limits projects adopted in response, from Ghostty’s voucher to LLVM’s labels.
\nThe participation numbers tell the rest. 169,886 registered in 2020, 146,891 in 2022, 98,855 in 2023, and 56,768 in 2025; DigitalOcean published no recap for 2024. Part of that is the opt-in and the T-shirt, which removed the reasons the spammers came for. Part of it is that fewer people are chasing a portfolio line for a junior job that isn’t there, as a December 2025 post argued. Either way, the event that remains is the one its critics asked for in 2020, and it is a smaller one.
\nYes, whether it’s your first Hacktoberfest or your tenth, and not for the stickers. What you get out of it depends on where you start.
\nIf it’s your first time, go to a Fest if there’s one near you: a room where people make their first pull request together is rarer than a T-shirt. Then make one, to a project you use, with the project’s rules read first. The guide’s Contributing module is the long version, and if you’d rather practice before you send anything to a real project, My First Contribution is a repository made for exactly that.
\nIf you have taken part before, the event needs you more than the stickers do: host a Fest, mentor at one, or review the pull requests a Fest sends to the projects you know. And if you maintain a project, October is a good month to decide what you want from new contributors, write it down, and set the limits that let you say yes to the rest.
", "date_published": "2026-10-01T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Community", "Contribution", "Events" ] }, { "id": "https://openresource.dev/articles/running-a-local-ai-inside-obsidian-with-ollama/", "url": "https://openresource.dev/articles/running-a-local-ai-inside-obsidian-with-ollama/", "title": "Running a Local AI Inside Obsidian with Ollama", "summary": "Learn to set up Ollama with Obsidian for a completely local AI writing assistant. Step-by-step guide to private, offline AI that works with your notes without sending data to the cloud.", "content_html": "What if your notes could think with you, without sending a single word to the cloud? In this article, we’ll build a fully local AI setup inside Obsidian using Ollama and the open Gemma 4 model. You’ll learn why local AI makes sense for knowledge work, how to install and test Ollama from the command line, how to connect it to Obsidian using community plugins, and how to use it for practical, everyday note-taking workflows, all while keeping full control over your data.
\nBefore jumping into installation, it’s worth clarifying what is and isn’t open source in this setup, and why it still aligns strongly with open source values.
\nObsidian is an application that allows users to create and manage notes using plain text Markdown files stored locally on their devices.
\nObsidian is not open source itself, but supports open source community plugins, and is local-first:
\nThis dramatically reduces vendor lock-in. Even without Obsidian, your knowledge remains usable.
\nOllama is an open source tool that lets you run AI models locally on your machine:
\nTogether, Obsidian and Ollama create a powerful combination that aligns with open source values: local notes, local AI for privacy, and knowledge work that you actually control.
\nBy the end of this article, you’ll have:
\nEverything described below has been tested using Gemma 4 with Ollama.
\nLet’s consider that Obsidian is already installed on your machine. If you haven’t done so yet, you can download it from obsidian.md.
\nInstall Ollama from the official site at https://ollama.com, or on macOS via
\n![\"The](\"https://openresource.dev/images/hacktoberfest-2.png\")
![\"The](\"https://openresource.dev/images/hacktoberfest-3.png\")
![\"The](\"https://openresource.dev/images/hacktoberfest-5.webp\")
![\"GitHub's](\"https://openresource.dev/images/hacktoberfest-4.png\")
![\"Kestra's](\"https://openresource.dev/images/hacktoberfest-6.png\")
curl -fsSL https://ollama.com/install.sh | shVerify the installation by running in your terminal:
\nollama --versionThe output should show the installed version of Ollama.
\nPull and run the Gemma 4 model with:
\nollama run gemma4Once the model is downloaded, you’ll get an interactive prompt. Test it with:
\nExplain what a local-first application is in one paragraph.If you receive a response, everything is working correctly.
\nExit the chat with the command:
\n/byeOllama also starts a local API server at http://localhost:11434.
\nOpening this URL in your browser will show the “Ollama API is running” message. This endpoint is what Obsidian will use next.
\nTo connect Obsidian to Ollama, you’ll need two open source Obsidian community plugins created by Pavel Frankov:
\n![\"\"](\"https://avatars.githubusercontent.com/u/584632?v=4&s=96\")
pfrankov/pfrankov/Let’s start by installing the AI Providers plugin.
\nIn Obsidian, go to “Settings → Community Plugins → Browse” and search for “AI Providers”.
\n\nClick “Install”, then “Enable” to enable the plugin.
\nClick “Options” to configure the plugin:
\nThen, install the Local GPT plugin.
\nIn Obsidian, go to “Settings → Community Plugins → Browse” and search for “Local GPT”.
\n\nClick “Install”, then “Enable” to enable the plugin.
\nClick “Options” to configure the plugin:
\nTo quickly access Local GPT features, set up hot keys in Obsidian.
\nIn Obsidian, go to “Settings → Hotkeys”.
\nFilter by “Local”.
\nAssign hot keys to the following commands:
\nNow that everything is set up, it’s time to test Local GPT inside Obsidian.
\nTwo hot keys are set up: one for the action palette and one for the context menu.
\nThe context menu is a quick way to apply AI actions to selected text.
\nOpen any note in Obsidian.
\nSelect some text you want to process with AI.
\nPress the hot key you assigned for “Local GPT: Show context menu” (e.g., ⌘ + M). It will open a context menu with various AI actions you can perform on the selected text:
\nPlease note that you can create your own custom prompts as well.
\nLet’s say I’ve written this article in Obsidian first and wanted to summarize it. I would select the text and use the context menu to choose “Summarize”.
\n\nGemma 4 would then generate a concise summary of the selected content directly at the end of my note (this can be configured).
\n\nThe action palette allows you to type custom prompts and interact with Local GPT more freely.
\nLet’s say I want to analyze an image to describe its content. I would select the image in my note, open the action palette, and type: “Describe this image!”
\n\nThe model would then generate a description of the image directly in my note.
\n\nI just scratched the surface of what you can do with this setup, and honestly, it’s pretty useful for specific tasks. Gemma 4 works well for close-to-the-text stuff: cleaning up messy first drafts, turning rambling meeting notes into actual bullet points, or getting a quick summary when I don’t want to reread a long note.
\nResponse times are decent for most tasks. Not instant, but fast enough to keep you in the flow.
\nWhere I use it most is rewriting awkward sentences, expanding bullet points when I need more detail, or brainstorming different ways to phrase something. It’s also surprisingly good at catching unclear writing that I might miss.
\nBut it definitely has limits. It can’t access other notes in my vault (just the current one), struggles with complex reasoning, and sometimes gives generic responses if your prompt is too vague. I’m also not sure how well it handles really technical content as I’ve had mixed results there.
\nThe key thing I’ve learned is that it works best as an editing partner for stuff you’ve already written, rather than generating ideas from scratch.
\nMaybe a more powerful setup could mix local and cloud models, using local for sensitive stuff and cloud for heavy lifting when needed. But for now, this local-first approach feels like a solid step toward more private, controllable AI in my writing workflow.
\nLocal AI isn’t perfect:
\nBut in exchange, you get:
\nFor personal knowledge management and everyday writing, that trade-off is often not just acceptable, but desirable.
\nIf you try out this setup, let me know how it goes! Share your experiences, tips, or custom workflows in our social platforms.
\nHappy note-taking!
", "date_published": "2026-02-01T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "AI", "Tools", "Tutorial" ] }, { "id": "https://openresource.dev/articles/coding-linkedin-carousels/", "url": "https://openresource.dev/articles/coding-linkedin-carousels/", "title": "Coding LinkedIn Carousels", "summary": "Creating LinkedIn carousels is a great way to share information in a visually appealing format. Learn how to code LinkedIn carousels with this guide.", "content_html": "Coding LinkedIn carousels… yes, not using design tools but using developer tools! It’s now possible!
\nA few days ago, we shared a new article on LinkedIn and tried to make it more engaging by using a carousel. And creating a carousel on LinkedIn can take a bit of time, especially if you’re not that familiar with design tools such as Canva, Figma, or even Penpot, our open-source design tool friend. Even with the tons of templates available out there, customizing them is a lot of work.
\nIn the open-source software world, we are mostly developers, we’re not going to lie. So, we thought: “Why not code the LinkedIn carousel?” And that’s what we did!
\nJust for those who are not familiar with LinkedIn carousels, they are a series of images or slides that you can swipe through. They are a great way to share information in a visually appealing format. You can use them to showcase your open-source project, share tips, or even tell a story.
\nThere’s no real creator tool for LinkedIn carousels, so you have to create them yourself.
\nBasically, a LinkedIn carousel is in fact a PDF file. You can create a PDF file with multiple pages, and each page will be a slide in your carousel. You can then upload this PDF file to LinkedIn, and it will automatically convert it into a carousel.
\nSo, if it just a PDF file, why not code it? We can create a simple HTML file with multiple slides, and then convert it into a PDF file. And that’s what we did!
\nWe already use this great tool for presentations, it’s called Slidev.
\nSlidev is a presentation tool based on Vue.js. It allows you to create beautiful slides with Markdown and code. And it has a feature to export your slides as a PDF file. It is an open-source project, under the MIT license.
\n![\"\"](\"https://avatars.githubusercontent.com/u/83095831?v=4&s=96\")
slidevjs/It’s really simple in fact.
\nThe first step is to create a new Slidev project. You can do this by running the following command:
\n![\"Obsidian’s](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-1.webp\")
![\"The](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-2.png\")
![\"Obsidian’s](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-3.webp\")
![\"Local](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-4.png\")
![\"Obsidian](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-5.png\")
![\"The](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-6.png\")
![\"A](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-7.png\")
![\"The](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-8.png\")
![\"The](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-9.png\")
![\"The](\"https://openresource.dev/images/running-a-local-ai-inside-obsidian-with-ollama-10.png\")
![\"LinkedIn’s](\"https://openresource.dev/images/coding-linkedin-carousels-1.png\")
![\"LinkedIn’s](\"https://openresource.dev/images/coding-linkedin-carousels-2.png\")
npm init slidev@latestThis will create a new Slidev project in the current directory. You can then open the project in your code editor and start customizing the slides.
\nObviously, you’ll notice that the default Slidev theme is not really suitable for LinkedIn carousels as the slides are generally wide, in a 16:9 ratio. So, you’ll need to customize the theme to make it more suitable for LinkedIn carousels.
\nIn the slides.md you just have to add the following properties in the frontmatter:
---\naspectRatio: "3/4"\ncanvasWidth: 800Just install playwright-chromium as a dev dependency, and export your slides as a PDF file:
npm install -D playwright-chromium\nnpm run exportAnd voilà, you got a nice slides-export.pdf that could be used as a LinkedIn carousel!
However, you’ll notice that you still have some design work to do in order to render your carousel more visually appealing.
\nSo, we created a theme for LinkedIn carousels called slidev-theme-linkedin-carousel, that is an open-source project under the MIT license.
![\"\"](\"https://avatars.githubusercontent.com/u/129324099?v=4&s=96\")
Open-reSource/Here’s what it looks like: https://slidev-theme-lk-carousel.netlify.app.
\n![\"Cover](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/1.png\")
![\"Text](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/2.png\")
![\"Image](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/3.png\")
![\"A](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/4.png\")
![\"The](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/5.png\")
![\"The](\"https://cdn.jsdelivr.net/npm/slidev-theme-linkedin-carousel@latest/example-export/6.png\")
To use the theme, you just have to install it as a dev dependency:
\nnpm i -D slidev-theme-linkedin-carouseland then add the following frontmatter to your slides:
\n---\ntheme: linkedin-carousel\n---For more information on how to use the theme, check out the README.
\nThe example.md file in the repository is a good starting point to create your own LinkedIn carousels. And from there, you can customize the slides to your liking, and even use custom components to make them more impacting.
Don’t hesitate to share your LinkedIn carousels with us, we’d love to see them! See ya on LinkedIn!
\nIf you liked this theme, use it, please consider giving it a star on GitHub, or even sponsoring us. It helps us a lot!
", "date_published": "2024-09-29T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "LinkedIn", "Social Media", "Tools" ] }, { "id": "https://openresource.dev/articles/add-funding-links-to-your-packagejson/", "url": "https://openresource.dev/articles/add-funding-links-to-your-packagejson/", "title": "Add Funding Links to Your 'package.json'", "summary": "Learn how to add funding links to your 'package.json' file to make it easier to support your open-source project.", "content_html": "Fund your open-source project by adding funding links to your package.json file. Who knows, you might get a coffee or two out of it!
If you’re not new to the content of Open {re}Source, you know a thing or two about the importance of financing and funding open-source projects. The time and effort that maintainers put into their projects are invaluable, and it’s essential to support them in any way possible.
\nSupporting open-source projects can be as simple as starring a repository, contributing to the codebase, or even providing financial support. The latter can be done through platforms like GitHub Sponsors, Open Collective, or even through direct donations.
\nHave you ever noticed the funding information displayed when you run the npm i command in your terminal?
% npm install\n\n247 packages are looking for funding\n run `npm fund` for detailsIf you’re not a fan of the funding information displayed when installing packages, you can turn it off by setting the --no-fund flag when running the npm install command.
You can also set it as a default behavior by running npm config set fund false.
Or you can turn it off in your .npmrc file in your home directory (~/.npmrc) manually or in your project’s .npmrc file:
fund = falsenpm fund CommandHave you already launched npm fund in your terminal? If not, go ahead and do it now in one of your projects.
Here’s what it looks like for this repository:
\nopenresource.dev@0.0.0\n├── https://opencollective.com/fakerjs\n│ └── @faker-js/faker@9.0.1\n├── https://dotenvx.com\n│ └── dotenv@16.4.5\n├── https://github.com/sponsors/wooorm\n│ └── gemoji@8.1.0, bcp-47@2.1.0, bcp-47-match@2.0.3, direction@2.0.1, longest-streak@3.1.0, bail@2.0.2, trough@2.2.0, collapse-white-space@2.1.0, comma-separated-tokens@2.0.3, ccount@2.0.1, parse-entities@4.0.1, character-entities-legacy@3.0.0, character-reference-invalid@2.0.1, is-alphanumerical@2.0.1, is-alphabetical@2.0.1, is-decimal@2.0.1, is-hexadecimal@2.0.1, stringify-entities@4.0.4, character-entities-html4@2.1.0, property-information@6.5.0, space-separated-tokens@2.0.2, zwitch@2.0.4, html-void-elements@3.0.0, web-namespaces@2.0.1, markdown-table@3.0.3, import-meta-resolve@4.1.0, decode-named-character-reference@1.0.2, character-entities@2.0.2, devlop@1.1.0, trim-lines@3.0.1, parse-latin@7.0.0, array-iterate@2.0.1\n├── https://opencollective.com/vitest\n│ └── vitest@2.1.1, @vitest/expect@2.1.1, @vitest/mocker@2.1.1, @vitest/pretty-format@2.1.1, @vitest/runner@2.1.1, @vitest/snapshot@2.1.1, @vitest/spy@2.1.1, @vitest/utils@2.1.1, vite-node@2.1.1\n├─┬ https://paulmillr.com/funding/\n│ │ └── chokidar@3.6.0\n│ ├── https://github.com/sponsors/jonschlinkert\n│ │ └── picomatch@2.3.1, picomatch@4.0.2\n│ └── https://github.com/sponsors/sindresorhus\n│ └── binary-extensions@2.3.0, is-plain-obj@4.1.0, markdown-extensions@2.0.0, escape-string-regexp@5.0.0, make-dir@3.1.0, boxen@7.1.1, camelcase@7.0.1, cli-boxes@3.0.0, string-width@5.1.2, type-fest@2.19.0, widest-line@4.0.1, ora@8.1.0, cli-cursor@5.0.0, restore-cursor@5.1.0, onetime@7.0.0, mimic-function@5.0.1, cli-spinners@2.9.2, is-interactive@2.0.0, is-unicode-supported@2.1.0, log-symbols@6.0.0, is-unicode-supported@1.3.0, stdin-discarder@0.2.2, p-limit@2.3.0, p-queue@8.0.1, p-timeout@6.1.2, string-width@7.2.0, get-east-asian-width@1.2.0, is-docker@3.0.0, is-wsl@3.1.0, is-inside-container@1.0.0, find-up-simple@1.0.0, is-absolute-url@4.0.1, get-stream@5.2.0, is-stream@2.0.1, onetime@5.1.2, pretty-ms@7.0.1, time-span@4.0.0\n├── https://github.com/prettier/prettier?sponsor=1\n│ └── prettier@2.8.7\n├── https://github.com/sponsors/epoberezkin\n│ └── ajv@6.12.6\n├── https://github.com/sponsors/feross\n│ └── run-parallel@1.2.0, queue-microtask@1.2.3, safe-buffer@5.2.1\n├─┬ https://github.com/chalk/wrap-ansi?sponsor=1\n│ │ └── wrap-ansi@7.0.0, wrap-ansi@8.1.0\n│ └── https://github.com/chalk/ansi-styles?sponsor=1\n│ └── ansi-styles@4.3.0, ansi-styles@6.2.1\n├── https://opencollective.com/unified\n│ └── hast-util-from-html@2.0.1, hast-util-select@6.0.2, hast-util-has-property@3.0.0, hast-util-to-string@3.0.0, hastscript@9.0.0, mdast-util-directive@3.0.0, mdast-util-to-markdown@2.1.0, mdast-util-phrasing@4.1.0, mdast-util-to-string@4.0.0, rehype@13.0.1, rehype-parse@9.0.0, rehype-format@5.0.0, hast-util-embedded@3.0.0, hast-util-phrasing@3.0.1, hast-util-is-body-ok-link@3.0.0, html-whitespace-sensitive-tag-names@3.0.0, rehype-minify-whitespace@6.0.0, remark-directive@3.0.0, micromark-extension-directive@3.0.1, unified@11.0.5, unist-util-visit@5.0.0, vfile@6.0.3, @mdx-js/mdx@3.0.1, estree-util-build-jsx@3.0.1, estree-util-is-identifier-name@3.0.0, estree-util-to-js@2.0.0, hast-util-to-estree@3.1.0, estree-util-attach-comments@3.0.0, hast-util-whitespace@3.0.0, mdast-util-mdx-expression@2.0.0, mdast-util-mdx-jsx@3.1.3, vfile-message@4.0.2, mdast-util-mdxjs-esm@2.0.1, hast-util-to-jsx-runtime@2.3.0, remark-mdx@3.0.1, mdast-util-mdx@3.0.0, micromark-extension-mdxjs@3.0.0, micromark-extension-mdx-jsx@3.0.1, micromark-extension-mdx-md@2.0.0, micromark-extension-mdxjs-esm@3.0.0, unist-util-position-from-estree@2.0.0, estree-util-visit@2.0.0, hast-util-to-html@9.0.2, rehype-raw@7.0.0, hast-util-raw@9.0.4, hast-util-from-parse5@8.0.1, hastscript@8.0.0, hast-util-parse-selector@4.0.0, vfile-location@5.0.3, hast-util-to-parse5@8.0.0, remark-gfm@4.0.0, mdast-util-gfm@3.0.0, mdast-util-gfm-autolink-literal@2.0.1, mdast-util-find-and-replace@3.0.1, mdast-util-gfm-footnote@2.0.0, mdast-util-gfm-strikethrough@2.0.0, mdast-util-gfm-table@2.0.0, mdast-util-gfm-task-list-item@2.0.0, micromark-extension-gfm@3.0.0, micromark-extension-gfm-autolink-literal@2.1.0, micromark-extension-gfm-footnote@2.1.0, micromark-extension-gfm-strikethrough@2.1.0, micromark-extension-gfm-table@2.1.0, micromark-extension-gfm-tagfilter@2.0.0, micromark-extension-gfm-task-list-item@2.1.0, remark-stringify@11.0.0, hast-util-to-text@4.0.2, hast-util-is-element@3.0.0, unist-util-find-after@5.0.0, unist-util-is@6.0.0, mdast-util-definitions@6.0.0, rehype-stringify@10.0.0, remark-parse@11.0.0, mdast-util-from-markdown@2.0.1, unist-util-stringify-position@4.0.0, remark-rehype@11.1.0, mdast-util-to-hast@13.2.0, unist-util-position@5.0.0, unist-util-remove-position@5.0.0, unist-util-visit-parents@6.0.1, retext@9.0.0, retext-latin@4.0.0, nlcst-to-string@4.0.0, unist-util-modify-children@4.0.0, unist-util-visit-children@3.0.0, retext-stringify@4.0.0, retext-smartypants@6.1.1\n├── https://locize.com\n│ └── i18next@23.15.1\n├── https://github.com/sponsors/antfu\n│ └── oniguruma-to-js@0.3.3\n├── https://github.com/sponsors/colinhacks\n│ └── zod@3.23.8\n├─┬ https://opencollective.com/postcss/\n│ │ └── postcss@8.4.45, postcss-nested@6.2.0\n│ └── https://github.com/sponsors/ai\n│ └── nanoid@3.3.7\n├── https://github.com/sponsors/isaacs\n│ └── glob@7.2.3, rimraf@3.0.2, signal-exit@4.1.0, signal-exit@4.0.2\n├─┬ https://opencollective.com/babel\n│ │ └── @babel/core@7.25.2\n│ └── https://opencollective.com/browserslist\n│ └── browserslist@4.23.3, caniuse-lite@1.0.30001660, update-browserslist-db@1.1.0\n├── https://github.com/sponsors/sibiraj-s\n│ └── ci-info@4.0.0\n├─┬ https://github.com/chalk/strip-ansi?sponsor=1\n│ │ └── strip-ansi@7.1.0\n│ └── https://github.com/chalk/ansi-regex?sponsor=1\n│ └── ansi-regex@6.1.0\n├── https://github.com/vitejs/vite?sponsor=1\n│ └── vite@5.4.6\n├── https://opencollective.com/libvips\n│ └── sharp@0.33.5, @img/sharp-darwin-arm64@0.33.5, @img/sharp-libvips-darwin-arm64@1.0.4\n├─┬ https://github.com/sponsors/fb55\n│ │ └── css-select@5.1.0, css-what@6.1.0, domelementtype@2.3.0\n│ ├── https://github.com/fb55/domhandler?sponsor=1\n│ │ └── domhandler@5.0.3\n│ └─┬ https://github.com/fb55/domutils?sponsor=1\n│ │ └── domutils@3.1.0\n│ └── https://github.com/cheeriojs/dom-serializer?sponsor=1\n│ └── dom-serializer@2.0.0\n├── https://github.com/fb55/htmlparser2?sponsor=1\n│ └── htmlparser2@8.0.2\n├── https://github.com/sponsors/NaturalIntelligence\n│ └── fast-xml-parser@4.5.0\n├─┬ https://github.com/privatenumber/get-tsconfig?sponsor=1\n│ │ └── get-tsconfig@4.8.1\n│ └── https://github.com/privatenumber/resolve-pkg-maps?sponsor=1\n│ └── resolve-pkg-maps@1.0.0\n└── https://github.com/sponsors/ljharb\n └── minimist@1.2.8As stated in the official npm documentation, the npm fund command shows funding information for the installed packages in your project.
And there can be a lot of them!
\nBut you might wonder, how can you add funding information to your own project? It can be interesting to let know the world that you are looking for funding, right?
\npackage.jsonIt’s quite simple in fact. You can add funding information to your package.json file by using the funding field.
As stated in the official npm documentation:
\n\n\nYou can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs:
\n
{\n\t"funding": [\n\t\t{\n\t\t\t"type": "individual",\n\t\t\t"url": "http://example.com/donate"\n\t\t},\n\t\t"http://example.com/donateAlso",\n\t\t{\n\t\t\t"type": "patreon",\n\t\t\t"url": "https://www.patreon.com/my-account"\n\t\t}\n\t]\n}From there, those who install your package might see the funding information when they run some npm commands. And who knows, they might decide to support your project!
\nOn top of that, if your package is listed on the npm registry, the funding information will be displayed on the package’s page with a “Fund this package” button:
\n\nFunding your open-source project might be complicated, but referencing your funding links a the right places can make it easier for people to support you. And adding funding links to your package.json file is a good start! It’s not going to make hundreds of people support you, for sure, but it’s a good way to let the world know that you are looking for funding; and little by little, you might get a coffee or two out of it!
After the refactoring of this website, folks (maybe you) started to spread the word about it. The statistics started to rise a little bit, and we discovered along the way that the repository holding this website also started to receive some new stars. To our knowledge, there’s no native way to get notified by GitHub when you receive stars on your repositories. So, we decided to do something about it!
\nWe know, we know, tracking stars is a little bit linked to the gamification of the open source world, but to be honest, it’s still a fun way to keep track of your project’s popularity and engage with your community.
\nSo, we decided to build a simple automation that would send a notification to a private Discord channel whenever our GitHub repository receives new stars. There are probably better ways to do this, existing solutions, but where is the fun in that?
\nAfter a few times of tweaking and testing, we finally got it working! 🎉
\nHere is the notification we received on our phone this afternoon:
\n\nAnd when you click on the notification, here is how the notification appears on Discord, showing the new star count and the repository name:
\n\nCool, right? Here’s how it’s been done!
\nTo send notifications to Discord, you will need to set up a webhook in your Discord server. Here’s how to do it:
\nHere’s also a link to the Discord documentation - Intro to Webhooks for more information.
\nNow, let’s create a private GitHub repository to store our future GitHub Actions workflow. You can create a new repository or use an existing one, make it public or private, as you prefer.
\nTo securely store your Discord Webhook URL to ensure that sensitive data isn’t exposed in your repository code, you will need to create a secret variable in your GitHub repository:
\n![\"Screenshot](\"https://openresource.dev/images/add-funding-links-to-your-package.json.png\")
![\"A](\"https://openresource.dev/images/get-real-time-github-stars-notifications-in-discord-1.png\")
![\"GitHub](\"https://openresource.dev/images/get-real-time-github-stars-notifications-in-discord-2.png\")
DISCORD_WEBHOOK_URL and paste the webhook URL you copied from Discord.\n\n[!NOTE] What is GitHub Actions?\nIf you’re not familiar with GitHub Actions, it allows you to automate workflows directly in your GitHub repository, and it can be triggered based on various events. More information can be found in the GitHub Actions documentation.
\n
In this repository:
\n.github/workflows.gh-stars-to-discord.yml (or choose a name you prefer).The algorithm is rather simple:
\nTo get started, you will need to use the GitHub REST API to fetch the star count for your repository. The GitHub API provides a simple way to access information about your repositories, including the number of stars they have received.
\nThere is a public endpoint that you can use to get the star count for a specific repository:
\nGET https://api.github.com/repos/{owner}/{repo}Replace {owner} with your GitHub username and {repo} with the name of your repository. The response will include a JSON object with various details about the repository, including the stargazers_count field, which indicates the number of stars.
So for our main repository, you would make a request to:
\nGET https://api.github.com/repos/Open-reSource/openresource.dev\n\n[!NOTE] Try it out!\nYou can try it out directly in your browser (or using a tool like Curl) to see the JSON response. In the browser, you can simply paste the URL into the address bar and hit enter.
\n
In September 2024, when this article was written, the Open {re}Source main repository had 61 stars, so the answer was:
\n{\n\t// ...\n\t"stargazers_count": 61\n\t// ...\n}\n\n[!WARNING] Be mindful of the GitHub API rate limits\nBe mindful of the GitHub API rate limits when making requests. You can find more information about the rate limits in the GitHub API documentation.
\nAs of September 2026, the GitHub API allows for up to 60 requests per hour for unauthenticated requests and up to 5,000 requests per hour for authenticated requests. If you plan to make frequent requests, consider using a personal access token for authentication.
\n
Now, let’s create the actual workflow:
\ngh-stars-to-discord.yml file:\n\n[!NOTE]
\n\n
\n- Make sure to replace
\nopen-reSource/openresource.devwith your own repository name.- The workflow is set to run every hour, but you can adjust the schedule as needed by changing the
\ncronexpression.- You can change the text of the notification sent to Discord by modifying the
\ncurlcommand in theCompare and notify if new starsstep.
name: GitHub Stars to Discord\n\non:\n schedule:\n - cron: '0 * * * *' # Every 1 hour. You can change the frequency as needed.\n workflow_dispatch: # Allows manual triggering\n\nenv:\n DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}\n GITHUB_REPOSITORY: 'open-reSource/openresource.dev' # Change this to your repository\n\njobs:\n notify:\n runs-on: ubuntu-latest\n\n steps:\n - name: Get the current number of stars and check rate limit\n id: get_stars\n run: |\n response=$(curl -s -i https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }})\n stars=$(echo "$response" | grep -oP '"stargazers_count":\\s*\\K\\d+')\n rate_limit_remaining=$(echo "$response" | grep -Fi 'X-RateLimit-Remaining:' | awk -F': ' '{print $2}' | tr -d '\\r')\n\n echo "Current stars: $stars"\n echo "Rate limit remaining: $rate_limit_remaining"\n\n echo "stars=$stars" >> $GITHUB_OUTPUT\n echo "rate_limit_remaining=$rate_limit_remaining" >> $GITHUB_OUTPUT\n\n - name: Stop if rate limit is low\n if: ${{ steps.get_stars.outputs.rate_limit_remaining < 10 }}\n run: |\n echo "Rate limit is low, exiting"\n exit 1\n\n - name: Cache previous stars count\n id: cache_previous_stars\n uses: actions/cache@v4\n with:\n path: previous_stars.txt\n key: stars-${{ github.repository }}-${{ github.run_id }}\n restore-keys: |\n stars-${{ github.repository }}-\n\n - name: Load the previous number of stars\n id: load_previous_stars\n run: |\n if [ -f previous_stars.txt ]; then\n echo "Loading previous stars"\n PREVIOUS_STARS=$(cat previous_stars.txt)\n else\n echo "No previous stars found"\n PREVIOUS_STARS=0\n fi\n echo "Previous stars: $PREVIOUS_STARS"\n echo "previous_stars=$PREVIOUS_STARS" >> $GITHUB_OUTPUT\n\n - name: Compare and notify if new stars\n if: ${{ steps.get_stars.outputs.stars != steps.load_previous_stars.outputs.previous_stars }}\n run: |\n NEW_STARS=${{ steps.get_stars.outputs.stars }}\n PREVIOUS_STARS=${{ steps.load_previous_stars.outputs.previous_stars }}\n if [ $NEW_STARS -gt $PREVIOUS_STARS ]; then\n echo "There are new stars: $NEW_STARS stars (previous: $PREVIOUS_STARS)"\n curl -H "Content-Type: application/json" \\\n -d "{\\"content\\": \\"The repository has gained new stars! Previous: $PREVIOUS_STARS → Total: $NEW_STARS\\"}" \\\n ${DISCORD_WEBHOOK_URL}\n else\n echo "No new stars"\n fi\n\n - name: Save current stars count\n run: |\n echo "${{ steps.get_stars.outputs.stars }}" > previous_stars.txt\n\n - name: Update cache with new stars count\n uses: actions/cache@v4\n with:\n path: previous_stars.txt\n key: stars-${{ github.repository }}-${{ github.run_id }}The workflow has a workflow_dispatch trigger, which means you can run it manually from the GitHub Actions tab in your repository. You can also wait for the next scheduled run (every hour) to see it in action.
The first time you run the workflow, it will probably send a notification saying that you had 0 stars and now you have X stars (the current number of stars).
\n\n\n[!NOTE]\nWe voluntarily left some logging in the workflow to help you debug if needed. You can remove or comment out the
\nechostatements if you want to clean up the logs.To check the logs, once your YAML file is pushed to the repository, go to the “Actions” tab, select the workflow, and click on the latest run. All the logs will be displayed there.
\n
To be honest, we are a little bit lazy, so we didn’t implement a complex logic to handle this first run, or even when the count of stars decreases. But you can always improve the workflow to suit your needs! This is just a starting point.
\nAutomation is really cool! You could do the same thing for your followers in your GitHub profile, send notifications by email, Slack, etc. But automation is not limited to just notifications. You can also automate tasks like deploying your code, running tests, and much more.
\nThe possibilities are endless!
\nA few words before we finish:
\nHappy coding! 🎉
", "date_published": "2024-09-17T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Automation", "Discord", "Discord Webhook", "GitHub", "GitHub Actions", "GitHub API", "GitHub Stars" ] }, { "id": "https://openresource.dev/articles/bluesky-starter-pack/", "url": "https://openresource.dev/articles/bluesky-starter-pack/", "title": "Bluesky Starter Pack About Open Source", "summary": "Open {re}Source creates a Bluesky starter pack about open source", "content_html": "Bluesky released starter packs on June 26, 2024. They are personalized invites that allow users to bring people directly into your slice of Bluesky!
\nBluesky, the decentralized social media platform, introduced starter packs on June 26, 2024, aiming to personalize user experiences and make it easier for communities to grow. They let users bring friends directly into their customized Bluesky environment.
\nA Bluesky starter pack can include the following:
\nAs of September 2026:
\nYou can count on us! The Open {re}Source team is excited to introduce our very own Bluesky starter pack focused on open source! 🚀
\nWe followed the tutorial provided by Bluesky in their blog post, but even without the tutorial, it is quite easy and intuitive to create a starter pack from the interface.
\nBelow is the link to our open source Bluesky starter pack:
\n\nIt contains accounts and individuals linked to the open-source world, as well as the Open Source feed we created for Bluesky.
\nWe hope you enjoy our starter pack! 🎉
\nDon’t hesitate to share your feedback with us on Bluesky, suggest new accounts to follow, or even create your own starter pack and share it with us! 🙌
\nFind this Bluesky profile widget cool? Check this out:
\n![\"\"](\"https://avatars.githubusercontent.com/u/30949385?v=4&s=96\")
saurabhdaware/Bluesky’s starter packs are an excellent way to foster community and personalize your social media experience. The Open {re}Source Bluesky starter pack is designed to connect you with the open-source community on Bluesky. Join us, and let’s continue to build and share together!
\nFeel free to reach out with any questions or suggestions. Happy Blueskying! 🚀
", "date_published": "2024-07-01T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Bluesky", "Social Media", "Tools" ] }, { "id": "https://openresource.dev/articles/github-ghost-user/", "url": "https://openresource.dev/articles/github-ghost-user/", "title": "Who Is the Ghost User on GitHub?", "summary": "Learn who is the ghost user on GitHub and why it can appear in some issues, discussions, or pull requests.", "content_html": "This morning, I woke up to a storm of 200+ GitHub notifications. My inbox, usually pristine, was drowning in a deluge of spams.
\nAs I scrolled through, my screen filled with an overwhelming array of spam discussions.
\n\n\nOK, cool, we are being productive today! 200+ GitHub discussions to delete!
\nWe can’t see it in the screenshots, but there were several authors of the discussions, or answering to the discussions. I couldn’t block them for this specific repository as I am not the owner of the repository, but I could report them. So, one by one, I started to delete the discussions and report the users without looking at their profile.
\nThe usual process happened on GitHub side, except for one user: ghost!
\nThe GitHub Developer Support answered:
\n\n\n“The ghost username is in place to designate accounts that have been deleted by their owners, but that still have content that is visible across the GitHub platform.”
\n
Oops!
\nIndeed, I didn’t check the GitHub profile of the user before reporting it, and it is pretty obvious when you are looking at it:
\n![\"\"](\"https://avatars.githubusercontent.com/u/10137?s=96\")
ghostHi, I'm @ghost! I take the place of user accounts that have been deleted. 👻\nThe ghost user is a placeholder account used by GitHub to manage contributions and commits from users who have been deleted or whose accounts are no longer active. So it is not a spam account, and not especially an account to report. 😅
\nWhen a user is deleted from GitHub, their contributions, such as commits, issues, and comments, are not erased. Instead, these contributions are attributed to the Ghost user to maintain the integrity and history of the repository.
\nThe primary purpose of the ghost user is to preserve the history and context of projects.
\nIt helps with maintaining repository integrity. When a user is deleted, removing their contributions would disrupt the continuity and understanding of the project. By attributing these contributions to the ghost user, GitHub ensures that the project’s history remains intact.
\nIt also helps with contextual continuity. Comments on issues and pull requests often provide valuable insights and discussions. Reassigning these to the ghost user ensures that future contributors can still benefit from these historical discussions.
\nYou might see the ghost user when a GitHub user decides to delete their account, all their contributions are transferred to the Ghost user.
\nIt can also happen when GitHub removes an account due to policy violations or other reasons. In this case, the contributions are reassigned to the Ghost user.
\nYou can even follow it: 13k people do (as of September 2026). 😅
", "date_published": "2024-05-18T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "GitHub" ] }, { "id": "https://openresource.dev/articles/contrib-rocks/", "url": "https://openresource.dev/articles/contrib-rocks/", "title": "contrib.rocks: Generate an Image of GitHub Repositories Top Contributors", "summary": "contrib.rocks generates an image of GitHub repositories top contributors.", "content_html": "contrib.rocks is a an online tool that generates an image of the top contributors of a GitHub repository that can be embedded in any website or Markdown file; including its README file.
\nIt is completely free and maintained by Suguru Inatomi, a.k.a. lacolaco. The source code is available on GitHub:
\n![\"\"](\"https://avatars.githubusercontent.com/u/1529180?v=4&s=96\")
lacolaco/This service allows to give a visual representation of the top contributors of any GitHub repository.
\nGenerating such an image of your GitHub repository top contributors can be a great way to show the activity of your GitHub repository and encourage people to contribute, but also to celebrate your top contributors.
\nUsage is pretty straightforward:
\n![\"Go](\"https://openresource.dev/images/bluesky-starter-pack.png\")
![\"A](\"https://openresource.dev/images/github-ghost-user-1.webp\")
![\"A](\"https://openresource.dev/images/github-ghost-user-2.webp\")
open-reSource/openresource.dev)And that’s it! You will get the image representing the top contributors of the GitHub repository you entered.
\nThen, you can click on the “Get Image URL!” button to get the Markdown code to embed the image in your README file for instance.
\n<a href="https://github.com/open-reSource/openresource.dev/graphs/contributors">\n <img src="https://contrib.rocks/image?repo=open-reSource/openresource.dev" />\n</a>\n\nMade with [contrib.rocks](https://contrib.rocks).You will notice that the first part of the generated Markdown code is in reality HTML code. You can use this HTML code to embed the image in any website or Markdown file.
\nHere is what it looks like for our openresource.dev GitHub repository:
\nMade with contrib.rocks.
\nAnd here is the same rendering, but on a more active repository like godot:
\n![\"\"](\"https://avatars.githubusercontent.com/u/6318500?v=4&s=96\")
godotengine/Made with contrib.rocks.
\nSome parameters can be added to the URL to customize the image:
\nmax={number}: Max contributor count (100 by default)columns={number}: Max columns (12 by default)anon={0|1}: Include anonymous users (false by default)So if we add &max=10&columns=2 to the image URL https://contrib.rocks/image?repo=godotengine/godot we get the following image with only the top 10 contributors and 2 columns:
<a href="https://github.com/godotengine/godot/graphs/contributors">\n <img src="https://contrib.rocks/image?repo=godotengine/godot&max=10&columns=2" />\n</a>\n\nMade with [contrib.rocks](https://contrib.rocks).Made with contrib.rocks.
", "date_published": "2024-04-27T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "GitHub", "Markdown", "Readme", "Tools" ] }, { "id": "https://openresource.dev/articles/repobeats/", "url": "https://openresource.dev/articles/repobeats/", "title": "Repobeats: GitHub README analytics", "summary": "Repobeats is a tool that provides analytics for your GitHub README files.", "content_html": "Repobeats is a tool that provides analytics of a GitHub repository that can be embedded in any Markdown file; including its README file.
\nIt is completely free and maintained by axiom.com, but does not seem to be an open-source project as it is not referenced in github.com/axiomhq.
\nThis service allows to give a visual representation of the activity of your GitHub repository:
\nIt can be a great way to show the activity of your GitHub repository and encourage people to contribute, but also to celebrate your top contributors.
\nBehind the scene, Repobeats uses public data available on GitHub.
\nInstalling Repobeats requires a GitHub account.
\n\n\n[!WARNING]\nPlease consult their Frequently Asked Questions for more information before installing it. They explain for example how they use your email address.
\n
To install Repobeats, it is pretty straightforward:
\nAnd that’s it! You will get a URL like ours that you can use in your README file or any Markdown file:
\n// Add the following to your README.md to embed Repobeats\nHere is what it looks like for our openresource.dev GitHub repository:
\n![\"Repobeats](\"https://repobeats.axiom.co/api/embed/da1c940f0135aece8b9942f518b44dacc39bd9ce.svg\" "\\"Repobeats")
And here is the same kind of data, but on a more active repository like freeCodeCamp:
\n![\"\"](\"https://avatars.githubusercontent.com/u/9892522?v=4&s=96\")
freeCodeCamp/![\"Repobeats](\"https://repobeats.axiom.co/api/embed/89be0a1a1c8f641c54f9234a7423e7755352c746.svg\" "\\"Repobeats")
freeCodeCamp is using it in the “Contributing” section of their README file and it looks great!
\nWe can see right away that this repository is very active with a lot of contributions, issues, PRs, and commits.
", "date_published": "2024-04-02T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "GitHub", "Markdown", "Readme", "Tools" ] }, { "id": "https://openresource.dev/articles/github-marketplace-social-preview-for-your-github-actions/", "url": "https://openresource.dev/articles/github-marketplace-social-preview-for-your-github-actions/", "title": "GitHub Marketplace: Social Preview for Your GitHub Actions", "summary": "Learn how to create and add a social preview image to your GitHub repository to have a better rendering when sharing on social media platforms the link of your GitHub Actions on the GitHub Marketplace.", "content_html": "You are finally ready to share your GitHub Action with the world. You have spent hours working on it, and now it is time to show it off. You open your favorite social media platform, start typing your post, link your GitHub Action on the GitHub Marketplace, click on send, and… your big face is on people’s screen!
\n\nThis is what happened to me when I shared the marketplace link of my GitHub Action named “Update Issue Body”.
\nTo be fair, the rendering is different and way better if one shares a link to the GitHub Action repository itself.
\n\nIt is possible to add a social preview image to your GitHub repository. This image will be used when you share the link to your repository on social media platforms. But this image will also be used when you share the link to your GitHub Action on the GitHub Marketplace!
\nIt is rather easy to do as everything is explained directly in the GitHub documentation Customizing your repository’s social media preview.
\nAt the times of writing, images are recommended to be 1280x640px for best display on high-resolution devices.
\nWhile not visible in the documentation itself, GitHub provides in the settings of your repository a template for the social preview image which is pretty handy to get started and to have the safe zones.
\n\nI am not a designer, so I used the template to create my social preview image which has the following rendering:
\n\nAfter having uploaded the image to your repository, you can check if it works by using online tools like opengraph.xyz.
\nWhether you use the marketplace link or the repository link, you should see the social preview image.
\n\nBased on this rendering, I have created a reusable Figma template named “GitHub Actions and Repo Social Previews” that you can use to create your own social preview image.
", "date_published": "2023-09-15T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Communication", "GitHub", "GitHub Actions" ] }, { "id": "https://openresource.dev/articles/display-your-sponsors-in-your-github-readmes/", "url": "https://openresource.dev/articles/display-your-sponsors-in-your-github-readmes/", "title": "Display Your Sponsors in Your GitHub READMEs", "summary": "Learn how to display the list of your sponsors in your GitHub READMEs thanks to SponsorKit and GitHub Actions.", "content_html": "A simple nice way to reward your sponsors could be to showcase them in the projects you create on GitHub. And what a better place to do that than in your READMEs? This article will show you how to do that easily!
\nThere are several ways to display your sponsors in your GitHub READMEs, but this article will focus on a single one by using SponsorKit created by Anthony Fu.
\n![\"\"](\"https://avatars.githubusercontent.com/u/167634566?v=4&s=96\")
antfu/SponsorKit is a toolkit for generating sponsors images that supports GitHub Sponsors, Open Collective, Patreon, and Afdian.
\nHere’s how Anthony uses it himself in antfu/unplugin-auto-import README.
\nLet’s do our own sponsors image showcasing our GitHub sponsors!
\nBefore starting, you will need to have a GitHub account and have at least one sponsor.
\nThen, you will need to create a new GitHub personal access token (classic) with the read:org, and read:user scopes that you can name whatever you want, and keep its value somewhere for the next steps of this tutorial.
You can find more information about how to create a GitHub token in the GitHub documentation.
\nIn order to facilitate the process, we have created for you a template repository that you can use to create your own repository: https://github.com/Open-reSource/sponsorkit-starter.
\nOpen-reSource/You can click on the “Use this template” button to create your own repository.
\nThen, you will need to fill the form with the name of your repository, a description, and choose if you want to make it public or private. Click on the “Create repository from template” button to create your repository.
\nIt will launch a GitHub Action that will fail, but don’t worry, we will fix that in the next steps.
\nIt is also possible to create your repository from scratch, clone it locally, and then running the following command:
\n![\"The](\"https://openresource.dev/images/github-marketplace-social-preview-for-your-github-actions-1.png\")
![\"The](\"https://openresource.dev/images/github-marketplace-social-preview-for-your-github-actions-2.png\")
![\"Repo](\"https://openresource.dev/images/github-marketplace-social-preview-for-your-github-actions-3.png\")
![\"My](\"https://openresource.dev/images/github-marketplace-social-preview-for-your-github-actions-4.png\")
![\"opengraph.xyz](\"https://openresource.dev/images/github-marketplace-social-preview-for-your-github-actions-5.png\")
npx degit Open-reSource/sponsorkit-starterYour new repository is now created, and should contain the following files:
\n.github/workflows/scheduler.yml that runs the SponsorKit action on a schedule every day, for each merge on the main branch, or manually..env.example as described in SponsorKit usage.build.sh script to generate the sponsors images.package.json relying on the latest version of SponsorKit and containing the build script.sponsor.config.ts that contains the configuration for the generation of the sponsors images.First important thing to do is to change the default permissions of the GITHUB_TOKEN that is used by the GitHub Action to commit and push the generated sponsors images.
It can be changed by going to your repository settings, then to the “Actions” section, and choose “Read and write permissions” for the “Workflow permissions” option.
\nYou can find more information about this configuration in the GitHub documentation.
\nBy looking at .github/workflows/scheduler.yml, we can see that it relies on a ${{ secrets.SPONSORS_TOKEN }} environment variable.
We will need to set it up in the GitHub repository settings with “SPONSORS_TOKEN” as a name, and with the value of the GitHub personal access token that we have created in the prerequisites.
\nYou can find more information about how to create a new repository secret in the GitHub documentation.
\nEither after having cloned your repository locally, or directly on GitHub, you will need to edit the .github/workflows/scheduler.yml to indicate your GitHub username as a value for “SPONSORKIT_GITHUB_LOGIN”.
Commit and push your changes.
\nThis latter change will trigger the GitHub Action that will generate your sponsors images, commit, and push them at the root level of your repository with the message ” chore: update sponsors.svg”.
\nFor example, you can see the generated sponsors images of the julien-deramond/static repository created from this same template.
\nIt might be useful to know, even if rarely useful, it is also possible to run it locally.
You will need to install the dependencies by running npm i in your terminal.
Then, copy .env.example to .env still at the root level of your repository with the following content:
; GitHub provider.\n; Token requires the `read:user` and `read:org` scopes.\nSPONSORKIT_GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx\nSPONSORKIT_GITHUB_LOGIN=usernameSPONSORKIT_GITHUB_TOKEN is the GitHub token you created earlier.SPONSORKIT_GITHUB_LOGIN is your GitHub username.The final step is to run npm run build in your terminal to generate the static files:
ju ߷ ~/j/static ➤ (main) npm run build \t(0.060674 hrs)\n \t17:48:16\nSponsorKit v0.8.3\n\n✔ Loaded from cache ./.cache.json \t17:48:16\n✔ Wrote to ./sponsors.json \t17:48:16\nℹ Composing SVG... \t17:48:16\n✔ Wrote to ./sponsors.svg \t17:48:16\n✔ Wrote to ./sponsors.png \t17:48:16\n \t17:48:17\nSponsorKit v0.8.3\n\n✔ Loaded from cache ./.cache.json \t17:48:17\n✔ Wrote to ./sponsors.wide.json \t17:48:17\nℹ Composing SVG... \t17:48:17\n✔ Wrote to ./sponsors.wide.svg \t17:48:17\n✔ Wrote to ./sponsors.wide.png \t17:48:17\n \t17:48:17\nSponsorKit v0.8.3\n\n✔ Loaded from cache ./.cache.json \t17:48:17\n✔ Wrote to ./sponsors.part1.json \t17:48:17\nℹ Composing SVG... \t17:48:17\n✔ Wrote to ./sponsors.part1.svg \t17:48:17\n✔ Wrote to ./sponsors.part1.png \t17:48:18\n \t17:48:18\nSponsorKit v0.8.3\n\n✔ Loaded from cache ./.cache.json \t17:48:18\n✔ Wrote to ./sponsors.part2.json \t17:48:18\nℹ Composing SVG... \t17:48:18\n✔ Wrote to ./sponsors.part2.svg \t17:48:18\n✔ Wrote to ./sponsors.part2.pngAll the images are now generated at the root level of your repository. You can check them out in your file explorer.
Warning: Once it’s done, please don’t forget to remove at some point your GitHub token from the .env file for security reasons. You won’t probably never re-run it from your local machine.
Now that the GitHub Action has run, you can use the generated images in your READMEs.
\nFor example, you can use the sponsors.svg image in your README.md file by adding the following code. Don’t forget to replace username by your GitHub username in the link’s href, link’s aria-label, and image’s src attributes.
<p align="center">\n\t<a href="https://github.com/sponsors/username/" aria-label="Go to username's sponsors page">\n\t\t<img src="https://cdn.jsdelivr.net/gh/username/static/sponsors.svg" />\n\t</a>\n</p>Warning: GitHub can take a while to render the image in your README. If you don’t see it, wait and refresh the page. On my side, it took around 10 minutes to be displayed. As long as the https://cdn.jsdelivr.net/gh/username/static/sponsors.svg URL is showing the image, don’t worry, it will be displayed in your README soon.
You can check my own personal sponsors list generated by following this article:
\n\nAnd find it integrated in one of my projects: https://github.com/julien-deramond/update-issue-body#sponsors.
", "date_published": "2023-05-18T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "GitHub", "Sponsors", "Tutorial" ] }, { "id": "https://openresource.dev/articles/can-i-take-this-issue/", "url": "https://openresource.dev/articles/can-i-take-this-issue/", "title": "Can I Take This Issue?", "summary": "Learn about the frustration caused by issue assignments in open-source software development and how to tackle it. Get insights here.", "content_html": "Open-source software development is a collaborative effort that relies on volunteers to contribute to the project. Contributors have different skill levels and come from various backgrounds. As such, project maintainers make sure that the contributions received are of high quality and meet the project’s goals. One way maintainers do this is by providing clear guidelines on how contributors can submit their work. Unfortunately, contributors don’t always take the time to read these guidelines, and maintainers don’t always assign issues, which can lead to confusion and frustration on both sides.
\nHey! Can I take this issue?
Hello! As mentioned in our contributing guidelines, we do not assign\nissues in this repository. However, if you’d like to contribute a solution, feel free to create a PR directly. Thank\nyou for your interest!
OK thanks!
This is a common scenario in open-source projects. A contributor sees an issue that they think they can solve, so they ask if they can take it.
\nSeriously, again… What do I usually answer? Hmmm…
If you are the maintainer of this open-source project, you start by receiving a notification. You then go to the issue and take the time to respond to the contributor something you may have already said ten times this week. You then go back to your work, and receive another notification from the same contributor saying basically “OK thanks!”.
\nSeriously? I have already checked the issue, I have the solution!!! They don’t trust me. They think I’m not good\nenough, they don’t deserve my contribution…
If you are the contributor, you may feel frustrated. You may have spent time looking for an issue to work on, and you may have even started working on it. You then ask if you can take it, and the maintainer responds by saying that they don’t assign issues. You then feel discouraged and decide not to contribute to the project.
\n\nThis is a frustrating experience for both the contributor and the maintainer.
\nThe contributor is left wondering if they can actually work on the issue, and the maintainer is left wondering why the contributor didn’t read the contributing guidelines.
\nMaintaining an open-source project is a challenging task that involves multiple responsibilities. One of them is managing issues reported by contributors or users. Assigning issues to specific maintainers or contributors is a common practice that can help ensure that problems are addressed in a timely and efficient manner and that contributions align with the project’s vision and goals. However, not all maintainers assign issues, or they may only assign a small number of them.
\nAssigning issues to specific individuals helps ensure that they are addressed promptly and efficiently, reducing the likelihood of issues being overlooked or forgotten. It allows maintainers to manage issues more efficiently, ensuring they are resolved in a timely and effective manner. However, the assignee can still benefit from the feedback of the community and maintainers, and this approach is particularly useful for larger projects that receive many issues.
\nAssigning issues can help to clarify the responsibilities of different contributors and maintainers. It’s clear who is responsible for resolving an issue when it’s assigned to a specific person. This can reduce confusion and ensure that issues are addressed by the right people. In larger projects, where multiple contributors and maintainers may be working simultaneously.
\nAssigning issues can also create a clear sense of accountability and responsibility. When an issue is assigned to a specific person, they become responsible for resolving it. This accountability can motivate contributors and maintainers to take ownership of the issue and work towards a solution. When contributors know that they are responsible for resolving an issue, they are more likely to focus their efforts on finding a solution. This sense of ownership can also lead to a more engaged and invested community.
\nAssigning issues to specific contributors can foster community involvement and collaboration. Assignees have a clear understanding of what needs to be done, leading to increased contributions and a more active community. Additionally, assigning issues can encourage collaboration between contributors and maintainers, leading to more efficient issue resolution and a stronger sense of community.
\nTo address unassigned contributions, both contributors and maintainers need to work together.
\nContributors can help by taking the time to read the project’s contribution guidelines carefully. They should also review the issue tracker and try to find issues that align with their skills and interests. If an issue is not assigned, contributors can reach out to maintainers or community managers for guidance.
\nMaintainers can also take steps to address unassigned contributions. One way is to review the issue tracker regularly and assign issues promptly. They can also update the contribution guidelines and make them more visible to ensure that contributors are aware of them. Maintainers can also provide feedback on contributions, highlighting areas for improvement and encouraging contributors to continue their work.
\nAssigning issues can also help to manage resources more effectively.
\nBy assigning issues to specific contributors or maintainers, the workload can be distributed more evenly. It also helps prevent duplicated work, as contributors can see what others are working on and avoid duplicating their efforts.
\nAssigning issues can also help maintainers to manage their workload. By assigning issues to specific people, maintainers can ensure that they are not overwhelmed with too many tasks at once.
\nThis approach can help to prevent burnout and ensure that contributors and maintainers are working on issues that are within their skill level and expertise. It can ensure that maintainers’ time and energy are focused on the issues that matter most.
\nAssigning issues can also help to avoid confusion. When multiple people are working on the same issue, it can be difficult to know who is responsible for what. By assigning issues to specific people, maintainers can ensure that everyone knows what they are responsible for and what their role is in addressing the issue.
\nDespite the benefits of assigning issues, there are also some challenges that maintainers may face. So there are some maintainers who choose not to assign issues, quite a lot in fact. This lack of assignment can result in contributors not knowing what to work on or feeling discouraged about contributing to the project.
\nMaintaining an open-source project can be a daunting task, and the responsibility is often shouldered by a handful of maintainers. These maintainers are responsible for reviewing contributions, triaging issues, and coordinating with contributors to ensure the project’s growth and success. However, due to limited resources, some maintainers may not be able to assign issues effectively, which can lead to frustration among contributors and a decline in the project’s growth.
\nMaintaining an open-source project requires a significant amount of time and effort, and it can be a voluntary and unpaid job for many maintainers. As such, they may not have the financial resources or personnel to manage every issue that is reported.
\nAssigning an issue without proper analysis and discussion is inadequate and can impede its development. This is especially true for issues coming from the community, as they may lack sufficient details. Prioritizing, analyzing, and discussing the issue is necessary before assigning it to a maintainer or contributor for resolution. Assigning issues to specific people requires time and effort, and some maintainers may prefer to focus their attention on other aspects of the project, such as code review or documentation. Furthermore, some maintainers may be juggling multiple projects or other commitments in their personal and professional lives, which can limit their ability to assign issues.
\nThey are often already too busy reviewing contributions. Open-source projects are often community-driven, and they can receive a large number of contributions, especially when they gain traction. Each contribution requires review, testing, and integration, which can be time-consuming, especially for maintainers who have other responsibilities. In such cases, maintaining the project can become a daunting task, and maintainers may be unable to keep up with the influx of contributions, leading to a backlog of unassigned issues and sometimes even unassigned pull requests.
\nThe issue tracker can become overwhelming, making it difficult to assign issues to the right people. The issue tracker serves as a central hub for the project’s issues, feature requests, and pull requests. As the project grows, the number of issues and pull requests can quickly pile up, leading to confusion on the part of contributors. Without proper triaging and assignment, contributors may not know what to work on or feel discouraged about contributing to the project, resulting in a decline in contributions.
\nAs the community expands or is already large, maintainers may struggle to keep track of all its members and their capabilities. In such cases, assigning issues can become a daunting task, as maintainers may be uncertain of the skill level and commitment of potential contributors. Junior developers and new open source members may be attracted to issues in already popular projects, seeking mentorship and opportunities to contribute, but this can overwhelm maintainers who cannot mentor everyone or have limited resources for reviewing contributions.
\nTo assign issues appropriately, maintainers may need to review past contributions, evaluate code quality, and reach out to potential contributors to discuss their interest in the project. However, this can be a time-consuming process, leading some maintainers to avoid assigning issues altogether. This can create a backlog of issues that go unaddressed, causing frustration among contributors.
\nAnd this approach can backfire, as it can create a backlog of issues that are not being addressed, which can cause frustration among contributors. In such cases, establish clear guidelines for issue assignment and ensure that all members of the community are aware of them.
\nSome maintainers believe that assigning issues can create silos and discourage collaboration. They may prefer to have an open forum where anyone can contribute to resolving issues. This approach allows the community to work together and share knowledge and expertise. They encourage contributors to take ownership of the project and work together to resolve issues, rather than relying on a single maintainer to manage all aspects of the project.
\nWhile this approach can be effective, it can also result in a lack of direction and oversight. Without clear guidance or leadership, contributors may not know what to work on or how to approach a particular issue.
\nTo address this, maintainers can provide clear documentation on the project goals and how to get involved. Additionally, they can establish communication channels for contributors to ask questions or provide feedback, or even encourage contributors to work in pairs or small groups to resolve issues. Another potential solution is to use a rotating ownership model, where issues are assigned to a specific contributor for a set period of time, after which ownership of the issue rotates to another contributor. This approach allows for individual ownership of issues while still promoting collaboration and knowledge-sharing.
\nBy doing so, maintainers can foster a collaborative environment while still maintaining some level of oversight and direction.
\nAssigning issues can also lead to accusations of favoritism or bias. Some maintainers may choose not to assign issues to avoid any perception of preferential treatment. By allowing anyone to work on any issue, maintainers can ensure that everyone has an equal opportunity to contribute. This approach can help to create a more inclusive and welcoming community, where all contributors are valued and respected.
\nHowever, this approach can also result in confusion and duplication of effort. If multiple contributors are working on the same issue, it can lead to wasted time and resources.
\nOne way to ensure that everyone has a fair opportunity to contribute to a project is through establishing clear guidelines and protocols for contribution. For instance, the project can have a clearly defined process for claiming issues, stating who is responsible for which tasks, and how contributors can go about resolving issues. This approach allows contributors to work together in a coordinated fashion and avoid duplication of effort. In some cases, it may even foster a sense of friendly competition amongst contributors, which can help to drive innovation and progress.
\nThey can also provide feedback on contributions to ensure that everyone is working towards the same goal, thus minimizing duplication of effort and confusion.
\nAnother reason why some maintainers do not assign issues is that they trust the community to self-organize and take ownership of issues without assigning them to specific individuals. This approach is based on the belief that a highly engaged and motivated community will work together to resolve issues and prioritize tasks. It can be an effective approach in projects with a large and active community where multiple contributors can work on the same issue simultaneously.
\nWhen maintainers trust the community to self-organize, they can focus on other aspects of the project such as developing new features, maintaining documentation, or mentoring new contributors. This approach can also be useful in situations where maintainers have limited resources or are unable to keep up with the volume of incoming issues. By allowing the community to take ownership of the project, maintainers can create a sense of ownership and belonging within the community, leading to increased participation and collaboration.
\nHowever, relying solely on the community to self-organize can also have its drawbacks. Without clear guidance or leadership, contributors may not know how to prioritize tasks or resolve issues effectively. Sometimes, the issues are not yet read by the maintainers and contributors start the development of something useless which is not what the maintainers want. This can result in duplication of effort, wasted time and resources, and may lead to frustration and disengagement among contributors.
\nTo address these issues, maintainers can establish clear guidelines on how to claim an issue and work on it. They can also provide feedback on contributions to ensure that everyone is working towards the same goal. Additionally, maintaining open communication channels for contributors to ask questions or provide feedback can help foster a collaborative environment while still maintaining some level of oversight and direction.
\nWe may tend to forget it but not all the maintainers know everything about open source so some maintainers may “choose” not to assign issues simply because they are not familiar with the process. Assigning issues can be a complex task, especially in large projects with many contributors. If a maintainer is not comfortable with the process, they may choose to avoid it altogether. Additionally, some maintainers may be new to the project and may not yet have a good understanding of the various roles and responsibilities. This can make it difficult to assign issues to the appropriate parties.
\nIn this case, this article may be a good starting point 🙂
\nAn open-source project can be maintained by a core team working full-time, often linked to a company. Then, issues assignments may be handled differently than in other open-source projects. Indeed, they can rely on a specific agenda and deadlines, so they may assign issues to ensure accountability, clear ownership, prioritization, expertise, and consistency. At the same time, the core team may also allow external contributors to contribute to the project for diverse perspectives, community building, increased productivity, and learning opportunities. In that case, they could not assign issues to external contributors. Here comes our hybrid approach.
\nAs an external contributor, you won’t probably be assigned to an issue for several reasons:
\nHowever, it might happen, depending on their contributing guidelines, for unprioritized issues that don’t have any deadline yet. Most repositories use a dedicated label in this case to let know outsiders that they can help and contribute. And of course, they will probably be happy to review code not related to already planned issues or fixes.
\nBy allowing external contributions to the project, the core team might benefit from:
\nNot assigning issues is a choice made by the maintainers based on several criteria as seen in the previous sections.
\nTo counter-balance the fact that issues are not assigned, projects often rely on a strong issues workflow with a powerful system of labeling and triage to help identify the complexity of the tasks, the status of the analysis, whether the issue is ready to develop or not, the target versions, the scope, etc. so that the community can be autonomous, but also to reduce the noise for the maintainers who have most of the time really limited resources.
\nThis full backlog can be accompanied by a schema representing the whole workflow of states of issues and sometimes even pull requests, the actors, etc. It can be linked to a roadmap.
\nTo make the most of their limited resources, maintainers can set up automatic triage systems that categorize and prioritize issues based on their severity or complexity so that the community can be autonomous and evaluate where they could be helpful depending on their level and expertise. High-priority or high-complexity issues can be tackled by experienced contributors or reserved for the core team while low-priority or low-complexity might be left for the new contributors to help them gain experience.
\nAdditionally, maintainers can reach out to the community to encourage contributions and provide guidance on how to best help with the project so that the whole process runs smoothly. By doing so, maintainers can ensure that they are making the most of their limited resources, while also making it easier for contributors to get involved.
\nLabeling is very powerful as it can filter the backlog by elements but also be used for automation in projects.
\nEverything can start from the creation of these issues with the issues templates to guide contributors in providing the necessary information when they create an issue. This can include a checklist of requirements that need to be met before an issue can be treated, such as providing a clear description of the problem, steps to reproduce, any relevant logs or errors messages, or motivation if this is a new feature.
\n\n\n\n[!TIP]\nWhen you don’t assign issues in your repository, it can be reminded at the end of the issues!
\n
As of September 2026, GitHub doesn’t provide any options to add some Markdown content at the end of the issues when using issue templates: the markdown elements of an issue form are shown to the author but not submitted. However, you can use GitHub Actions to do that. Here is an example of a GitHub Action that adds a message for newly created issues:
Open-reSource/An infinite way of managing labels is possible. Let’s imagine, for example, a to analyze label that can be picked up only by a core team member. When this core team member analyzed the issue and provided expectations, clarity, and guidance, the label could be transformed into an analyzed label, and a new ready for dev label could be applied combined to high priority and low complexity labels, and a version 12 label, bug or feature, core team if it is reserved for the core team, or pr welcome when it is OK for external contributors to work on it. When doing that, contributors can start to help or not, filter the backlog by labels, and the core team can focus on the most important issues. If the workflow is automated, the issue can go to one or another project, be in a roadmap, etc. This is just an example, but you can imagine how powerful it can be.
\nBy establishing clear communication channels, maintainers can provide guidance to contributors and answer any questions they may have about the assignment process and issues workflow. This can also help build trust and foster a sense of community among contributors, which can lead to greater collaboration and more successful outcomes.
\nBy taking the time to establish clear guidelines and protocols for issues assignment and maintaining open communication with contributors, maintainers can help ensure that each issue is addressed by the most qualified contributor, leading to more successful outcomes for the project as a whole.
\nWhether maintainers put in place a simple or advanced workflow, it must be clearly explained somewhere. Depending on the amount of information, it can be directly in the Contributing Guidelines or in a Wiki, documentation, etc. linked from the Contributing Guidelines.
\n\nIf issues are assigned, make sure that it’s clearly explained in the Contributing Guidelines.
\n\nIf issues are not assigned, make sure that it’s clearly explained in the Contributing Guidelines.
\nYes, it is important for open-source projects to have Contributing Guidelines to provide critical information about the project, including its goals, coding standards, how to submit changes, how to ask for help, and how to get involved in the community.
\nThis is also the place where are explained how contributors can report issues and how maintainers will manage them. The guidelines should include information on whether issues will be assigned or left unassigned, and why. This will help to set expectations for both contributors and maintainers and ensure that everyone is on the same page.
\nIf an open-source project is maintained by a core team working for a company, the contribution guidelines should make it clear that issues will be managed by the core team and may or may not be assigned to individual team members. The guidelines should also explain the reasons behind this approach, such as the need to ensure that issues are addressed in a timely and efficient manner, and the fact that the core team has the expertise and resources to manage the project effectively.
\nIf an open-source project is maintained by a community of volunteers, the contribution guidelines should explain how issues will be managed and whether they will be assigned or left unassigned. The guidelines should also provide guidance on how contributors can help to manage the issue tracker, such as by reviewing and triaging issues, and how they can get involved in the project’s decision-making process.
\nRegardless of the approach taken by an open-source project, it’s important to have clear and transparent contribution guidelines that set expectations for both contributors and maintainers. This will help to ensure that the project is sustainable and that issues are addressed in a timely and efficient manner.\nOn top of explaining what is the process, it is also interesting to explain why this choice has been made by the maintainers. It will help contributors who will read the contributing guidelines, but can also be useful to remind this rule for those who don’t read the contributing guidelines. It happens sometimes, doesn’t it? ;)
\nFirst of all, contributors may not even know their existence. Always remind that each day, there are newcomers in the open source world who don’t know how it works. But let’s be honest, apart if the Contributing Guidelines are not at the right place, contributors don’t always take the time to read them because they may be in a hurry to start working on the project, or because they assume that their previous experience will suffice.
\nSo the frustration of maintainers can be understood rather easily, especially if they spent time writing down a thorough explanation of why the repository doesn’t assign issues. Reminding days after days for years that the repository doesn’t assign issues feels like repeating over and over the same thing. But always remind that you are not talking to the same person who has a different background regarding OSS and probably does not have the same expertise as you in the field.
\nStreamers, for example, use pre-defined messages, videos, or FAQs in order not to repeat the same information to the newcomers (who almost always ask the same things based on the streamer’s point of view) so that they are not bothered when they are streaming, and the viewers can still have the information. Having tools answering for you, either semi-automatic or automatic, will help not become angry at contributors after repeating the same thing over and over.
\nIn a nutshell:
\nOverall, the key is to be patient, clear, and helpful in your interactions with contributors. By doing so, you can create a welcoming and productive community around your open-source project
\nOverall, by using a combination of manual, semi-automatic, and automatic tools, maintainers can help to manage the influx of questions from contributors who are unsure about taking up an issue. This can help to ensure that contributors are able to contribute effectively and that maintainers can focus on other aspects of the project.
\nThere are several manual and automatic tools that maintainers can use to help handle these questions and politely refuse them by mentioning the contribution guidelines.
\nDirect communication is not really a tool, but this is often the way it is handled by maintainers. They can engage with contributors who are unsure about taking up an issue, write down a specific personalized message, help clarify any confusion and ensure that contributors feel supported to contribute in the right way, and even provide alternative issues or areas of the project where the contributor can help. But it takes a huge amount of time, especially in a big community, and the content can be inconsistent.
\nIn most of the Git source code platforms, it is possible to set up saved replies:
\n\nIt is only a semi-automatic tool but it can help save a lot of time by not repeating over and over the same thing. Maintainers will lose the personalized side but will gain consistency with a clear and precise answer accompanied by links pointing to unique resources.
\nIf you are maintaining OSS projects or communities on different platforms, you may opt for decentralized messages and actions stored in your own environment for transversal usage. Tools like Alfred on macOS could be used in this spirit.
\nWriting this article was the occasion to try creating a semi-automation tool based on labels. Maintainer can add a we don’t assign issues label to an issue right after a comment asking to be assigned. This label will trigger a GitHub action that will write a personalized comment explaining that the repo is not handled that way, and then remove this label automatically. We could even hide the original contributor’s comment in the process.
\n\nThe source code of this experiment is available on GitHub via the card below.
\nOpen-reSource/Unfortunately, if there are intermediate comments before maintainers have the time to use this label, it won’t work. And it stays semi-automatic.
\nThis was a nice experiment, but can we go further with full automation? Actions can already be triggered when a comment is created or updated, it would only be a matter of time to create a bot that would be able to answer automatically to the contributor.
\nWe keep seeing new AI tools popping up every day in our feeds. They are pretty powerful and help automation. But so far, we haven’t had the occasion to find or test such tools for this specific use case. If you have any suggestions, or links, you can create an issue so that we can test them and improve this article. Or come talk about it on our Discord.
\nOn the contributor’s side, Finding a Project to Contribute To covers where to find an issue and how to start on it without wasting an afternoon, and Open Source Etiquette the comment to write instead of “Can I take this issue?”.
", "date_published": "2023-05-15T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Community", "Contribution" ] }, { "id": "https://openresource.dev/articles/how-to-create-a-code-of-conduct-for-an-open-source-project/", "url": "https://openresource.dev/articles/how-to-create-a-code-of-conduct-for-an-open-source-project/", "title": "How to Create a Code of Conduct for an Open-Source Project", "summary": "Build a safe and welcoming community for your open-source project with a clear code of conduct. Learn the steps, from defining goals to updating the document, to create guidelines for behavior. Start strong with our expert guidance.", "content_html": "Creating a code of conduct is a first step toward a safe and welcoming community for an open-source project. In many cases, the code of conduct may be created before the community even exists. This can be beneficial as it ensures that the project starts with clear expectations and guidelines for behavior. The process of creating a code of conduct involves several steps, including defining goals and scope, researching existing codes of conduct, drafting the document, reviewing and approving the document, publishing and communicating the code of conduct, and regularly reviewing and updating the document.
\nBy adopting a code of conduct for your open-source project, you can establish clear expectations for participant behavior, which can help foster a positive social atmosphere within your community. In turn, this can not only protect your participants, but also yourself as the project maintainer, as unproductive attitudes from participants can ultimately make you feel drained or unhappy about your work. By being proactive and enforcing a code of conduct, you can facilitate healthy and constructive behavior, which can reduce the likelihood of issues arising and make your project a more welcoming and supportive environment for all.
\nThe first step is to define the goals and scope of the project. This involves considering the project’s purpose, its intended audience, and the types of behavior that are expected from contributors and users. The goals of the code of conduct should be clear and concise and should outline the expectations for all contributors, users, maintainers, and community members.
\nDefining the goals and scope of a project is the first step in creating a code of conduct. This involves identifying the project’s purpose, intended audience, and expected behavior from contributors and users. The code of conduct should have clear and concise goals that outline the expectations for all community members, including contributors, users, and maintainers.
\nAdditionally, a code of conduct should also specify where it applies, who it applies to (including sponsors), what actions will be taken if someone violates it, and how individuals can report any violations. Considering “where it applies”, we are often thinking only about issues, pull requests, and discussions, but it can apply also to community events, social media, communication applications, etc.
\nWhether the community already exists or not, the next step is to research existing codes of conduct to identify what works and what doesn’t, but also to have a base to work on. This can be done by reviewing codes of conduct from similar projects or industries. The goal is to identify best practices and guidelines that can be incorporated into the code of conduct.
\nThe Contributor Covenant is a widely-used code of conduct to free and open-source software projects, created by Coraline Ada Ehmke in 2014. This code of conduct outlines specific behaviors that are expected from contributors, such as being respectful of differing viewpoints, avoiding offensive language, and refraining from harassment or discrimination. The goal of the Contributor Covenant is to ensure that everyone can participate in open-source projects without fear of being marginalized or excluded and to promote a culture of kindness and empathy in the tech industry.
\nIt has been adopted by thousands of open-source projects and many prominent companies including Google, Intel, GitLab, and open-source projects including Vue.js, Symfony, Bootstrap. The code outlines specific behaviors expected of contributors, such as being respectful of differing viewpoints and avoiding offensive language. In 2021, it has been included in the Organization for Ethical Source. The Contributor Covenant has played a significant role in promoting a culture of kindness and empathy within the open source community.
\nAdopting the Contributor Covenant as your code of conduct offers several benefits:
\n\n\n[!TIP] Looking to make a big impact as an open source contributor?\nTranslate or help to translate the Contributor Covenant into your non-English language. As of September 2026, version 3.0 exists in 9 languages, against 26 for version 2.1: your contribution can help make the open source community more accessible and inclusive. Visit the Contributor Covenant GitHub repository for instructions on how to get started and make a significant difference. Non-Code Contributions Maintainers Actually Want covers translating in general.
\n
There are several other well-known codes of conduct in open source, in addition to the Contributor Covenant, or based on it:
\n\n“These guidelines have been adapted with modifications from Mozilla’s original Community Participation Guidelines,\nthe Ubuntu Code of Conduct, Mozilla’s View Source Conference\nCode of Conduct, and the Rust Language Code of\nConduct, which are based on Stumptown Syndicate’s Citizen Code of\nConduct. Additional text from the\nLGBTQ in Technology Code of Conduct and the WisCon code of\nconduct. This document and all associated processes\nare only possible with the hard work of many, many Mozillians.”
These are just a few examples of the many codes of conduct that exist in the open source community. Each code of conduct may have its own unique focus and guidelines, but they all share the goal of promoting a respectful and inclusive environment for collaboration and contribution.
\nAfter gathering research and input, the code of conduct can be drafted. The code of conduct should be written in clear and concise language and should be easily understood by all members of the community.
\nIt should include guidelines on behavior, as well as consequences for violating the code of conduct.
\nSpecify the actions that will be taken if there is a violation of the code of conduct. Doing so will convey the seriousness with which you take the code of conduct, assure the community that complaints will be fairly and transparently reviewed, and demonstrate your commitment to enforcing the code of conduct. Providing a private way for people to report violations and specifying who will receive those reports matter too. Lastly, it’s important to offer an alternative option for people to report violations if they are related to someone who receives those reports.
\nOnce the code of conduct is drafted, it is important to review it with key stakeholders, including legal advisors in some cases, and any other relevant parties. These individuals could provide feedback on the code of conduct and ensure that it is legally sound.
\nOnce the code of conduct is finalized, it should be published and communicated to the community.
\nThis can be done through the:
\nIt is important to ensure that all members of the community are aware of the code of conduct and understand its expectations. But it is also important to have it available accessible by anyone and in order to link it if one must be reminded of the rules.
\nGitHub offers guidance on creating a Code of Conduct through templates available on their website. When adding a new CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file through the interface at the root level of your repository, you can select from two different templates to add to your project:
You can then complete your code of conduct by filling out a simple form with the required information.
\n\n\nAfter reviewing your changes, submit them and a CODE_OF_CONDUCT.md file will be created at the root level of your repository. You can then view a special display by visiting your repository. An example of this rendering can be seen in the GitHub Community repository.
This article may be obsolete in the future regarding some details, please check the latest version of the GitHub documentation for Adding a code of conduct to your project.
\nAdding a code of conduct in your repository is a straightforward process that works for all source code repository services, including GitHub, GitLab, BitBucket, and more. Simply create a CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file at the root level of your repository, depending on whether you prefer the Markdown or simple text format.
While GitHub provides guidance with templates, you can in fact use any code of conduct you prefer. Except for GitHub, even if most of the source code repository services do not offer a dedicated display in repositories for code of conduct files, open-source projects should still incorporate one, as it is considered a best practice. By storing it at the root level of the project, it can be easily referenced and used as a standard for appropriate behavior within the community.
\nIf you have selected the Contributor Covenant as your code of conduct, there is a neat trick to add a badge to your README.md file. You can do this by adding the following code:
\n![\"Julien](\"https://cdn.jsdelivr.net/gh/julien-deramond/static/sponsors.svg\")
![\"A](\"https://user-images.githubusercontent.com/17381666/236413271-12b7b2f2-12b1-4498-99d0-19db8b4b97d8.png\")
![\"GitHub's](\"https://openresource.dev/images/add-a-code-of-conduct-to-your-project-1.png\")
![\"The](\"https://openresource.dev/images/add-a-code-of-conduct-to-your-project-2.png\")
![\"The](\"https://openresource.dev/images/add-a-code-of-conduct-to-your-project-3.png\")
![\"The](\"https://openresource.dev/images/add-a-code-of-conduct-to-your-project-4.png\")
[](code_of_conduct.md)GitHub provides a convenient feature for reusing a code of conduct across multiple repositories by creating a default code of conduct. This default code of conduct is part of a list of default community health files, including CONTRIBUTING, FUNDING, and issue and pull request templates. Any repository owned by the account that does not have its own code of conduct file will use this default one. To set this up, you can create a .github public repository and add a CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file at the root level of the repository.
To see an example of how this works, you can take a look at our .github public GitHub repository.
This article may be obsolete in the future regarding some details, please check the latest version of the GitHub documentation for Creating a default community health file.
\nFinally, the code of conduct should be reviewed and updated regularly to ensure that it remains relevant and effective. This review process should involve the entire community and should be conducted at regular intervals, such as annually.
\nA useful tip for those using the Contributor Covenant is to subscribe to release notifications in project’s GitHub repository. This way, you can easily stay informed and be alerted when a new version of the code of conduct is released, ensuring that your project stays up-to-date.
\nIt’s rare, but in any community, there may come a time when a member violates the code of conduct. When this happens, there are several steps that moderators or maintainers can take to address the situation.
\nThe first step is to gather information about the situation. It’s important to treat each community member’s voice as important as your own and take any reports seriously. Investigate the matter even if it doesn’t match your own experience with that person. Before responding, take time to understand what happened by reading through the person’s past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
\nOnce you have gathered sufficient information, it’s important to take appropriate action. Your goal as a moderator or maintainer is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community’s behavior and expectations moving forward. Depending on the severity of the violation, you may choose to give the person in question a public warning and explain how their behavior negatively impacted others or privately reach out to the person to explain how their behavior negatively impacted others. In some cases, stronger action may be necessary, such as suspending or permanently banning the person from the project.
", "date_published": "2023-04-13T00:00:00.000Z", "date_modified": "2026-10-03T00:00:00.000Z", "tags": [ "Community", "Contribution" ] } ] }![\"Contributor](\"https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg\"){kind=icon}