Wong Edan's
Cover
Coding & Algorithms

Breaking the Golden Handcuffs: The Open Source Wishlist

March 14, 2026 • By Azzar Budiyanto

Welcome to the digital asylum, my fellow keyboard-mashing monkeys. You’ve walked into the right place if you’ve ever looked at your monthly SaaS bill and felt a sharp, stabbing pain in your wallet that not even the strongest cup of Java can numb. I am your resident Wong Edan, and today we are peeling back the skin of the “proprietary” beast to see what lies beneath. Why are we still tethered to closed-source tools that treat our data like a hostage situation? Why do we pay for “Pro” features that should have been a standard git pull away?

According to the latest cries for help on Reddit (specifically tracking through August 2025 and back), the developer community is reaching a breaking point. We are drowning in a sea of “freemium” traps and orchestration tools that require a PhD in Finance just to scale. From Docker’s dominance to the “not-so-open” nature of VS Code, let’s dive into the technical abyss of the tools we desperately wish were truly, honestly, and brutally open-source.

1. The Orchestration Overlords: Docker Compose, Tilt, and Skaffold

In the realm of local development and service orchestration, the name “Docker” is whispered like a prayer and a curse. As of the discussions on August 17, 2025, Docker Compose remains the absolute “go-to” for multi-service local development. It’s the standard. It’s the air we breathe. But even air can be taxed. Developers are increasingly vocal about the need for more robust, open alternatives to the advanced layers that sit on top of the container ecosystem.

While Docker Compose handles the basics, the Reddit threads highlight tools like Tilt and Skaffold. These are described as “more advanced” options for managing the feedback loop when you’re dealing with dozens of microservices. The technical frustration stems from the “black box” nature of some orchestration services. When you move from local dev to a managed cloud environment, the open-source spirit often vanishes, replaced by proprietary orchestration logic that makes vendor lock-in feel like a warm, suffocating hug.

The technical demand here is for an open-source tool that can handle:

  • Real-time sync between local code and remote clusters without proprietary lag.
  • Unified service discovery that doesn’t break when you leave a specific vendor’s ecosystem.
  • Resource-efficient “hot reloads” that don’t melt your MacBook Pro’s CPU.


# The classic Docker Compose we love/hate
version: '3.8'
services:
app:
build: .
ports:
- "8080:8080"
volumes:
- .:/code
db:
image: postgres:latest
environment:
POSTGRES_DB: madness

The community is looking for something that takes the simplicity of the docker-compose.yml above but adds the “magic” of enterprise-level service mesh visibility—without the enterprise-level invoice.

2. The IDE Illusion: VS Code vs. VSCodium

This is where it gets spicy, my friends. As a Reddit post from July 19, 2022, pointed out, there is a massive misconception about Visual Studio Code. Many developers think they are using open-source software. They aren’t. Not exactly. The version you download from Microsoft is proprietary. It includes telemetry, tracking, and certain proprietary bits that would make a privacy advocate weep into their mechanical keyboard.

The “real” open-source heart is Code-OSS or its cleaner cousin, VSCodium. The technical community is pushing for more awareness here. Why do we want a good open-source IDE? Because when the tool you use to write code starts phoning home more often than a homesick teenager, you have a problem. The wish here isn’t for a *new* tool, but for the open-source versions (like VSCodium) to achieve the same level of seamless extension support that the proprietary version enjoys.

“Fyi, vscode is proprietary, code-oss or vscodium are the way to go.” – A Redditor who clearly hasn’t been fooled by the marketing.

The technical divide lies in the Marketplace. Microsoft’s extension marketplace is technically restricted to the proprietary build of VS Code. Open-source advocates are left struggling with the Open VSX Registry, which, while noble, often lacks the latest and greatest versions of popular plugins. We want an ecosystem where the “open” part isn’t just a marketing tag on a GitHub repo.

3. CI/CD: The External Pipeline Trap

August 8, 2021, marked a significant point in the CI/CD comparison wars. Why do we keep using external, closed-source tools for our pipelines? The answer is usually “convenience,” but the cost is visibility. When your build fails in a proprietary CI/CD environment, you’re often left digging through cryptic logs that feel like they were written in ancient Sumerian.

The community wish-list is full of requests for CI/CD tools that are:

  • Self-hostable without requiring a dedicated DevOps team of five.
  • Deeply integrated with the version control system (Git) rather than being a “bolted-on” service.
  • Transparent in their billing—avoiding the “hidden costs” of build minutes and concurrent runner fees.

Developers are tired of the “black box” build. We want to know exactly why the container failed to build, and we want to be able to replicate that failure locally without jumping through eighteen hoops of proprietary configuration. If the tool were truly open, we could debug the runner itself, not just our code.

4. The Android Dilemma: Fear of the Fork

Now, let’s talk about why some developers *don’t* make their code open-source. On February 21, 2024, the r/androiddev community dropped some truth bombs. For many, the risk of open-sourcing a tool or an app is simply too high. Why? Because of the “Pro Version” parasites.

The fear is real: you spend thousands of hours crafting a perfect dev tool or utility app, you open the source code, and within 48 hours, someone has forked it, added intrusive ads, slapped a “Pro” label on it, and uploaded it to the Play Store. The benefits of open-sourcing—such as “maybe someone will contribute”—often pale in comparison to the risk of having your work stolen and monetized by a bottom-feeder.

This creates a vacuum where many high-quality developer tools remain closed-source not because the dev is greedy, but because the “open” ecosystem lacks the protections needed to keep the original creator’s vision (and income) intact. We wish for a world where open-source licenses were more than just “suggestions” to bad actors in the mobile space.

5. Discovery and Curation: Toolspace and the “Ungrateful” Problem

How do we even find these open-source unicorns? On June 20, 2022, Toolspace was introduced—a library of curated open-source developer tools. This was a response to the “discovery” problem. Even when good open-source alternatives exist, they are buried under the massive marketing budgets of their closed-source rivals.

However, being an open-source developer is a thankless job. A recent thread from February 18, 2025, highlighted the “ungrateful people” problem. Devs provide job-ready projects and documentation for free, only to be met with demands for more features, complaints about bugs, and zero financial support. This “toxic” interaction is why many great tools eventually go “Open Core” or shut down entirely.

Technically, the community wishes for:

  • Better curation platforms that highlight “actively maintained” vs. “abandonware.”
  • Sponsorship models that actually reach the individual contributors, not just the big foundations.
  • A shift in developer culture from “this is free, so I can complain” to “this is free, let me help fix it.”

6. The Entrepreneur’s Perspective: Saving Businesses from SaaS Fatigue

Fast forward again to August 17, 2025. A developer on r/entrepreneur sparked a massive debate by asking what expensive software people use that they wish had an open-source alternative. The goal? To help businesses save money. We are talking about tools that cost $50-$200 per seat, per month. For a small startup, that’s not a bill; it’s a mortgage.

The technical target here is “boring software” that has become incredibly expensive. Think of things like:

  • Error tracking and logging (the Sentry/Datadog alternatives).
  • Project management tools that don’t require a university degree to navigate (the Jira alternatives).
  • Customer data platforms that don’t sell your soul to the highest bidder.

The technical challenge is that these “expensive” tools have massive infrastructure costs. An open-source alternative isn’t just a repo; it needs to be an efficient, self-hostable beast that doesn’t cost more in AWS bills than the original SaaS subscription.


# What we want: A simple CLI to replace a $500/mo service
$ oss-tool deploy --env production --no-bullshit
> Checking infrastructure...
> Optimizing containers...
> Deployment successful. Total cost: $0.00 (plus your dignity)

Wong Edan’s Verdict

Listen, you beautiful disasters. The reason we keep using closed-source tools isn’t because we love them. It’s because they are convenient, and humans are fundamentally lazy. We want the “Go-to” power of Docker Compose without the Docker Desktop licensing fees. We want the “Extension Paradise” of VS Code without the Microsoft telemetry. We want the “Scale” of Jira without the “I want to quit my job every time I see a ticket” feeling.

The reality is that “Open Source” is a two-way street. If you want a good alternative to that expensive tool, you have to be willing to git clone, build, and occasionally fix the damn thing yourself. We need to support the creators of things like Toolspace and VSCodium before they get burned out by “ungrateful” users who think “Open Source” means “Free Tech Support Forever.”

My verdict? Stop complaining on Reddit and start contributing. Or at least, stop paying for that “Pro Version” that’s just a skin on a fork of a repo that was written by a guy in his basement in 2014. Stay crazy, stay open, and for the love of all that is holy, check your telemetry settings.