Open Source, Homeservers, and the Beauty of Tiny Contributions

I once wrote an article about 6 years ago mentioning this profound conversation:

I once asked a CxO of a Fortune 500 company what were his views about “Open-source”. His answer made me realize that I had a long way to go in every walk of life. He said, “Open-source is like Potluck, everyone wants to be there and enjoy the dishes, but not many want to cook and bring something for others”.

Today, open source software is estimated to be valued at about $9 trillion (a little more than twice the GDP of India as of 2025), and GitHub.com has become synonymous with git for many developers. But with recent changes in the tech landscape, including GitHub becoming part of Microsoft, I wonder what’s evolving in this space.

The Beautiful Contradiction of Open Source 🌟

Open source is beautiful. Open source enables 70-90% of all software in codebases to come from open source projects, and 78% of companies rely on it heavily, and this was so 10 years ago.

Yet, many open source projects die. Death doesn’t come in the same way for every project—it manifests in various forms:

License Changes: Java, CentOS, Redis, and other notable projects have faced community backlash due to licensing shifts.

Maintainer Burnout: This is perhaps the most heartbreaking cause. The evidence is everywhere:

• GitHub’s guide on maintaining balance
• What Lodash’s issue backlog reveals about OSS burnout
• When open source maintainers leave
• The Register’s report on maintainer burnout
• SonarSource on maintainer burnout being real
• Why I quit open source
• Awful OSS incidents related to developer burnout

Bad Decisions: Like the Actix Web controversy, or who can forget when OpenAI almost went for-profit?

My Open Source Journey

For me, open source has been the core of every decision I’ve made since that Fortune 500 conversation. Or even before, because I was able to ask that question. Months afterward, I started my homeserver on a Raspberry Pi (back when ARM wasn’t fully supported and Mac was still on Intel, not ARM), but open source saved me almost always.

I found myself constantly seeking awesome repositories to contribute to in whatever fashion I could:

• Testing forks and creating Dockerfiles, docker-compose files, Kubernetes configs (even though I was barely a year into the industry)
• Making small PRs wherever I could find opportunities
• Writing blogs about my experiences
• Giving shoutouts on social media
• Advocating for open source alternatives in professional decisions (even gave a tech talk about it)
• Creating my own projects and sharing them

Today, I just made a tiny contribution to a brilliant open source project called Pake. It’s one of its kind for what it does, and I realized how tiny that change was, but what it meant was significant in my eyes. Partly for personal reasons, but mostly because something like this is exactly what enables open source developers, homelabers, and the self-hosting community.

I wonder if I would have ever considered contributing without being informed, educated, and aware of what open source did for me, each day, every day.

A Homeserver That Delivers 🏠

When I built my homeserver, I built it from nuts and bolts—literally from CPU architecture to everything it became. This wasn’t just about buying a pre-built NAS or grabbing a mini PC off the shelf. I’m talking about understanding ARM architecture limitations, dealing with compatibility issues when most Docker images were still x86-only, figuring out heat dissipation in a tiny form factor, and wrestling with GPIO pins for custom LED status indicators. At that time, I was even considering doing a research paper on how kubernetes on edge could work.

The value it added is not overstated when I say that it exploded, not just expanded, my horizons in the software architecture landscape. Even today, when I experiment with self-hosting LLMs like Ollama or LocalAI, or run different software stacks locally, I get tremendous value from those foundational learnings.

My homeserver runs from my home in India, humming quietly in a corner of my room, connected to a UPS that’s seen more power cuts than I care to count. I use it primarily as an experiment engine, although it’s quite a monster after moving to a full server away from by Raspberry Pi.

Initially, I was port forwarding through my router, dealing with dynamic DNS services, Cloudfront, opening specific ports for SSH, HTTP, and whatever experimental service I was running that week. The router configuration became a nightmare of forwarded ports and firewall rules. But after meeting the incredibly passionate people from Tailscale at DevOpsDays Chicago, I switched to Tailscale. Suddenly, my entire homelab was accessible from anywhere with the simplicity of just typing http://gateway or http://homeserver from my laptop, phone, or any device on my Tailnet—no more remembering port numbers or dealing with DDNS updates.

Like every homelabers worth their salt, I run a dashboarding tool to monitor this beautiful mess of services. Initially, I was running my own creation, WebSheets—a simple Flask app that could display system metrics, service statuses, and quick links to all my self-hosted applications. It served me well, with custom widgets for CPU usage, memory consumption, disk space, network traffic, and even integration with my UPS to show battery status during those frequent power outages.

But when I discovered Glance, I envied it immediately. It was so similar to what I was building but way better—cleaner UI, more widgets, better mobile responsiveness, and it was written in Go, making it incredibly lightweight compared to my Python/Flask setup. The configuration was elegant YAML, the Docker deployment was smooth, and it had built-in support for services I was already running like Pi-hole, Portainer, and various APIs. Much better than what I could achieve as a solo developer working on weekends. So I made the switch, and my dashboard went from functional to genuinely beautiful.

What do you do when you see something easy, tiny, and simple? Switch. (Like Arya Stark in Game of Thrones)

The Pake Discovery 🔍

Yesterday, while casually browsing GitHub repos tagged “llm,” I came across this repository that could turn any web app into a native application. I’d seen variants of this before, sure, but the simplicity of this tool was jaw-dropping! Just pake [url] [options]. I thought, “How could it be that simple?” But I was initially skeptical about such simplicity.

You see, I’ve dealt with PWAs (Progressive Web Apps) before, and they’re… complicated. Sure, the concept is beautiful—write once, run everywhere—but the reality involves wrestling with service workers, manifest files, caching strategies, and platform-specific quirks. Want to make your web app feel native on desktop? You need to handle window management, system integrations, offline functionality, and a dozen other considerations. The traditional approach would be to modify your web application’s source code to include a proper web app manifest, implement service worker caching, handle offline states, and then still deal with browser-specific installation flows that confuse most users.

What makes Pake special is that it sidesteps all of this complexity. Instead of requiring developers to PWA-ify their applications from within their own repositories, Pake takes any existing web application and wraps it in a native shell using Tauri (Rust + web technologies). This means you can take someone else’s dashboard, your internal company tools, your homelab interfaces—basically any web application that wasn’t designed to be a PWA—and instantly make it feel like a proper desktop application with window management, system tray integration, and native OS behaviors.

This is particularly powerful for homelabers and self-hosters like myself. Most of the awesome self-hosted applications we use (Grafana, Portainer, Pi-hole admin interfaces, Jellyfin, etc.) weren’t built with desktop app distribution in mind. The developers focused on making great web interfaces, not on packaging them as desktop applications. Pake bridges that gap without requiring those maintainers to add PWA complexity to their repositories.

And yet, I wasn’t entirely wrong about being skeptical.

~ % pake http://gateway/ --name Glance --hide-title-bar
error: command-argument value 'http://gateway/' is invalid for argument 'url'.
Your url "http://gateway/" is invalid

Seeing this error made me feel like giving up. Sure, why not just open the browser and click on a bookmark? Or just type it in? Actually, just RDP/SSH to my homeserver. Better yet, just run the server locally. Wait, do you guys need a server?

But then I tried all different possibilities:

~ % pake https://gateway/ --name Glance --hide-title-bar
error: command-argument value 'http://gateway/' is invalid for argument 'url'.
Your url "https://gateway/" is invalid

~ % pake http://gateway:80/ --name Glance --hide-title-bar
error: command-argument value 'http://gateway/' is invalid for argument 'url'.
Your url "http://gateway:80/" is invalid

~ % pake http://gateway --name Glance --hide-title-bar
error: command-argument value 'http://gateway/' is invalid for argument 'url'.
Your url "http://gateway" is invalid

The IP address worked!

~ % pake http://I.WONT.SHARE.MY.IP.COME.ON.JK/
✖ Enter your application name … 224
✼ No icon given, default in use. For a custom icon, use --icon option.
✖ Rust not detected. Install now? … no
✕ Rust required to package your webapp.

But I use my application just by typing the hostname, not the IP, thanks to Tailscale for allowing that.

This meant one of three things:

1. Either the DNS resolution was happening very differently
2. The URL validation logic wasn’t working because it was designed for public URLs with TLDs
3. I was being dumb and should just move on (unlike the 40k+ stars on the repo—maybe I was just the exception)

The Fix 🛠️

So I did what everyone does. Quit. Just kidding! I downloaded the repo, found the error, and fixed it. Thanks to the awesome codebase, excellent documentation, and the incredibly helpful Dockerfile, I was able to dive deep into the issue.

The problem was in the URL validation logic. Pake uses a library for URL parsing that strictly follows RFC standards, which means it expects URLs to have proper top-level domains. When you type http://gateway, the validator sees gateway as the hostname but can’t resolve it as a valid TLD like .com or .org. This works fine for public websites but breaks for internal hostnames, local development servers, and—crucially for homelabers—Tailscale magic DNS names.

The beauty of open source meant I could actually fix this. I didn’t need to file a support ticket and wait for a proprietary vendor to maybe consider my edge case in their next quarterly update. Instead, I could:

1. Fork the repository
2. Locate the URL validation function in the code
3. Modify the regex pattern to accept hostnames without TLD validation
4. Test it with my own Tailscale setup
5. Submit the fix back to the community

This is exactly why PWA alternatives like Pake are so powerful when they’re open source. If I wanted to convert my Glance dashboard to a proper PWA, I’d need to fork the Glance repository, add service worker files, create manifest.json, implement caching strategies, handle offline states, and then submit a PR to the Glance maintainers hoping they’d accept the added complexity. Many maintainers rightfully resist this because PWA support adds a significant maintenance burden to their codebase.

But with Pake, the PWA-like functionality is completely separate from the original application. The Glance developers can focus on making an awesome dashboard, and Pake handles the “make it feel like a desktop app” part. And when Pake has bugs that affect my specific use case—like local hostname validation—I can fix just that part without touching the core application logic.

After spending a few hours understanding the codebase (thankfully well-commented and structured), I was able to:

1. Create an issue documenting the problem with clear reproduction steps
2. Submit a PR with the fix and additional test cases
3. Pray that someone would take a look

Remember the maintainer burnout I mentioned earlier? I wasn’t sure if it would be accepted or even looked at for a long time. Open source maintainers are often overwhelmed with issues and PRs, especially on popular projects with 40k+ stars. But you know it was merged because you can see the status when you open the PR!

The fix was simple but impactful: now Pake can handle local hostnames, Tailscale magic DNS, development servers running on localhost, internal corporate hostnames, and any other non-public URL that follows standard hostname conventions but doesn’t have a public TLD.

Now every homelabers can use Pake without needing to download, build, and create their own solution—or even worse, just not using such an awesome tool!

And I think that the beauty of open source isn’t just in the massive contributions or the groundbreaking projects. Sometimes it’s in the tiny fixes that enable fellow developers, homelabers, and tinkerers to use amazing tools without friction. Every small contribution matters, and every fix, no matter how tiny, keeps the open source ecosystem thriving. 💚