One Person.
A Broken Laptop.
A Promise.

The Group Chat

Somewhere in a PhD WhatsApp group, among the usual clutter of announcements and article requests, someone posted a simple message: they needed a license key for a structural equation modeling tool. A commercial one. The kind that costs over a thousand dollars for a single perpetual seat.

Nobody was shocked. Within the hour, two more people had posted the same kind of request. One was looking for any working version, cracked or otherwise. Another mentioned their university couldn't afford the site license. A third had already graduated and lost access.

The tool they were asking about is widely considered the industry standard for PLS-SEM research. It is cited in tens of thousands of journal articles. Its name appears in the methods section of doctoral dissertations across every continent. And yet, in that group chat, the people who needed it most were quietly, politely begging for a crack.

This is not a rare or dramatic thing. It happens constantly, in academic groups everywhere. The licensing economics of research software have always punished the people at the bottom of the hierarchy — PhD students on stipends, independent researchers in lower-income countries, faculty at institutions without big library budgets. They need the tools to do the work. The work is how they prove their worth. But the tools cost what a month's salary costs. So they ask around.

I saw those messages and did not reply. I scrolled past. But I did not forget them.

The Resolve

The question that kept returning was simple and uncomfortable: if a free, legitimate, rigorous SEM tool existed, would those people have needed to ask?

The answer was no. And there was a follow-up: can someone build it?

The honest answer to that is harder. Building a credible alternative to professional research software means implementing PLS-SEM and CB-SEM correctly, validating outputs against published anchor values from peer-reviewed literature, shipping a usable interface that doesn't require a command line, and maintaining it. It is not a weekend project. It is months of evenings and early mornings and debugging sessions that end at 2 AM with a single broken test fixed.

I had done enough of those to know what I was signing up for. I signed up anyway.

The goal was never to build a clone. It was to build something that could genuinely be cited in a methods section — something a PhD student could use, reference, and stand behind without apology. Free. Open source. Archived on Zenodo with a citable DOI. Distributed through SourceForge so it would outlast any single hosting decision. Listed on AlternativeTo so it could be found. Available on the Microsoft Store so researchers on managed university machines could install it without administrator rights.

These were not marketing decisions. They were infrastructure decisions made for a specific person: the researcher who has no institutional budget, limited technical support, and a dissertation deadline.

The Professor

Before I can make this purely about altruism, I have to be honest about something else.

In 2013, I was a student in an Information Systems Management course. The professor was knowledgeable and, I think, experienced enough to know better than to judge a piece of work by who submitted it. And yet.

I remember the particular quality of attention that settled on the author line before the content. The way a name — my name — could create a frame around the work before the work was even read. That kind of pre-judgment is not always hostile. Sometimes it is simply a lowering of expectation so slight that the person doing it might not even register it. But the person on the receiving end always does.

I carried that knowledge forward. The feeling of having work assessed through a filter that the work itself had no power to remove. The only real answer to that kind of judgment is to produce something undeniable. Not better than expected — simply undeniable. Something that makes the question of who secondary to the question of what.

NAVAL-SEM is partly that. It is software that runs against published benchmarks. It either matches the literature or it does not. The 174 tests in the release gate do not care what name is on the repository. The Bollen CFI is either 0.997 or it isn't.

The Laptop

There is nothing glamorous about building software on a broken laptop. The fan runs too loud. There is a key that only registers when you press it at an angle. The screen flickers during heavy computation — exactly the kind of computation that takes the longest to debug. You learn to save before every test run.

Nobody donated. Not once. The project got forked — which tells you something about perceived value — but the forks did not come with PRs or fixes or even a kind word in the issues. People copied the idea and the approach without contributing back. People criticized the name before they had read the documentation. A professor who once looked past my name now looked past my work.

I want to be clear-eyed about this rather than bitter: none of it was unusual. Open source software built by individuals who are not yet famous exists in a strange space where it has to prove itself every day just to be taken seriously, while simultaneously producing results that justify the attention it hasn't received yet. The bootstrapping problem is real. You need credibility to earn credibility.

The only way out of that loop is to keep building until the work speaks clearly enough that the loop breaks. Not through volume or noise, but through accumulation. Each release that shipped. Each test that passed. Each validated anchor value. Each version that didn't break what came before.

The laptop is still broken. The software is not.

The Infrastructure

Software that exists only on GitHub is invisible to most of the people who need it. This is not a criticism of GitHub — it is a fact about how researchers find tools. They search app stores. They look for listings on software directories. They trust things that have DOIs. They share links to pages that load fast and explain clearly what the tool does.

Building the distribution infrastructure took nearly as long as building the core functionality.

Each of these required filling out a form, navigating a policy page, waiting for an appeal, or writing an explanation. None of them are technically interesting. But all of them are necessary if the goal is actually to reach the person who was quietly asking for a license key in a WhatsApp group at 12:16 on a Tuesday.

v1.0

The roadmap was written early and it was specific. Not a collection of vague aspirations but a dependency-ordered feature list: measurement models before validity checks, validity checks before robustness methods, robustness methods before scale development, scale development before fsQCA and reporting. One thing had to be correct before the next could be built on top of it.

That specificity was the only thing that made it survivable. When you are building alone, with no external deadlines and no one checking your progress, the roadmap is the discipline. It tells you what comes next when you no longer have the energy to decide.

On the 27th of June 2026, POST /fsqca passed all its tests. POST /report generated a correctly-formatted APA 7th edition Word document. The schema freeze was applied to every public result model. The release pipeline ran. The tag pushed. The version string in the health endpoint read 1.0.0.

There was no one to tell. The only notification was the GitHub Actions green checkmark and the SourceForge deployment completing without errors. I closed the terminal and went to sleep.