Open-source software belongs in Indonesia's gov-tech stack

Indonesia’s largest government programs run on tens of thousands of distributed local units. SPPG kitchens for MBG. Puskesmas for public health. Posyandu for community monitoring. BUMDes for rural enterprise. Whenever a vendor proposes a piece of software to support one of these programs, the default architecture is a centralised SaaS dashboard with per-seat pricing.

There’s a better default for this profile of program. It just isn’t on the menu.

What’s actually deployed at the edge

A typical SPPG kitchen has:

• One or two commodity Windows laptops, often shared between staff.
• Mobile data or a slow broadband connection that drops out during pickup hour.
• Zero in-house IT.
• A monthly budget that has to cover gas, ingredients, packaging, drivers, and electricity before it covers software.

A typical Puskesmas in the regencies has roughly the same profile. So does a Posyandu, except smaller and with even less budget.

The “central SaaS dashboard with per-seat pricing” architecture asks every one of these units to:

1. Pay a recurring subscription per user.
2. Trust the central host with operational data.
3. Stay online to use the tool.
4. Wait for the vendor to ship features that match their specific context.

Each of those is a fight, and the fight gets harder the further the unit is from Jakarta.

What open source gets you for this profile

Permissively-licensed open-source software (MIT, Apache 2.0, BSD) flips every one of those fights.

• No subscription cost. The local kitchen lead installs the binary the same way they install LibreOffice. Recurring spend goes to zero.
• Data stays local. No vendor sees the operational data of a kitchen they don’t operate.
• Works offline. The tool runs on the kitchen’s own machine. Internet is a luxury, not a dependency.
• Forkable. A regional health department can take the source, modify the specific thresholds for their province, and run that fork. They don’t need to convince the vendor to ship it.

This isn’t theoretical. It’s how a lot of essential infrastructure already works. The Indonesian government uses LibreOffice across many ministries. Public schools run Linux variants. The same logic applies to operational tools for distributed programs.

Why MIT specifically

There are three common open-source licensing options to consider:

1. MIT (or Apache 2.0, or BSD). Permissive. Anyone can use, modify, fork, redistribute — including commercially. Attribution required, no obligation to share modifications.
2. GPL (or AGPL). Copyleft. Modifications must be shared under the same licence. Useful for software that should stay open. Hostile to commercial integrators who want to keep their fork private.
3. Custom or “source-available” licences. Source visible but redistribution restricted. Useful for the vendor, painful for the adopter.

For nationally distributed operational tools, MIT is the right answer. The goal isn’t “force every adopter to share their improvements” — it’s “let every adopter use, modify, and run the tool without friction.” A regional government modifying compliance thresholds for their context shouldn’t have to publish those modifications under a copyleft obligation. A culinary school adapting the recipe builder for student training shouldn’t worry about licence inheritance. MIT removes the friction.

What the vendor side looks like

The argument for SaaS-default usually rests on “ongoing maintenance needs a recurring revenue model.” Two responses.

First, an open-source operational tool can still have a maintainer. The maintainer can be paid through grant funding, a government contract, or a commercial support offering for adopters who want managed deployment. The tool being open source doesn’t preclude a sustainable business model around it — it disconnects the price tag from per-seat usage.

Second, the alternative isn’t “no maintenance.” It’s “every program builds another half-finished SaaS that gets abandoned three years later when funding changes.” Indonesia has plenty of those already.

What I’m doing about it

I’m building MBG Dashboard — an open-source operational tool for SPPG kitchens running the MBG program. MIT-licensed, single-operator design (the Kepala SPPG), with both a desktop binary and a progressive web app from the same codebase. Government compliance thresholds from Juknis MBG 2026 sit at the kernel of the application. The repo goes public on launch.

I’m not arguing every gov-tech tool must be open source. But the default for distributed-edge operational software deserves to be flipped. The argument for SaaS isn’t strong when the operator is a kitchen lead with no IT budget and a flaky internet connection.

A longer case study lives at /work/mbg-dashboard for the practical example.