Czy otwarta licencja kodu automatycznie czyni projekt otwartym? Coraz częściej widać, że nie – znaczenie ma też otoczka społeczna i kultura organizacyjna. Simon Phipps, programista i aktywista OSI związany między innymi z rozwojem Javy, zaproponował jak oszacować stopień otwartości na poziomie całego projektu.
Zaczął od swojego podwórka, jako były członek przejściowej rady OpenJDK. Jej nowy, świeżo przedstawiony model otrzymał -3 punkty. To mało, ponieważ zaproponowana skala rozciąga się od -10 do +10 punktów. Najważniejsze jest w niej jednak to, że Phipps opracował standardowy formularz z kryteriami oceny, co umożliwia w miarę obiektywny sposób przyznawania punktów, a zwłaszcza porównywania projektów.
Licząc wedle tego samego szablonu ocenił LibreOffice na 5 punktów, a Eclipse wystawił aż 8 punktów. Autor zachęca do przysyłania danych na temat innych projektów, aby dla nich także określić wskaźnik otwartości.
Wniosek jak się nasuwa to taki, że jeśli zaczynamy się zastanawiać nad szacowaniem stopni otwartości projektów to czas najwyższy znaleźć sobie dziewczynę, a jeśli to niemożliwe to przynajmniej adoptować kolejnego kotka.
Bardzo pospieszny ten wniosek, tak samo jak leżące pod nim założenie, że to sztuka dla sztuki. Przykład wieloletniej inercji organizacyjnej OOo wskazuje, że ma to bardzo praktyczne znaczenie.
A można chłopaka albo pieska?
Zgadzam się, że skala jest trochę dziwna ale nie chcę też krytykować czyjegoś zaangażowania. Może komuś się takie narzędzie przyda. Dla mnie nie ma to aż takiego znaczenia, jeżeli kod jest dostępny na odpowiedniej licencji to wiem co i jak (otwartość zresztą nie jest dla mnie celem samym w sobie, ale nie powiem żebym nie lubił otwartych projektów).