MyZubster Space Station: from MVP to a Transparent Open-Source Bounty Workflow
Open-source projects need more than code.
They need a way for contributors to understand what needs to be built, how work is verified, and when a reward has actually been paid.
That's the direction we're taking with the MyZubster Space Station project.
The current project is an experimental software MVP focused on simulation, telemetry, APIs and dashboards. It is not a claim that we have built a physical space station or operational space hardware.
The goal is to build the software foundation first — and make the development process itself as transparent as possible.
What exists today
The Space Station repository currently contains an MVP architecture around:
Space Station Core
robot/mission API
telemetry ingestion
Eva Ioni simulator
web dashboard
Gateway integration
payment integration experiments
The Eva Ioni simulator can generate telemetry such as temperature, humidity and battery information and send it to the telemetry API.
The dashboard can consume telemetry and display it to the user.
The backend provides API endpoints for missions, telemetry and payment records.
These are software prototypes. They should not be confused with production aerospace systems.
From documented bounty to public GitHub issue
One thing we discovered while reviewing the project was that the original documentation listed five bounty items:
Bounty Work Reward
001 Eva Ioni Simulator 250 MYZ
002 Telemetry System 250 MYZ
003 Dashboard UI 250 MYZ
004 Gateway API 250 MYZ
005 MYZ/XMR Payments 250 MYZ
Originally, these were described in the project documentation but were not backed by corresponding GitHub issues in the Space Station repository.
Rather than leaving the bounty system ambiguous, we decided to formalize the work publicly.
The five tasks are now tracked through GitHub issues in the main repository:
390 — Eva Ioni Simulator
391 — Telemetry System
392 — Dashboard UI
393 — Gateway API
394 — Payments
Each issue contains acceptance criteria, scope, verification requirements and the declared bounty.
This gives contributors a much clearer workflow.
The important distinction: merged does not mean paid
We are also introducing a strict distinction between development status and payment status.
A bounty should follow a process like:
AVAILABLE
↓
CLAIMED
↓
IN PROGRESS
↓
PR OPEN
↓
REVIEW
↓
MERGED
↓
PAYMENT PENDING
↓
PAYMENT VERIFIED
A merged pull request is evidence that the software work was accepted.
It is not automatically evidence that the contributor was paid.
For a bounty to be marked as paid, we want a separate, verifiable payment record.
Why this matters
This is especially important for cryptocurrency-related projects.
A statement such as:
"This bounty was paid."
is much less useful than:
Issue: #XXX
Contributor: @username
PR: #YYY
Amount: XXX
Currency: XMR
Network: mainnet
Transaction:
Status: CONFIRMED
The objective is to make the payment independently verifiable whenever the underlying payment system supports it.
MYZ and XMR are not the same thing
Another point we want to make explicit is the distinction between MYZ and XMR.
XMR is Monero.
If MYZ represents a project-specific accounting unit or token, it must not be presented as though it were Monero.
For any future real token/payment implementation, the project should document:
network;
asset/token identifier;
wallet/address format;
transaction mechanism;
transaction explorer;
verification procedure.
Until that information is available, simulated or internal payment records should be labelled accordingly.
What we are looking for
The five current bounty issues are intended to attract contributors who want to improve the software itself.
The most useful contributions are not necessarily large.
A good contribution might be:
improving telemetry validation;
adding tests;
making the simulator configurable;
improving dashboard reliability;
implementing Gateway integration;
improving documentation;
implementing verifiable payment infrastructure.
Every contribution should be reproducible and reviewable.
What "Space Station" means here
The name can easily create the wrong impression, so let's be explicit.
This repository does not represent a deployed space station.
It is an experimental software environment for:
simulation + telemetry + APIs + dashboards + future robotics integration.
The long-term vision may include more advanced robotics and space-related simulations, but those are future engineering goals, not claims about currently operational hardware.
The experiment
The interesting experiment is therefore not:
"Can we claim to have built a space station?"
It is:
Can an open-source community progressively build the software infrastructure through publicly verifiable contributions and rewards?
That's a much more useful question.
The next milestone is simple:
Get an independent contributor to claim one of the bounty issues, submit a PR, have the work reviewed and merged, and then demonstrate the payment process transparently.
If that workflow works, we have something much more valuable than another README claiming that everything is "complete".
We have a reproducible open-source development process.
Follow the work
The project is open source and contributions are welcome.
The five current bounty tasks are tracked publicly in GitHub:
390 — Eva Ioni Simulator
391 — Telemetry System
392 — Dashboard UI
393 — Gateway API
394 — Payments
Status matters. Evidence matters. And a bounty is not considered paid until the payment can actually be verified.
That's the standard we're going to use going forward.
Tag suggeriti su DEV
opensource · javascript · robotics · monero · webdev
Top comments (0)