The central insight is understanding that promises are not obligations, and why and how that matters. From there, interesting things can be analyzed -- using types and contracts in a development team, unit tests, integration tests, specs, user interface and user experience, compliance, signaling, APIs, etc.
I think it is particularly useful now in the age of LLMs, agenic AIs, and autonomous robots that have to navigate spaces shared with humans.
Unfortunately I think it has been unappreciated and largely unknown, leading to people either re-inventing things already known, or, even worse, trying to create something that essentially contradicts the theory and results and therefore failing.
Promise theory isn't really about computation. It is about voluntary cooperation among agents. Agents, for the purpose of this semi-formal language, is defined as something that can make its own promises -- that is, communicate intent to a set of observers, some of whom might also be agents.
Promises are not obligations, and as such, the intent to do something is not the obligation to do something. There is no guarantee that the intent will be executed at all. Maybe other agents are actually doing this by best-effort. Sometimes external circumstances can trigger a failure. Sometimes the agent is not able to execute the promise well. Sometimes, the agent may deceive, and deliberately communicate an intent when it is intend to do something else.
How well an agent kept is promises is an assessment -- crucially, assessments are not global determination of an agent's ability to keep a promise. Each agent makes its own subjective assessment on how well another agent keeps its promises. Understood in this way, this can model both centralized and decentralized systems of voluntary cooperation.
Is the Thinking in Promises book too shallow or is it a good start?
I was working through "Promise Theory: Principles and Applications" and read through the first handful of chapters. For me at least, it was more accessible than math-heavy books. Yet, I can tell that it helped sharpened my reasoning ability about promises. I only made it through the first handful of chapters and yet it set a foundation that I was able to use over the years. Reading through some of the comments and reviews again, I see there are even more ideas that I could understand if I make my way through the book.
Just to add on to that. Beyond a promise, it's a contract, and someone has to be responsible and accountable for it.
Like when you're walking or driving and see a traffic light... you don't stop to wonder if there's a race condition or if another signal is out of sync. You trust it and act.
Unfortunately, it feels like in software today, promises are made... but rarely kept. And worse, most people just seem to accept that. If traffic lights were broken, we'd just need to upgrade to the next version right?
Hence why large businesses pay a lot of money to get guarantees in writing from reputable firms, even though the nominally same software may be available for free.
There's a loophole in that scenario, which is created by the fact that in FLOSS there is no clear distinction between users and mantainers. Meaning, the whole concept of FLOSS is based on community modifying and redistributing their own contributions, as a form of giving back to the community.
The same principle applies to wikis. You can take it or leave it, but the whole notion of a wiki lies on your ability to make it your own.
A simple "I put this up but please do not contact me" solves the problem.
A software license is not a social contract but that doesn't mean you can't bring some kindness and common sense to the situation.
It goes a long way if a "maintainer" simply states upfront about their mode of operation and sets expectations accordingly.
It doesn't mean you have to either. There's no social contract either way, so there's nothing to debate. Doing whatever you want is the correct thing to do regardless.
