Machinevertaling, niet beoordeeld door een moedertaalspreker. Engels is de referentie.

ProjectBewerken op GitHubBron: GOVERNANCE.md

Bestuur van Kshana

Dit document beschrijft hoe Kshana wordt bestuurd: wie beslissingen neemt, hoe, en wat het project wel en niet opneemt. Het is bewust licht, in verhouding tot de huidige omvang van het project, en is eerlijk over de huidige situatie met één beheerder en over het pad naar breder bestuur naarmate de gemeenschap groeit.

Missie en reikwijdte#

Kshana is een neutrale, reproduceerbare, eerlijk getoetste referentie voor de prestaties en veerkracht van hybride kwantum/klassieke PNT. De missie legt de lat voor elke beslissing: correctheid, bronvermeldingen en reproduceerbaarheid gaan voor breedte. De eerlijke reikwijdte is gedocumenteerd in docs/CAPABILITY.md en de validatiestatus in docs/VALIDATION.md; voorstellen worden gewogen tegen die reikwijdte, niet tegen het aantal functies.

Rollen#

  • Beheerder. Kshana wordt momenteel beheerd door de oprichter, Ashforde OÜ (contact: contact@ashforde.org). De beheerder neemt de eindbeslissing over reikwijdte, ontwerp, releases en wat wordt samengevoegd. Dit is een model met een welwillende beheerder, openlijk benoemd in plaats van verhuld als een commissie die niet bestaat.
  • Bijdragers. Iedereen die een issue of pull request opent. Bijdragen worden getoetst aan de drempel in CONTRIBUTING.md: herkomst voor elke numerieke parameter, validatie aan de hand van een gepubliceerde relatie en eerlijkheid over de rijpheid.
  • Toekomstige committers. Naarmate aanhoudende, hoogwaardige bijdragen daartoe aanleiding geven, worden commitrechten uitgebreid naar vertrouwde bijdragers en wordt dit document bijgewerkt naar een model met meerdere beheerders (beslissingen via lazy consensus, waarbij de groep beheerders meningsverschillen oplost). Tot die tijd is het pad: bijdragen, een staat van dienst opbouwen en worden uitgenodigd.

Hoe beslissingen worden genomen#

  1. Open discussie. Inhoudelijke wijzigingen beginnen als een GitHub-issue, zodat de motivering, de alternatieven en de afwegingen vastliggen.
  2. Lazy consensus. Een voorstel waartegen na redelijke tijd geen aanhoudend bezwaar bestaat en dat de technische drempel hieronder haalt, gaat door.
  3. De beheerder beslist bij onenigheid. Waar geen consensus wordt bereikt, beslist de beheerder en legt die de reden vast. Onenigheid wordt beslecht door de missie en de technische drempel, niet door anciënniteit of volume.

De technische drempel (niet onderhandelbaar)#

Dit zijn harde invarianten, afgedwongen door CI en review, die geen enkele beslissing opheft:

  • Reproducibility. (scenario, seed, engine_version) moet een run bit-voor-bit reproduceren. Een wijziging die dit niet-deterministisch maakt, is een bug, geen functie.
  • Herkomst. Geen anonieme numerieke constanten: elke parameter vermeldt een bron.
  • Eerlijkheid over validatie. Elke mogelijkheid is gelabeld als validated (tegen een onafhankelijke referentie) of als modelled / not modeled. Niets wordt beweerd buiten wat het bewijs toelaat. Zie de machinaal gecontroleerde matrix in src/verification.rs.
  • Hygiëne. Nergens in commits, inhoud of geschiedenis een vermelding van een geautomatiseerd hulpmiddel als auteur (afgedwongen door scripts/check-no-attribution.sh).

Een wijziging die de drempel niet kan halen, wordt afgewezen, hoe nuttig ze ook zou zijn.

De grens tussen open en gesloten#

Kshana is open-core. Deze repository is en blijft de volledige open AGPL-3.0-engine, de neutrale referentie, commercieel onder dubbele licentie gebracht door Ashforde OÜ (zie LICENSING.md). Het project neemt het volgende niet op in de open repository:

  • Exportgecontroleerde of dual-use-diepgang: echte dreigingsbibliotheken, golfvormen van tegenstanders of prestatieparameters tegen jamming/spoofing. De openbare repo houdt zich aan algemene, gepubliceerde modellen en methoden (zie CONTRIBUTING.md → Exportcontrole). Vraag het in geval van twijfel voordat u bijdraagt.
  • Vertrouwelijke gegevens of kalibratie van klanten of partners.
  • Copyleft-afhankelijkheden (GPL/AGPL/LGPL/MPL): niet omdat ze botsen met de eigen AGPL-licentie van de engine (dat doen ze niet), maar omdat ze niet kunnen worden herlicentieerd in de commerciële uitgave: we kunnen alleen een commerciële licentie verkopen op code die we bezitten of die permissief is. Een copyleft-afhankelijkheid zou de commerciële uitgave besmetten en de dubbele licentie breken. Afhankelijkheden blijven daarom permissief (Apache/MIT/BSD/ISC), afgedwongen door deny.toml.

Omgekeerd zal het project de open core niet uithollen om propriëtaire waarde te stimuleren: de engine die aan een onafhankelijke externe referentie is getoetst, de openbare validatieankers, het eerlijkheidsregister, het uitwisselings-/standaardformaat en de distributiekanalen blijven open. De open core uithongeren is de ene fatale fout bij open-core en die komt niet in aanmerking.

Releases#

  • Semantic Versioning. Vóór 1.0 kan het scenario-/resultaatschema veranderen; ingrijpende wijzigingen worden aangegeven, en de versie van het uitwisselingsschema (src/interchange.rs::SCHEMA_VERSION) is de enige bron van waarheid voor de compatibiliteit van artefacten.
  • Releasebevoegdheid. Publiceren (bijvoorbeeld cargo publish) is een handmatige stap van de beheerder waarvoor een registertoken nodig is. CI en de door een tag gestarte Release-workflow publiceren nooit automatisch naar externe registers: ze voeren alleen alle controles opnieuw uit en voegen een buildartefact toe. Zie CONTRIBUTING.md → Commits en versiebeheer.

Gedragscode en beveiliging#

  • Gedrag wordt geregeld door CODE_OF_CONDUCT.md.
  • Beveiligingsproblemen volgen het vertrouwelijke meldproces in SECURITY.md; open geen openbaar issue voor een kwetsbaarheid.

Handelsmerk#

De naam en het logo van Kshana zijn handelsmerken van Ashforde OÜ. De licentie (AGPL-3.0, of een commerciële licentie) geldt voor de code, niet voor de merken: een fork mag de code onder de licentie gebruiken, maar niet de naam Kshana of de canonieke distributie-identiteit. Zo blijft Ashforde de geciteerde bron van waarheid en dat is een deel van hoe de open core een neutrale referentie blijft.

Dit document wijzigen#

Wijzigingen in het bestuur worden zelf voorgesteld als pull request en beslist via het proces hierboven. Naarmate de schaal van het project verandert, mag u verwachten dat dit document een beslismodel met meerdere beheerders krijgt; de technische drempel wordt daarmee niet verlaagd.

Licht per ontwerp. Eerlijk over vandaag, met een benoemd pad voor morgen.