DEV Community: OWASP BLT

Connecting AI and Security with BLT-MCP

Nachiket Roy — Mon, 06 Jul 2026 21:25:45 +0000

This summer i was given the opportunity to work on my BLT-MCP project with OWASP-BLT. Over the last few months, I've been working on transforming how users interact with BLT. Now it marks the midpoint of the project, and there's been some interesting development i would like to share.

What is MCP?
MCP (Model Context Protocol) is an emerging open standard that helps AI models securely interact with local tools and remote data sources. By building an MCP server for OWASP BLT, we're essentially teaching AI assistants (like Claude, Cursor) how to natively speak with BLT directly. Your AI can read issue context, browse repositories, and submit vulnerabilities, without ever leaving your IDE.

The Two Pillars So Far

The MCP Server
Written in Python, the server acts as the translation layer between LLMs and the BLT API. It exposes two main capabilities to the AI:
- Resources (blt:// URIs) - the AI can fetch live data exactly when it needs context. For example, reading blt://issues/123 to get the details of a specific vulnerability.
- Tools - actionable endpoints that let the AI do things, like submit_issue and add_comment.
The BLT-CLI (Rust Terminal UI)

While IDE integration is great, sometimes you just want a fast terminal experience. I built BLT-CLI in Rust using ratatui a Terminal UI (TUI) that connects directly to the MCP server and the BLT API. Triage logic is being built alongside it, so you can browse, review, and act on issues right from the terminal.

What's Next
The core logic and terminal are built. For the remaining sprint, I'll be focused on testing everything end-to-end, polishing the rough edges, and starting work on a vision pipeline that can turn a dropped screenshot into a drafted vulnerability report, which is still early and in progress.
Thanks for following along!

Building BLT HackerHouse: An Open Source Journey!

rp_dex — Sun, 05 Jul 2026 16:35:08 +0000

Over the past few weeks, I've had the opportunity to intern with OWASP BLT, where I've been working on BLT HackerHouse a real time platform that visualizes contributor activity in an interactive virtual house.

The idea behind HackerHouse is simple: as contributors open merge requests, report bugs, or interact with the project, their avatars move through different rooms, giving maintainers a live overview of what's happening across the community. Behind that visualization is a backend responsible for processing events, managing contributor state, and delivering updates in real time.

When I joined, I expected my biggest challenge to be designing the backend architecture. Instead, the project took an unexpected turn.

During development, the OWASP BLT GitHub organization became inaccessible, requiring the team to migrate active development to GitLab. It wasn't just a matter of moving repositories documentation, development workflows, CI/CD pipelines, and contributor onboarding all had to be updated while development continued.

It was the first time I'd experienced how quickly the direction of an open source project can change and how important adaptability is. Watching the community reorganize and keep shipping despite the disruption was a valuable lesson in resilience.

Alongside the migration, I focused on building the backend foundation for HackerHouse. This included designing an event processing pipeline, implementing webhook handling, creating a unified event model, building real-time communication with WebSockets, and writing automated tests to ensure the system remained reliable as it evolved.

One of my biggest takeaways from this internship has been that building software isn't just about implementing features. It's about designing systems that can evolve, collaborating with an open source community, and adapting when unexpected challenges arise.

I'm excited to continue developing HackerHouse over the coming weeks and contribute further to the OWASP BLT ecosystem. This experience has already taught me far more than I expected not just about backend engineering, but about how resilient and collaborative open source communities can be.

GSoC'26 Midterm Blog: Building BLT University Into an Interactive Security Learning Platform

saksh — Sun, 05 Jul 2026 15:51:10 +0000

Overview

This summer, I got the chance to contribute to OWASP BLT, a project under the OWASP umbrella organization, through Google Summer of Code 2026. My project is focused on BLT University, a security learning platform that helps learners and contributors understand web vulnerabilities through hands-on labs.

The main idea behind this project is simple: instead of only reading about vulnerabilities, learners should be able to identify vulnerable code, explain why it is unsafe, and then fix it. This makes security learning more practical and closer to real open-source contribution work.

BLT University is part of the OWASP BLT ecosystem and aims to make cybersecurity education more accessible through open learning material and practical labs.

During the first half of GSoC, most of my work went into building the foundation for this experience: structuring labs, creating an interactive lab engine, adding validation, improving contributor workflows, and setting up tests so the platform can grow safely.

What is my GSoC all about?

My GSoC project is about transforming BLT University from a mostly static educational site into an interactive cybersecurity learning platform.

The core learning flow I am building is:

Identify the vulnerable part of a code snippet.
Explain why the code is vulnerable.
Fix the issue using safer code.

This flow is being built on top of a static Jekyll site, so a big part of the work has been designing a system that works without a traditional backend while still supporting structured content, validation, progress tracking, and future dashboard features.

The main tech stack for this phase included Jekyll, Markdown, YAML frontmatter, JavaScript, JSON Schema, Python validation scripts, Jest, jsdom, GitLab CI, and browser localStorage.

Key deliverables

Lab content and platform structure

Created 10 labs across major web security topics.
Moved lab content into _labs/ using Markdown and YAML frontmatter.
Added lab listing and lab detail pages.

Interactive learning experience

Built an interactive lab engine with Identify, Explain, and Fix stages.
Added line-selection based vulnerability identification.
Added explanation and fix validation.
Added browser-side progress storage using localStorage.

Contributor workflow

Added schema validation for labs.
Added a lab validation script for contributors.
Added contributor documentation and a reusable lab template.

Gitlab CIs & Tests

Added GitLab CI checks for validation, build, and tests.
Added a Jest test baseline for lab behavior, validators, progress storage, and state transitions.

Progress vs proposal

At midterm, the strongest progress is in the foundation layer. BLT University now has a structured lab platform and the core interactive learning flow is mostly in place.

Proposal area	Current progress	Status
Structured labs	Labs live in `_labs/` and render through Jekyll.	Mostly complete
Interactive flow	Identify, Explain, Fix, feedback, hints, and progress storage are working.	Mostly complete
Contributor workflow	Schema validation, docs, and a reusable lab template are in place.	Mostly complete
Quality checks	GitLab CI and Jest test coverage have been added.	In progress
Intelligence dashboard	Planned for the second half.	Upcoming
Personalisation	Recommendations, analytics, badges, and streaks are planned next.	In second half

Architecture

The main challenge was connecting the different parts of BLT University into a reusable system.

Lab content begins in _labs/, where each lab is defined using Markdown and YAML frontmatter. During the Jekyll build process, these files are transformed into static pages. A shared JavaScript engine then powers the interactive Identify, Explain, and Fix workflow by loading the lab configuration, rendering the simulation, validating learner submissions, and tracking progress in the browser using localStorage.

flowchart LR
    author["Contributor writes lab<br/>Markdown + YAML frontmatter"] --> labs["_labs/ collection"]
    labs --> schema["Schema validation<br/>and lab checks"]
    schema --> ci["GitLab CI<br/>validate, build, test"]
    labs --> jekyll["Jekyll build"]
    jekyll --> page["Static lab page"]
    page --> data["Embedded lab data"]
    data --> engine["JavaScript lab engine"]
    engine --> identify["Identify vulnerable code"]
    identify --> explain["Explain the issue"]
    explain --> fix["Fix with safer code"]
    fix --> progress["Browser progress<br/>localStorage"]
    engine --> feedback["Hints and validation feedback"]

Merge requests

MR !1 introduced the first interactive simulation work and helped move the project from static reading material toward hands-on labs.
MR !2 improved the lab page structure and site integration so labs could be rendered more consistently.
MR !3 added schema validation, the lab validation script, and contributor-facing lab documentation.
MR !4 expanded the lab with additional web security labs such as command injection, file upload vulnerabilities, open redirect, sensitive data exposure, and SSRF.
MR !5 added automated test coverage for validators, simulation state transitions, progress storage, and lab engine behavior.
MR !6 refined the lab simulation experience and addressed review feedback around reusable simulation behavior.

Links:

Repository: BLT University on GitLab
Live demo: BLT University

Challenges & What I Learned

One of the main challenges was building interactive experiences on a static Jekyll site without relying on a backend. The lab pages are static, but the learner experience still needs dynamic behaviour: selecting lines, validating answers, showing feedback, and tracking progress. This pushed me to think carefully about what should live in Markdown, what should be handled by Jekyll, and what should be handled by JavaScript.

Another challenge was designing reusable validators. Security fixes can be written in many valid ways, so the validators cannot simply check for one exact answer. They need to focus on secure coding patterns, such as parameterised queries or restricted redirects, while still giving useful feedback to learners.

I also learned how important state management is in an interactive learning flow. A step being unlocked is different from a step being completed, and learners should be able to restart earlier stages without the UI showing later stages as complete. Fixing these details made the lab engine feel more reliable and less confusing.

Next phase after midterm

After midterm, the focus will move from the foundation layer to the intelligence and personalisation layer.

It will include:

Building the vulnerability intelligence dashboard to show vulnerability trends, OWASP category patterns, and related BLT University labs.
Creating data files for vulnerability trends and OWASP category weights.
Mapping vulnerability patterns to relevant labs.
Building a recommendation system based on learner progress and vulnerability frequency.
Improving the lab dashboard experience.
Adding learner analytics across categories.
Improving accessibility and keyboard navigation.
Adding badges, streaks, and static hint fallbacks.

The long-term goal is for BLT University to become a platform where contributors can learn security through practice and understand which vulnerabilities matter most based on real patterns from open-source development.

The first half of GSoC was about building the foundation: labs, validation, reusable interactions, contributor workflows, and tests. In the second half, I'll be building smarter learning experience where BLT University not only teaches individual vulnerabilities, but also helps learners understand what to practice next and why it matters.

Acknowledgement

I would like to thank all my mentors, for their guidance, review feedback, and support throughout this period.

Thank you for reading :)

📢 Calling all Content Writers & Community Builders!

Ananya — Sun, 03 May 2026 20:21:06 +0000

Hey everyone! We are opening up opportunities for everyone to contribute to our official social media channels. If you enjoy writing, sharing tech insights, or highlighting community wins, we want you on the BLT Newsroom team! 🗞️✨

Here is how the process works:

Topics & Deadlines: We will regularly share specific writing topics based on our current requirements, along with a submission deadline.
Submit Your Draft: Write your post based on the given topic and share your draft right here in the group before the deadline hits.
Review & Feedback: The lead project maintainer and social media maintainers will review all the submitted drafts.
Final Selection: The draft that gets the top reviews will be selected and published on the official OWASP BLT social media pages!

This is a fantastic way to build your portfolio, practice your technical writing, and get your work seen by a much wider audience. Keep an eye out for our first topic announcement soon! 🎨💻

Apply here: https://jobs.owaspblt.org/job.html?id=owasp-blt-content-writer
Join our slack community today!👉https://join.slack.com/t/owaspblt/shared_invite/zt-3rstz26wj-WtlZFo5RXqT_9UwNYJeycw
Then join the newsroom channel.

See you all with your first drafts here!

Accepted into GSoC 2026: From First PR to Official Selection

Ananya — Thu, 30 Apr 2026 18:17:01 +0000

If some had told me in my first year of university that I would be writing this post, I wouldn't have believed.

Today, I finally achieved a dream I have held onto for years: I’ve officially cracked Google Summer of Code 2026! with @owasp_foundation under OWASP BLT✨ It might seem like just another program to some, but for me, this is a dream coming true-a journey of collecting broken pieces, holding them together, and building something completely new.

🍂 The Beginning

Coming from a computer science background in high school to an unexpected core engineering major in university was a drastic shift. My first year was spent just trying to heal my lost confidence and survive the transition. I heard about GSoC back then, but since I wasn't involved in the tech community, it felt like a distant, impossible mountain.

The real struggle hit in my second year. The syllabus was exhausting. By the time my second year rolled around, I started peeking outside my core curriculum. I heard whispers of hackathons, open-source contributions, and got more involved in exploring this "famous" program called GSoC. I made my first attempt at GSoC by looking into organizations. I failed. I didn't have the knowledge of any tech stack, Git, or the skills to write those hundreds of lines of codes.

☕ The Turning Point

That failure was my wake-up call. During the summer break, I made a choice. I grounded myself, cut out the outside world, and sat at my desk for three months straight. I began participating in hackathons, doing LeetCode, and my open-source journey truly took off with GirlScript Summer of Code (GSSoC) 2025. That experience gave me the momentum and belief I needed to aim higher.

💻 The GSoC Grind

In October, I changed my strategy, dug through past archives, and found an organization that perfectly matched my new skills: OWASP BLT.

The struggle didn't end there. For the first few months, I had to work incredibly hard just to understand how a single line of code contributed to the final service on their homepage. But I stayed consistent. I opened my first PR, fixed bugs, and slowly became a constant contributor from October all the way through March, balancing my contributions with my core curriculum.

🤍 The Gratitude

This win is not mine alone. It belongs to the incredible people who believed in me:

To my Father and Mother: You are my strength. Your faith in me when I had none is why I am here.
My Circle: To the few friends who stood by me and fueled this journey.

I met incredible people in this organization. To our Lead Project Maintainer, @donnieblt : Thank you. Every single step I have taken in this organization was only possible because of your support. If you hadn't been there, I wouldn't have reached this level of excellence.

I am endlessly humbled and grateful to every energy out there that helped make this dream a reality.

Here is to new beginnings. 🥂

Breaking Into Open Source This Summer? Start with OWASP BLT

saksh — Thu, 16 Apr 2026 15:31:47 +0000

As summer approaches, open source sees a steady wave of new contributors.
Each year, developers explore repositories, review issues, and look for meaningful ways to get involved.

The challenge is rarely writing code. It is understanding the system well enough to contribute effectively.

This summer, OWASP BLT is participating in the Social Summer of Code (SSOC), a three-month program focused on open source contribution, learning, and collaboration. It brings together contributors from diverse backgrounds to work on real-world projects, submit pull requests, and actively engage with the open source ecosystem.

About OWASP BLT

OWASP BLT (Bug Logging Tool) is a community-driven OWASP project developing open source tools for vulnerability reporting, bug tracking, and security automation.

The project spans APIs, dashboards, applications, bots, and ongoing research under OWASP. This is designed to make security workflows more practical, structured, and accessible for developers and teams.

Ongoing Deletion Program

Alongside regular development, OWASP BLT is running an ongoing deletion initiative.

Contributors review the repository, identify unused or unnecessary files, and remove them. Each valid contribution is rewarded with $1. This campaign will run till 30th April.

This effort focuses on:

Supporting the ongoing migration to separate and more structured repositories
Maintaining a clean and efficient codebase
Improving long-term maintainability
Helping contributors understand the structure of a real-world project

It also provides a simple and practical entry point for those beginning their open source journey.

Contribution Opportunities During SSOC

As the program progresses, more areas of the project will be opened for contribution, including:

Clearly defined and beginner-friendly issues
Opportunities across different parts of the stack
Active collaboration within the community

Whether you are exploring open source for the first time or looking to contribute to security-focused tooling, OWASP BLT offers a structured and meaningful way to get involved.

Get started 🚀

Explore the repository and start contributing:
https://github.com/OWASP-BLT/BLT.

🎉First PR? Get paid for it

Ananya — Wed, 01 Apr 2026 18:55:05 +0000

Introducing Dollar Deletions — a special campaign only for first-time contributors.

We know large codebases can be intimidating, so we are paying you $1 for your first accepted Pull Request where you safely delete unused or legacy code.

👉 Why are we doing this?

We are preparing for a major migration! To do this safely, we need to thoroughly clear out the existing repository. Your deletions will help us sweep away all the old files so we can seamlessly move our brand-new system into the clean repo.

🧹 Clean up real production code
🧠 Learn how large codebases work
🚀 Make your first open-source contribution
💵 Earn your first dollar online

How it works

Find dead or unnecessary code in our repository.
Submit your first-ever PR to remove it.
Pass the code review (your changes must not break existing functionality).
Get $1 via GitHub Sponsors!

📌 The Rules

This campaign is only for first-time contributors to this repo.
Your PR must include a clear explanation of what you removed and why.
The code must remain fully functional after your deletion.
Limited to one reward per contributor.

🏆 Bonus: Referral Leaderboard!

Spread the word and climb the ranks! You can refer others to this initiative. Just have the PR mentioning that you are referring a contributor as @user1 refers @user2 and link that PR to our mega issue. This will track the mention and boost @user1's rank on our referral leaderboard.

💡Not sure where to start? Look for issues labeled good-first-deletion to get your bearings.

👉Start here: OWASP-BLT/BLT

Your first PR shouldn’t be scary—it should be rewarding. We can't wait to review your code!

A Beginner’s Guide to Open Source Contributions (From My Journey and Mistakes)

Jayant Malvi — Tue, 31 Mar 2026 21:02:24 +0000

Hello everyone, I am Jayant Malvi. I am currently in 2nd year of my B.tech Computer Science in IIT Madras.

So my journey started way before I actually started contributing. I was really intrigued by the open source world and always wanted to contribute to organizations where my work is actually used by real people.

My first mistake was that I was just looking at how to start contributing—how to do GSoC and all that. I checked various GitHub repos, looked at good-first-issues, and always thought, “nah, I don’t know this, I won’t be able to contribute.” This was in my first year of college. Around the same time, I was also reading a lot about cybersecurity—networking, vulnerabilities, etc.

Then in my second year, one day in September, I explored OWASP projects and got introduced to OWASP-BLT. The idea of turning bug hunting and vulnerability findings into a gamified environment—with bounties, bacon—really caught my eye. That day I joined the Slack channel and messaged the maintainer, Donnie, about how I wanted to contribute. Donnie, being a great mentor, replied and helped me get started. That was the all the head start I needed.

I jumped into the codebase and started looking at pending PRs. My goal was simple: understand how the codebase works and how PRs are actually done. While setting up the project, I noticed tests were failing. I had no idea what those tests meant at first, but after digging into the codebase, I found there were two identical names causing the issue. I discussed it in Slack and raised a PR.

That’s when I realized—we really overcomplicate open source contributions. It’s honestly just about having the will to contribute and enjoying the process. From that day onwards, I caught momentum and never stopped.

The biggest advice I can give (it sounds simple, but it works): stop thinking so much and just jump into the codebase. At the start, you’ll feel like you don’t understand anything, but trust me—there will be a point where it just clicks, and after that it almost becomes addictive.

Another important thing: being involved in discussions. One of my mistakes was being too hesitant to talk or ask questions. I thought people might think I’m dumb or not professional. That mindset held me back for a while. What I later realized is—no one thinks like that. Everyone is learning. You should ask questions freely. The kind of knowledge you get from peers in these communities is something you won’t easily get elsewhere.

I also really liked how our maintainer, Donnie, introduced initiatives like requiring peer reviews for PRs. We have a strong peer network in BLT where everyone helps each other. A big part of my journey was reviewing PRs—this helped me understand the project better and learn about common mistakes like N+1 queries, deduplication issues, etc. I’d strongly recommend reviewing PRs—it helps others and sharpens your own understanding.

One of the major things I worked on was BLT-Zero. It’s a core part of OWASP-BLT where anyone can send vulnerabilities report to target organizations through a zero-trust workflow—no plaintext storage, mail with encrypted zips, hashes for decryption. This project is really close to me. I started working on it in November, it grew into a community project(in BLT-Zero repository, feel free to join us), and now we’re really close to sending the first vulnerability mail. I’m genuinely excited about that.

There are also many other community projects like BLT-Leaf, BLT-SafeCloak, and more across different domains ,you can contribute to domains that interests you and learn a lot. We’ve also started an initiative for new contributors to help reduce technical debt by making deletion PRs. It’s a great way to get started and understand the project better.

Today the GSoC proposal deadline ended. What I really liked is how my perspective has changed. Around 6 months ago, GSoC felt like just a program to get into. But now, it felt like I’m actually building my own project from scratch and trying to make it as good as possible in the organization which is really close to me. The time I spent researching and writing my proposal was quite a lot, but I enjoyed the whole process more than I expected.

Looking back, I’ve really enjoyed these last 6 months of contributing. I just wish I had joined in the fun earlier. The peer group I found here is one of the most supportive I’ve seen. I’ll keep contributing and see BLT grow into one of the biggest security projects out there.

And finally, a special thanks to our maintainer, Donnie for the constant guidance and for helping me grow as a contributor. The discussions we had around new ideas and improvements—and the way you always encouraged them—were easily the best part.

If you’re someone thinking about starting open source—just start. That’s it. You are always welcome at OWASP-BLT.

Designing the Face of OWASP BLT: Three New Creative Challenges 🎨✨

Ananya — Fri, 20 Mar 2026 15:33:34 +0000

If you’ve been following our journey, you know that OWASP BLT is evolving. We’re streamlining our mission and modularizing our code, but a project is only as strong as its identity. We want the "front door" of our project to reflect the innovation happening behind the scenes.

We are officially inviting the creative community to help us redefine our look and community interaction through these design contests:

1. The Video Meme Contest 🎬

Who says security has to be serious all the time? We’re looking for the most creative, relatable, or just plain hilarious video memes that capture the "bug hunting" struggle or the spirit of the OWASP community.

Prize: $10
Deadline: April 15, 2026

👉 View Video Meme Contest Details

2. The Logo Design Contest 🕵️

The OWASP BLT logo is more than just an icon; it’s a symbol of security and community accountability. We’re looking for a fresh, modern take on our visual identity. Whether you’re a minimalist or a fan of bold, "hacker-y" aesthetics, we want to see your vision.

Prize: $25
Deadline: April 15, 2026

👉 View Logo Contest Details

3. The Homepage Redesign Contest 💻

We want our landing page to be as intuitive and high-performance as the tools we build. This is a challenge for the UI/UX enthusiasts—how would you structure the first experience a researcher or contributor has with BLT? Show us your layouts, your transitions, and your vision for a better user experience.

Prize: $25
Deadline: April 15, 2026

👉 View Homepage Contest Details

Why get involved?

Open source isn’t a gated club for "genius coders." It’s a space for anyone who wants to build something that matters. By participating in these contests, you’re not just submitting a file; you’re interacting with the OWASP BLT repository, getting your name on the contributor list, and helping us shape the future of the project.

Start small, design bold, and let’s see what you can create.

The Great OWASP BLT Cleanup: Delete a File, Join Open Source

Donnie Brown — Mon, 16 Mar 2026 23:16:25 +0000

The OWASP BLT project is entering a new phase.

Over time, the main repository grew into a large monolith containing many different components. To make the project easier to maintain and contribute to, we’re migrating from a single repository into multiple focused repositories.

During this transition, we’ve paused new additions to the main repo while we move components into their own homes.

But instead of doing the cleanup alone, we decided to turn it into a community challenge.

🧹 The Great OWASP BLT Cleanup

Want to contribute to open source in the easiest possible way?

Delete a file.

Each contributor can submit one pull request that removes a single file from the repository. That’s it.

As components move to their new repositories, the community will help gradually bring the original repo down to zero files.

Think of it like a collaborative game where every PR moves the project one step closer to its next chapter.

Why We’re Doing This

This campaign helps us:

Trim down the original repository during the migration
Give first-time contributors an easy entry point to open source
Teach the basics of forking, branching, and pull requests
Create a fun community moment around the transition

Once the repository is empty, we’ll replace it with a lightweight version that reflects the project’s new structure.

The Rules

To keep things fair:

🗑 One file deleted per contributor
🔁 No multiple deletion PRs from the same person
🧩 Only one file per pull request
🌱 Contributors are encouraged to join the new repositories afterward

This ensures more people can participate.

Perfect for First-Time Contributors

If you’ve ever wanted to contribute to open source but didn’t know where to start, this is a great opportunity.

You’ll learn how to:

Fork a repository
Create a branch
Commit a change
Open a pull request

All with almost zero technical complexity.

Want to Do More?

After submitting your deletion PR, feel free to jump into the new BLT repositories and contribute real features, fixes, or improvements.

This campaign is just the first step into the community.

Let’s Clean It Up Together

Every deleted file means:

one step closer to the new architecture
one new contributor joining the project
one small win for open source collaboration

Find a file. Delete it. Submit your PR. 🚀

Welcome to the cleanup crew.

OWASP BLT Github Repo

The Transition: From Intent to Integration

Ananya — Wed, 11 Mar 2026 18:15:45 +0000

I had defined my "why" and mapped out a vision for GSoC 2026. However, the last few weeks have shifted my focus from the abstract goal to the granular reality of open-source contribution. The momentum I gained from the past few months of contributions, has evolved into a disciplined daily rhythm.

The gap between planning and execution is where the most significant learning occurs. In my previous update, I spoke about the "Plan." Since then, I have moved past simply archiving organizations to actively living within the repositories of OWASP BLT. I will share more insights on those in the upcoming posts.

The Recent Progress

A major technical highlight of these past two weeks was my deep dive into HTMX. While my foundation in the MERN stack is solid, exploring HTMX allowed me to view web development through a different lens—focusing on simplicity and high-performance transitions without the overhead of heavy JavaScript frameworks.

I successfully implemented a project using HTMX, which served as a practical laboratory for my learning. This experience taught me that being an engineer isn't just about sticking to what you know; it’s about the agility to adopt the right tool for the specific problem at hand. Integrating this into my workflow has made my contributions more versatile and informed.

The Momentum of the Merge

The most rewarding aspect of this period has been the "merged" status on my Pull Requests. There is a specific kind of validation that comes from having code reviewed by experienced maintainers and then integrated into a real-world repository. Each merged PR represented a hurdle cleared—whether it was navigating a complex file structure, adhering to strict coding standards, or resolving merge conflicts that initially seemed daunting.

Through this process, I have begun to overcome the hesitation I previously mentioned. Being active on GitHub and participating in PR discussions has forced me to communicate my logic clearly and accept feedback professionally. I am no longer just a spectator in these communities; I am a contributor, or better say an "Active Contributor"

Revamp of the main BLT home page as BLT Pages

Being involved in the launch of the new BLT Pages home page from both a development and a strategic perspective provided a holistic view of software delivery. It taught me that a successful launch requires more than just clean code; it requires a narrative that connects the technology to the user. This experience has been pivotal in addressing my previous goal of improving proactive communication and overcoming my hesitation in professional settings.

Technical and Community Growth

My commitment to upskilling remains a constant. While I work on the frontend and strategy for BLT, I continue to strengthen my backend capabilities and practice Data Structures and Algorithms in C++. My roles in GDG on Campus and the FLUX Society continue to provide a necessary balance, reminding me that while coding is often a solitary act, building great software is a communal effort.

Looking Ahead

The next few weeks will be about sustaining this velocity. The momentum from the last fourteen days has replaced the "magic" of open source with something more sustainable: the confidence that comes from consistent, meaningful work.

I will continue to deepen my involvement with the BLT core team, ensuring the momentum of the new home page launch is maintained. I am also beginning to translate these practical experiences into the initial framework of my formal GSoC proposal, using my recent contributions as a proof of concept for my potential as a long-term contributor.

See you in the next post. Let's make it happen!

Next Week Is Going to Be Pure Chaos!!

rp_dex — Sat, 07 Mar 2026 16:40:41 +0000

Next week my life will become a distributed system under heavy load.

Why??

Because three things are happening at the same time:

College midsems starts Monday

GSOC proposal writing

Trying to push open source PRs before deadlines

Which means my schedule next week looks something like this:

9:00 AM -> Study for midsem
11:00 AM -> Panic
12:00 PM -> Debug failing PR
2:00 PM -> Realize I studied the wrong subject
4:00 PM -> Write proposal draft
6:00 PM -> Coffee
7:00 PM -> Another PR review request appears
9:00 PM -> Existential crisis
2:00 AM -> Finally understand the code
2:05 AM -> Maintainer asks for rebase

The Academic vs Open Source Conflict

Professors expect to focus on my exams..
Maintainers expect “Can you update the PR with the latest changes?”
My brain expects Sleep

None of these expectations are being met.

The Midsem Preparation Strategy

Open the syllabus.
Realise I should've started earlier.
Open GitHub instead.
Convince myself fixing a bug is “productive studying”..

Proposal Writing Mode

Writing proposals is a special experience.

You start confident

“This project idea is brilliant.”

Two hours later

“Do I even understand my own architecture?”

Four hours later

“Maybe I should become a farmer.”

Reality of the Week

By Thursday the system will degrade into:

caffeine driven coding

last minute studying

refreshing GitHub notifications

pretending everything is under control

Spoiler: it will not be under control.

Final Thoughts

Next week is either going to be:

extremely productive

an absolute disaster

But either way…

there will be commits..