From Contributors to a Knowledge Network: What We’re Building in MyZubster

Open-source collaboration becomes much more interesting when a contribution is not treated as an isolated pull request.

What if a contribution could become:

• public evidence,
• a documented competence,
• a contributor profile,
• a Knowledge Card,
• a node in a knowledge graph,
• an input for another developer’s software,
• and eventually a bounty or internal reward with an auditable history?

This is the direction we are currently testing inside MyZubster.

Over the last few weeks, the project has moved from individual experiments toward something more interconnected: contributors are beginning to create work that can be linked together, reviewed independently, represented as structured knowledge, and reused by other parts of the ecosystem.

Two collaborations have been especially useful in showing how this can work:

• the work with Nicola / N4K48,
• and the newer contribution from khongten124.

This post explains what we have actually built, what is already merged, what is still experimental, and how contributor profiles, knowledge, software and rewards may fit together.

1. The original problem: contributions are often disconnected

A traditional open-source flow looks something like this:

issue
→ pull request
→ review
→ merge

That is useful, but it loses a lot of context.

A contributor may have demonstrated:

• research ability,
• technical writing,
• backend development,
• testing,
• data analysis,
• infrastructure knowledge,
• security awareness,
• or domain-specific expertise.

But after the merge, that knowledge often remains buried inside one PR.

MyZubster is experimenting with a different model:

contribution
→ evidence
→ competence
→ Knowledge Card
→ contributor profile
→ knowledge graph
→ project interoperability
→ optional bounty / reward

The goal is not to turn GitHub activity into automatic credentials.

The goal is to make real work easier to trace.

2. What we built with Nicola / N4K48

Nicola has been working on an independent software environment connected to the MyZubster ecosystem.

One of the important steps was creating a read-only bridge between Zorgax and Nicola Comics.

Two related pull requests have now been merged:

• PR #1460 — bridge explicit Nicola Comics requests
• PR #1461 — route natural-language Nicola Comics requests

These changes matter because they demonstrate a pattern that is larger than one feature.

Nicola can maintain his own software and his own project context, while MyZubster can interact with approved parts of that environment through a controlled interface.

The underlying idea is:

independent software
→ reviewed interface
→ limited data exposure
→ shared knowledge context

This is much closer to the architecture we want than simply putting everything inside one centralized application.

3. Independent contributor nodes

The Nicola work also helped us define a repeatable contributor pattern.

A contributor should be able to maintain:

• their own repository,
• their own local environment,
• their own evidence,
• their own project history,
• and, eventually, their own interoperable node.

In the N4K48 pilot, we documented a path involving Docker-based local operation, read-only flows, Git provenance and reproducible evidence.

That gives us a useful model:

developer machine
→ local node
→ public repository
→ test evidence
→ reviewed bridge
→ MyZubster Knowledge

This does not mean every contributor is automatically running a production decentralized node.

It means we now have a concrete architectural direction for letting contributors remain technically independent while still participating in the ecosystem.

4. A new contributor: khongten124

More recently, contributor khongten124 brought a different type of work into MyZubster.

Instead of focusing primarily on software infrastructure, the contribution focused on research, evidence structuring and Knowledge Cards.

The main work was developed around the Open Period Care pilot.

The contribution included:

• research questions,
• scientific and technical sources,
• evidence-to-requirement mapping,
• privacy and claim boundaries,
• Knowledge Cards,
• technical documentation,
• and a structured path for future verification.

This work was submitted through PR #1451 and has now been merged.

Two Knowledge Cards were included with carefully limited evidence states rather than exaggerated claims.

That distinction is important.

A Knowledge Card should not say “verified” simply because text exists in a repository.

The evidence state must reflect what has actually been demonstrated.

5. From documentation to machine-readable evidence

The collaboration then progressed further.

khongten124 created an Evidence Payload v1 for the Open Period Care / Circular Care path.

That work was merged through PR #1489.

The contribution included:

• a JSON Schema,
• a canonical machine-readable payload,
• structured provenance,
• privacy classification,
• evidence-state separation,
• deterministic hashing,
• and documentation explaining how Zorgax can navigate the evidence.

This is an important transition.

We moved from:

human-readable research

to:

human-readable research
+
machine-readable evidence

That means another software component can potentially reason over the contribution without losing its provenance.

6. Where Nicola’s software and the new contributor begin to connect

This is where the project becomes more interesting.

Nicola’s work demonstrated a model for independent software and reviewed interoperability.

khongten124’s work demonstrated a model for structured contributor evidence and machine-readable knowledge.

The next step is connecting those two patterns.

Conceptually:

Contributor A
creates software
        ↓
public evidence
        ↓
Knowledge Cards
        ↓
Knowledge Graph
        ↓
reviewed interface
        ↓
Contributor B software

A documentation bridge between the N4K48 evidence model and Open Period Care is already being developed in PR #1491.

That PR is still open, so I do not consider that integration complete yet.

But the direction is now concrete.

7. Contributors as knowledge nodes

This changes how I think about a contributor profile.

A profile should not just be:

name
bio
skills

Instead, it can become a navigation point for evidence.

For example:

Contributor
├── competence
├── project
├── accepted contribution
├── Knowledge Card
├── source PR
├── evidence state
├── related contributor
├── related software
└── future work

The profile becomes a knowledge guide.

Someone should be able to discover not only who a contributor is, but:

• what they actually worked on,
• where the evidence is,
• what level of verification exists,
• which projects depend on that knowledge,
• and what they could work on next.

8. Publishing contributor competences

We have also started publishing contributor competences.

This is an important distinction.

A competence should not be generated from a self-written claim alone.

The intended model is:

competence
← demonstrated contribution
← repository / PR / commit
← human review

For example, a contribution involving research design, evidence structuring and technical documentation can support a competence related to those areas.

But it should not automatically prove unrelated expertise.

This evidence-first approach is one of the core ideas behind the MyZubster Contributor Passport and profile system.

9. Profiles, Contributor Passport and Knowledge Cards

The profile layer is becoming the place where these elements can meet.

A contributor can potentially have:

• a GitHub-linked identity,
• a professional summary,
• competences,
• public project links,
• Knowledge Cards,
• Contributor Passport evidence,
• collaboration interests,
• and references to accepted work.

Publication remains under contributor control.

This is important because contribution evidence and personal identity are not the same thing.

A contributor may choose to publish:

GitHub alias + work evidence

without publishing private personal information.

10. Bounties as a coordination mechanism

Another part of this experiment is the bounty system.

A bounty can define:

• a specific objective,
• acceptance criteria,
• evidence required,
• funding state,
• review state,
• and eventual settlement state.

The important point is that a bounty should not simply mean:

do something → get money

A safer model is:

task proposed
→ contributor claims task
→ evidence submitted
→ maintainer review
→ acceptance
→ funding confirmed
→ settlement
→ settlement evidence

Those steps should remain separate.

11. Internal rewards without confusing money and competence

We are also exploring internal reward mechanisms.

But there is an important rule:

payment must never become proof of competence.

Likewise:

competence must never automatically imply payment.

These are separate evidence domains.

A contributor profile might show:

Contribution: accepted
Evidence: supported
Competence: demonstrated in project
Reward: proposed
Settlement: not funded

or:

Contribution: accepted
Reward: funded
Settlement: completed

This separation makes the system much easier to audit.

12. Why this matters for future collaboration

If this model works, MyZubster can eventually help answer questions such as:

• Who has actually contributed to this topic?
• Which evidence supports their competence?
• Which Knowledge Cards came from that work?
• Which software components use those cards?
• Which contributors are connected by related work?
• Which tasks are currently open?
• Which bounty is funded?
• Which reward has actually been settled?

That would turn a repository into something closer to a living collaboration graph.

13. A possible contributor journey

The workflow we are testing now looks roughly like this:

1. Discover MyZubster

2. Choose an issue or bounty

3. Work in your own repository / branch

4. Submit a PR

5. Provide reproducible evidence

6. Human review

7. Merge or acceptance

8. Create / update Knowledge Cards

9. Add competence to contributor profile

10. Connect profile to Contributor Passport

11. Link related contributors and software

12. Optional local node / interoperability path

13. Optional Marketplace offer

14. Optional bounty settlement

Not every contributor has to complete every step.

The system should remain modular.

14. The new relationship between contributors

This is one of the most valuable changes we are seeing.

Contributors are no longer necessarily working only “for MyZubster”.

They can begin working with each other through MyZubster.

For example:

• Nicola provides an independent software pattern.
• khongten124 provides structured scientific/evidence work.
• Zorgax can help navigate the resulting knowledge.
• the Knowledge Graph can connect their contributions.
• profiles can expose demonstrated competences.
• bounties can define the next missing work.

That creates a network effect around knowledge rather than only around code.

15. What is already real

At the time of writing, some concrete milestones include:

• Nicola Comics read-only Zorgax bridge merged
• natural-language Nicola Comics routing merged
• Open Period Care research package merged
• Knowledge Cards created and reviewed
• Evidence Payload v1 merged
• contributor evidence linked to public repositories
• contributor competences beginning to be published
• contributor profiles being connected to evidence
• bounty workflows being used for scoped tasks

These are real technical and documentation milestones.

16. What is still experimental

Some parts are intentionally still incomplete.

For example:

• full contributor-to-contributor node interoperability is still experimental,
• not every contributor profile is complete,
• not every competence has the same evidence maturity,
• bounty funding and settlement are separate from task completion,
• Marketplace competence listings are still evolving,
• the N4K48 ↔ Open Period Care knowledge bridge is still under review,
• and decentralized node communication still requires more end-to-end testing.

I think documenting these limitations is just as important as documenting the successes.

17. Why public profiles matter

The contributor profile may become one of the most useful interfaces in the ecosystem.

Instead of being a static résumé, it can act as a map.

A developer could open a profile and discover:

person / alias
→ competence
→ project
→ evidence
→ Knowledge Card
→ related contributor
→ bounty
→ next task

That turns identity into navigation.

And that is very different from a social profile based only on followers, likes or self-declared skills.

18. My long-term goal

My goal for MyZubster is not simply to build another developer platform.

I want to test whether open-source contributors can maintain their independence while still participating in a shared knowledge system.

Ideally:

independent people
+
independent repositories
+
independent software
+
verifiable evidence
+
shared knowledge
+
optional rewards

can become one interoperable ecosystem.

We are still early.

But the recent work with Nicola and khongten124 has shown that this idea can be implemented incrementally rather than remaining only a concept.

19. For developers who want to participate

If you want to contribute, the most useful approach is simple:

Choose a real problem.

Work publicly.

Provide reproducible evidence.

Be clear about what is tested and what is not.

Link your work to your profile and Knowledge Cards.

Let other contributors build on top of it.

That is the type of collaboration we want MyZubster to support.

---

MyZubster GitHub ecosystem:

https://github.com/MyZubster-Ecosystem/myzubster

My public GitHub profile:

https://github.com/myzubster

Open contributor / node discussion:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1474

Open Period Care contribution:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1451

Evidence Payload v1:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1489

Nicola Comics bridge:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1460

Natural-language Nicola Comics routing:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1461

Knowledge bridge currently in progress:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1491

If you're interested in open-source collaboration, independent nodes, evidence-first knowledge systems or contributor tooling, you're welcome to join the discussion.

Daniel Ioni

MyZubster