# Grayhat Blog Tag: Open Source Community

> Expanded public blog context for posts tagged Open Source Community.

## Page

- [Open Source Community Tag](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/tag/open-source-community)
- [Open Source Community Tag LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/tag/open-source-community/llms.txt)
- [Root LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/llms.txt)
- [Root Full LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/llms-full.txt)
- [Tag API](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/api/public/v1/tags/open-source-community)

## Tag Details

- Slug: `open-source-community`
- Description: Not provided
- Post count in current snapshot: 3

## Current Posts

- [How to GSoC: Lessons from my open source journey](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/how-to-gsoc-lessons-from-my-open-source-journey) - From Google Summer of Code, to Grayhat.
- [Fixing a Next.js Documentation Issue](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/fixing-a-next-js-documentation-issue) - How a small bug in the MSW example led me to contribute my first merged PR to Next.js, and what it taught me about open source.
- [Secure your ship](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/secure-your-ship) - In the fast-paced world of modern web development, where tools like Vercel, Checkly, Mixpanel, and Hotjar have revolutionized workflows, it's easy to focus on the efficiency gains these platforms bring while inadvertently neglecting a critical aspect—security. As development teams expand and diversify their skill sets, the boundaries of projects expand exponentially. With more contributors, integrations, and code to manage, the attack surface grows significantly, amplifying the potential risks.


## Child Route Content

### [How to GSoC: Lessons from my open source journey](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/how-to-gsoc-lessons-from-my-open-source-journey)

- Slug: `how-to-gsoc-lessons-from-my-open-source-journey`
- Published: 2025-11-12T14:00:19.000+05:00
- Updated: 2025-11-12T14:00:19.000+05:00
- Reading time: 5 min
- Tags: Open Source, Open Source Community, Google, Google Summer of Code
- Authors: Muhammad Haroon
- Visibility: public

When I was in third year of university, I came to know about the Google Summer of Code (GSoC) program through YouTube. For those who don’t know about GSoC, it is a prestigious program (sort of an internship) which Google has conducted every year since 2005. Google selects a number of open-source organizations each year.

Contributors then submit their proposals to different projects of different organizations, and each organization accepts or rejects them based on the contributor’s past involvement and the quality of their proposal. Once accepted, one work on the project for 3 to 4 months under the guidance of assigned mentors. The goal of GSoC is to bring new contributors into open-source organizations. It really motivated me to participate mainly because I wanted to work on software that is used by millions of people, gain hands-on experience with real-world projects, have Google on my resume (which is a pretty cool thing!), and of course the stipend was a great bonus.

After my third year ended, I got a 2-month break, and I thought, *why not give it a shot?* I began exploring different organizations in July 2024, and I found this website extremely helpful. It provided all the essential details about each organization including how many times the organization participated and in which years, the tech stack of that particular organization, and past selected contributors. Overall, it offered a comprehensive overview of each organization.

💡****Tip:**** Choose the organization which has participated in GSoC for multiple years. It’ll have a high chance of coming again in the upcoming year and will also be selecting more contributors, not just 1 or 2.*💡****Tip:**** Choose the organization early.I chose Sugar Labs as my organization in mid-July 2024 because its mission aligned with my interests. Additionally, its consistent participation in Google Summer of Code (for over 10 years) and the high number of contributors selected each year made it a strong choice. Sugar Labs has several projects, including Music Blocks, Sugarizer, Sugar, and many more. My interests and tech stack aligned best with Music Blocks. It is a visual programming language and a collection of manipulative tools for exploring musical and mathematics concepts in an integrative and entertaining way.

My first step was to find the communication channels where I could interact with the project maintainers. Most of these links were available in the README file of the GitHub repository. I was able to find those and introduced myself to the community.

💡****Tip:**** Most of the questions that come to your mind are already answered in the documentation, so make sure to read that first. If something is unclear, then one can reach out to the maintainers. Many contributors skip reading the documentation and ask basic questions directly, which can sometimes frustrate the maintainers.Next, I went through its documentation. Most of the questions I had, such as how to set up the project locally, how it works, etc., were clearly answered there. After reading the documentation, I successfully set up the Music Blocks project on my local machine.

💡****Tip:**** Before contributing, try to play with the project, understand how it works, make some changes to the code, and see if they are reflected.I experimented with the project by changing the text on a button to check whether it was reflected or not. While exploring the project, one may come across several bugs; ocan report them or even try to fix them.

I was experimenting with Music Blocks when I found an issue in their JavaScript editor: there was an extra line number. I decided to fix it, which eventually became my first open-source contribution.

*I located the relevant code, and the Visual Studio search functionality helped me a lot in finding it.

💡****Tip:**** One don’t have to understand the entire codebase of the project, start small.The code was adding 1 to the line count. I just removed it and it worked.

*I tested it thoroughly and created a Pull Request for it. To my surprise, it was merged within 3 to 4 hours. I was so excited and happy about it. It actually motivated me to make more contributions.

💡****Tip:**** These contributions and communications with the maintainers actually build trust, and there are high chances of one being selected.Afterwards, I made several more contributions. All my contributions can be found here:

 https://github.com/sugarlabs/musicblocks/pulls/haroon10725

Through these contributions, I learned not only how to write better code, but also how to communicate effectively and document my work properly.

GSoC organizations are announced around February 2025. The organizations that apply to the program publish their idea list around January, so contributors can choose the idea which excites them the most and start exploring it.

💡****Tip:**** At max one can submit 3 proposals in GSoC; try to submit at least two proposals for 2 different projects to increase your chance.Sugar Labs also started to publish their ideas around December and January 2025. I chose two ideas from the list and started exploring them.

Then from the end of February 2025, I started to work on my proposals. I created two detailed proposals that included my past contributions, how I would complete the project, and a timeline.

💡****Tip:**** Make sure the mentors assigned to the project review your proposal and give feedback on it.I asked the project mentors to review my proposals. They reviewed them and gave me detailed feedback. I improved them and then submitted them to the GSoC website one week before the deadline, as 8th April 2025 was the last date for it. I was pretty confident that I would be selected due to my past activity with the organization.

But unfortunately, when the results were announced on May 08, 2025, I was not selected. But this didn’t stop me from making meaningful contributions. After 3 to 4 days, my mentor reached out to me saying that “there is still a chance we can get you into GSoC; Google has opened some additional spots and we are going to nominate you.” I was so happy and thanked my mentors. But luck was not on my side and I couldn't get selected.

But then Sugar Labs announced their Sugar Summer of Code 2025. This was the first time they did it, and I was their pilot candidate for it. Under the guidance of my mentors, I created an AI Sample Generation tool which can create endless samples. A small demo of it can be found below:

*After completing my internship, I didn't stop contributing. I have continued to stay active in the Sugar Labs community, contributing in various areas. In addition, I've explored and contributed to several other open-source projects such as UniversalPython, which has helped me broaden my technical skills and understanding of collaborative software development.

I strongly believe that contributing to open-source projects is one of the best ways to gain hands-on experience. It not only sharpens your coding skills but also teaches you how to collaborate effectively, communicate with the maintainers and work on real world software used by people around the world.

At the last I would like the thanks my mentors; Walter Bender (https://github.com/walterbender) and Devin Ulibarri (https://github.com/pikurasa) for their guidance throughout the journey and Saad Bazaz (https://github.com/SaadBazaz) for guiding me in open-source.

### [Fixing a Next.js Documentation Issue](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/fixing-a-next-js-documentation-issue)

- Slug: `fixing-a-next-js-documentation-issue`
- Published: 2025-10-24T18:22:25.000+05:00
- Updated: 2025-10-24T18:31:40.000+05:00
- Reading time: 4 min
- Tags: Open Source, Vercel, Next.js, JavaScript, Open Source Community
- Authors: Hamad Ullah
- Visibility: public

A few months ago, I was assigned a ticket to integrate **Mock Service Worker **in to Ruby for API mocking. While trying to make things work, I stumbled upon a confusing issue, not in my code, but in the **Next.js documentation itself**. What began as a simple debugging session turned into a pull request that’s now officially merged into the Next.js repository.

This is a blog post on of how I found an issue, what I did to fix it, and why contributing to open source is essential.

### How I Found the Issue

I setting up **API mocking** using **MSW** in our Next.js application. For local development, MSW is incredibly useful, it intercepts network requests and allows us to simulate API behaviour without touching the backend.

I followed the Next.js documentation example for MSW setup carefully, but something just wasn’t working. The **worker setup** wasn’t behaving as described, in fact the imports were unrecognized.

After digging into the issue for a bit, I realized the example itself had a **outdated setup,** something subtle that could easily trip up any developer trying to follow it step by step.

I checked GitHub, and someone had already opened an issue describing the same problem. I realized the documentation is outdated and added a to-do for future reference to fix it in my free time.

### What I Did

I cloned the Next.js repo, navigated to the documentation example, and made the necessary fix. The goal was simple, make the MSW example actually work as advertised.

After verifying the fix locally and ensuring that it didn’t break anything else, I submitted a **pull request** with a short, clear explanation of what the problem was and how my change resolved it.

The **Pull Request **I made is the following**:**

Fix/msw-issue-68521 by HamadUllah16 · Pull Request #83482 · vercel/next.jsFix: 68521 Updating outdated with-msw example
The with-msw is outdated and doesn't work with the latest msw version.
What?
The with-msw example is outdated and does not work with the latest msw…*GitHubvercel*Soon after, one of the maintainers reviewed it, validated the change, and merged it.

That was a really satisfying moment, not just because my code was now part of Next.js, but because other developers wouldn’t need to waste their time figuring out why the setup isn't working as expected.

### Why I Think It Got Merged

Open source maintainers get hundreds of PRs. What I did was review the ones that actually got merged. I think that’s what worked in my case:

- I explained *why* the fix was needed, not just *what* it did.
- I referenced the existing issue and made it easy to verify the bug and the fix.
- The PR didn’t introduce extra complexity. It was a focused, single-purpose fix.
- I followed the repo’s contribution guide and conventions closely.
- I added a demo video which made it easier for reviewers to glance over my changes. Even though they'd still test locally, it establishes trust.

I tried to make it as contextual and easy to review as possible, because open-source reviewers are often doing this work in their free time - it's best to utilize their time in the best possible way, in the rare hours they get it.

### Why is open source development important?

Open source is the invisible backbone of modern web development. Majority of the frameworks, libraries, and tools we use, from **React** to **Next.js**, **MSW**, **Tailwind**, and beyond, are built on the collective effort of thousands of developers who share their work openly.

Contributing back isn’t just a nice gesture, it’s how the web keeps evolving. When you fix a bug, improve documentation, or clarify an example, you’re helping thousands of other developers avoid the same confusion.

What makes open source especially powerful in the **JavaScript ecosystem** is how interconnected everything is. A small fix in one project can ripple across others, improving developer experience far beyond a single codebase.
In a world where frameworks constantly transform and build on each other, collaboration is what keeps innovation moving forward.

Ruby – AI Powered Pitch Platform for Smarter SalesClose deals faster with Ruby. Instantly generate personalized, insight-driven sales pitches for any company using AI. Trusted by modern sales teams to win more.**Check out Ruby, the project I'm working on at Grayhat.

I'm open to learn more in the future about Next.js and contributing to open-source. Stay tuned!

### [Secure your ship](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/secure-your-ship)

- Slug: `secure-your-ship`
- Published: 2023-10-25T15:36:00.000+05:00
- Updated: 2024-05-10T13:49:03.000+05:00
- Reading time: 3 min
- Tags: Supply Chain Security, NPM, Open Source, Open Source Community, JavaScript, Typescript, Vercel, Innovation, Tech
- Authors: Asfand Yar
- Visibility: public

*In the fast-paced world of modern web development, where tools like Vercel, Checkly, Mixpanel, and Hotjar have revolutionized workflows, it's easy to focus on the efficiency gains these platforms bring while inadvertently neglecting a critical aspect—security. As development teams expand and diversify their skill sets, the boundaries of projects expand exponentially. With more contributors, integrations, and code to manage, the attack surface grows significantly, amplifying the potential risks.

Real-world incidents serve as stark reminders of the impact of security vulnerabilities. The Equifax breach in 2017 exposed sensitive data from 147 million individuals due to unpatched software, and the Colonial Pipeline ransomware attack in 2021 disrupted critical fuel supplies. Security lapses have even derailed major mergers and acquisitions, as seen in the delayed acquisition of Yahoo by Verizon following data breach revelations. The SolarWinds exploit underscored the risks associated with unlicensed software, affecting numerous networks.

### AI & Blockchain bring more security concerns than before.

Supply chain challenges wield a profound impact on the growth trajectory of today's AI and blockchain startups. In the AI realm, dependencies on open-source libraries and frameworks make startups vulnerable to security breaches and compromised model outputs, disrupting development timelines and compromising data integrity. Likewise, in the blockchain space, vulnerabilities in smart contract frameworks and consensus mechanisms due to supply chain issues can undermine the trustworthiness of distributed ledgers, leading to compliance issues and investor concerns.

These vulnerabilities often arise from various sources such as unpatched software, misconfigurations, and human error. The complexity introduced by open-source components and third-party integrations necessitates thorough vetting and monitoring to counter potential threats.

### Enter SecOps.

Integrating Supply Chain Security and Security Operations (SecOps) into development cycles becomes imperative for proactively addressing vulnerabilities. However, current security solutions often suffer from alert fatigue, overwhelming users and diluting the impact of critical notifications.

Enter listen.dev, a new player in the dynamic landscape of web development challenges, offering a fresh perspective on fortifying security measures seamlessly.

### Make Security Actionable.

If you've used dependabot before, you'll immediately know what the term "alert fatigue" means even if you've never read about it before. Basically, when you receive a flood of notifications and alerts but don't have an action item for them, and they keep piling up, you eventually start ignoring the notifications.

That's deadly for security; you start ignoring once, and it goes permanently under the rug **until it's too late.**

We've had some insider conversations with listen.dev, and according to their claims, security is no longer an afterthought. It's gotta be part of the SDLC (Software Development Life Cycle).

What does that mean for devs? Just like how Vercel plugs themselves right into the everyday DX (Developer Experience) of a developer with their GitHub integration, listen.dev also has a GitHub integration which gives you 1) Actionable insights, 2) A "Security Review" mechanism (Yes, it works exactly as it sounds like. It's a security approval for each PR which has security vulnerabilities).

On the side, Listen features the standard:

**Real-time Security Scans:** By embedding real-time security scans into each pull request, listen.dev facilitates early identification and resolution of vulnerabilities during code integration.

**DNS Profiling:** A standout feature, listen.dev's DNS profiling provides proactive alerts for potential malicious attacks, acting as a shield against looming threats.

**User-Friendly Interface:** listen.dev distinguishes itself by offering a user-friendly interface focusing highly on its DX (taking inspiration from Vercel), making security measures not only effective but also accessible.

**High Customization:** The platform's high level of customization caters to diverse user needs, ensuring improved security and ease of use with tailor-made solutions adaptable to specific requirements.

In the ever-evolving digital landscape, listen.dev emerges as a promising contender, offering robust security enhancements alongside a user-centric approach. Its suite of features designed for practical usability and adaptability signals a potential shift towards more secure and personalized web development practices.

The key is not just about adopting new tools but integrating security seamlessly into the development workflow. It's necessary now more than ever before to be proactive than reactive - a supply chain vulnerability or hack could mean life or death for a company in today's privacy-savvy world.

At Grayhat, we bring impossible to life, and challenge tech to its very extreme. A team of ragtag hackers, with a thirst for innovation, we don't shy from taking on early-stage design and development challenges which define the gray line which sits between the possible and impossible.

Interested in working with us? Drop us an email at sales@grayhat.com.pk

Author: Asfand Yar Aftab