Open source jako dowód pracy

Artefakt, nie certyfikat

Publiczne repozytorium pozwala zobaczyć kod, historię zmian, testy i decyzje zapisane w dokumentacji. Nie dowodzi jednak samodzielnie, że system działał w produkcji, osiągnął efekt biznesowy albo został niezależnie zaudytowany.

Wartość repozytorium jako dowodu zależy od tego, czy odbiorca może przejść od twierdzenia do konkretnego pliku i od pliku do powtarzalnego uruchomienia.

Łańcuch dowodowy

1. Claim opisuje dokładnie to, co ma być widoczne.
2. README wskazuje wersję, zakres i komendę uruchomienia.
3. Test sprawdza właściwość, której dotyczy publiczne twierdzenie.
4. Historia zmian pokazuje, jak wynik powstał.
5. Ograniczenia mówią, czego repozytorium nie pokazuje.

Co ujawnia historia

Małe, opisane zmiany ułatwiają odtworzenie decyzji. Można zobaczyć, czy błąd został naprawiony testem, czy interfejs powstał przed kontraktem danych oraz gdzie następowały kompromisy.

Sama liczba commitów nie jest metryką jakości. Liczy się czytelność zależności pomiędzy problemem, zmianą i sprawdzeniem.

Ryzyko demonstracji

Repozytorium stworzone wyłącznie jako pokaz może omijać prywatne dane, integracje i awarie obecne w realnej eksploatacji. Odbiorca powinien odróżnić concept, prototype, pilot i production.

Praktyka publikacji

Najlepszy publiczny artefakt nie potrzebuje głośnego opisu. Potrzebuje wersji, instrukcji, testu, licencji, pochodzenia danych i jawnej listy ograniczeń.