OpenSID is an Indonesian village information system with a public and a premium build

What a village information system is for

OpenSID stands for Sistem Informasi Desa, the village information system, and it is developed openly and collaboratively by a community that cares about these systems. The description in the readme is a village office application, and the list of what it is expected to help with is the list you would expect from a small local government going digital.

It is meant to make the village office more efficient and effective, to encourage transparency and accountability in village government, to improve the quality of public services, and to give residents better access to village information. The stated aim is that as many villages in Indonesia as possible can adopt an information system to advance their own village.

The development strategy explains why this is on GitHub at all. The project wants to make it easy for users to obtain SID freely and without bureaucracy, to make it easy to adopt the latest release, and to allow SID activists to contribute directly to the source code of the application. The GitHub hosting is justified by four things: recording every change, allowing a return to a previous revision if needed, easing collaboration between activists and the villages that support them, and providing an online backup of the source code that is accessible at any time.

That last one is the point worth holding on to for a system that lives in a village office in a place with unreliable connectivity. The repository provides a backup of source code, not a backup of a village's records, uploaded files or local configuration. Operators need separate, tested backups and recovery procedures for those assets.

The audience, then, is two groups: Indonesian village and district administrations that need a working system, and developers in the community who maintain and extend it. The application is PHP, and the installation and usage guide is published separately on the project's documentation site.

Two builds, a six month delay, and a binding decision

The distribution model is the most distinctive thing about this project, and the readme spends several sections on it.

The public version, Versi Publik or Versi Umum, is software with limited access to the premium version's features for six months. The premium version, Versi Premium, is kept updated from user feedback, with weekly bug fixes and monthly feature releases. Every feature and improvement released in the premium version will also be available in the public version, but with a six month delay. And some features will never be released in the public version at all, being available exclusively to premium users, according to administrator policy.

So there are two classes of feature. Some are premium first and public six months later, and some are premium only, permanently. The first class is unusual and is worth thinking about in terms of incentives: the public build is not a frozen older version, it is a delayed version, so some public features may follow the premium release after six months, while features designated exclusive may never appear in the public version. Availability and timing should be checked against the current policy.

The copyright section then states who decides. The copyright holders have the exclusive right to determine and manage the difference between the public and the premium versions, including access to features and functions. They are authorised to set the rules, the policy and the update schedule for the two versions in accordance with the applicable GPL terms. The difference they determine is final and binding, and the premium exclusive features will not be available in the public version.

The reference to the GPL terms is the legal hook that makes the arrangement coherent. The project is distributed under the GNU General Public License version 3, and the documentation asserts the right to schedule the two versions within those terms. Whether that is an uncontested reading of what the GPL permits is a question for a lawyer, and it is a question worth asking in a different jurisdiction, because the arrangement is unusual and it is load bearing for the project.

Who owns it, and what the licence file says

The copyright history is written out in detail, and it explains a lot about the governance.

The village information system was first developed by Combine Resource Institution from 2009, with the initial copyright held by that organisation. This GitHub version has been developed since May 2016, free for all villages to use and to develop. And the OpenSID copyright is now held by Perkumpulan Desa Digital Terbuka, a legal entity formed specifically to manage OpenSID.

That last detail is the most consequential line in the readme for anyone considering a fork or a derivative. A community project that keeps its copyright with an informal group of individuals cannot be governed cleanly, and forming a legal entity to hold it is a deliberate step towards making the project sustainable and its licensing decisions defensible. It also means that the person deciding what is premium and what is public is an organisation, not a maintainer, which is a more durable arrangement and a slower one.

The licence metadata on the repository is listed as a custom licence that GitHub cannot classify, and there is a LICENSE file at the repository root. The README describes GPL version 3, but the repository LICENSE embeds project-specific distribution and policy text within the GPL text. Review the actual file and obtain legal advice about its effect instead of treating it as an unmodified standard license. So the same pattern appears here as in many community projects: the human readable statement of the licence is in the documentation, and the file behind it should be read before you rely on it.

For a government deployment, the practical question is what happens to a village's data and configuration if the project is discontinued. The source repository does not back up a village's own data or configuration. Maintain and test separate backups, document recovery procedures and review the license applicable to the deployed edition.

What is in the repository, and the two application structures

The top level tells you that this is a substantial PHP application rather than a single script.

There is an app/ directory with an artisan entry point, which is the Laravel convention, alongside a Modules/ directory and a donjo-app/ directory, which is how CodeIgniter style module applications are laid out, plus resources/ with views, config/, bootstrap/, storage/, assets/, bin/ and vendor/. The coexistence of an app/ tree and a Modules/ tree is the visible trace of a migration between two application structures, and the presence of a rector.php at the root says the migration is being done with automated refactoring rather than by hand.

The modules are the functional heart of it, and a village information system is not a small feature set: it covers population and household records, land and asset registers, planning and budgeting, services and complaints, and the reporting that a village office has to produce for the district.

Around that there is a real engineering setup. There is a composer.json and a composer.lock for the PHP dependencies, a phpunit.xml for the PHP test suite, a playwright.config.ts and a .e2e.env.example for end to end browser tests, and a tsconfig.json alongside a package.json for the front end assets. The package.json is small, with prettier and a Blade specific prettier plugin, which is what a Laravel project with a lot of server rendered views looks like from the tooling side. There is also a .php-cs-fixer.php for the PHP style rules, and a prettierrc.json.

Two other files stand out. There is make_obfuscate.php and umum_obfuscate.php, which are obfuscation scripts, and a backup_inkremental/ directory. Their names alone do not establish how either edition is built or whether a particular deployment has working backups. Inspect the scripts and test the deployment's backup process before relying on them.

For the record keeping, there is catatan_rilis.md for the release notes and catatan_singkat_library_yang_digunakan.md, a short list of the libraries in use, which is exactly the file a compliance checklist needs and a rare one to find in a project of this kind.

The demos, the community and how it is funded

There are two live demos, and they are the fastest way to see what the public and premium versions actually do.

The public version demo is at demosid.opendesa.id, with the administration module at the siteman path, and the credentials are the admin account with the password sid304. The premium version demo is at berputar.opendesa.id, with the same administration module path and the same credentials. The readme points at both, which is a sensible thing for a project whose central design decision is a feature difference between two builds: you can compare them yourself rather than take the policy on trust.

The community channels are informal by design. There is a Facebook group and a Telegram group for OpenSID users and activists, and the readme is explicit that the forum is informal, a place to share information and help each other with using and developing OpenSID.

Contributions come through GitHub issues for problems, suggestions and development requests, and the readme says contributions from the community are highly valued, both in the documentation through the project wiki and in the source code in the main repository.

The funding is Open Collective, with a backers badge and a sponsors badge, and the sponsorship text asks whether your village, institution or company has benefited from OpenSID and invites you to become a sponsor, with your logo and a link to your site displayed in the readme. There is also a direct bank transfer option, with the details on the project site.

The combination of a sponsored open source project, a public and a premium build, and a legal entity holding the copyright is a coherent and fairly common shape for infrastructure software that has to be maintained for years and also has to pay for itself.

Release cadence and where the project stands

The versioning is calendar based, which is a sensible choice for software that villages install and keep for years, because it makes the release date visible in the version string.

The recent releases are v2606.0.0 on 2026-06-01, v2607.0.0 on 2026-07-01 and v2607.0.1 on 2026-07-24. So a release at the start of each month, with patch releases inside the month, and the year and month carried in the version. The default branch is umum, the public branch, and the last push was on 2026-09-06 with the repository not archived.

The gap between the last tagged release in July and the last push in September is normal for a project that tags monthly and works continuously, and it means the public branch is ahead of the last release. Anything you deploy should be a tagged release rather than the branch tip, which is a general principle but is easy to forget when the branch is the one people work from daily.

The overall picture for an adopter is a long-lived project with a history going back to 2009, an active monthly release line, a copyleft licence with an unusual two tier distribution arrangement, a real test and linting setup, and a community that includes both the people writing the code and the villages running it. The questions to settle before you depend on it are the licence and the premium split, and the guide at the project's documentation site is where the installation and usage instructions live.

Editorial conclusion

OpenSID serves Indonesian village information workflows. Compare the current public and premium offerings and review deployment, support, privacy and backup requirements before adoption. The repository's LICENSE includes GPLv3 text with inserted project-specific provisions; assess the actual terms and their applicability with qualified counsel rather than assuming the file is unmodified GPLv3.

Frequently asked questions

Official sources

1. Issues
2. OpenSID/OpenSID on GitHub
3. README
4. Releases