Zbyt wcześnie wypuszczanie oprogramowania typu open source [zamknięte]

Jaka jest moralna odpowiedzialność za zbyt wczesne wydanie oprogramowania typu open source? Na przykład produkt prawie kompletny, który nie został w pełni przetestowany.

Czego oczekuje programista? Poczekać, aż zostanie w pełni przetestowany, czy wydać wersję open source, a następnie kontynuować rozwój, testowanie i postępy?

Istnieje obawa, że ​​oprogramowanie jest otwarte i może potencjalnie powodować problemy dla konsumentów.

Czy to nieuzasadniony strach?

Uważam, że wręcz przeciwnie, należy jak najszybciej wydać oprogramowanie typu open source. Nie ma na to „za wcześnie” (ale powinno się skompilować).

^{Lub przynajmniej publikuj kod źródłowy bardzo wcześnie i ciągle (np. Przez częste wypychanie na github ), bez formalnych wydań.}

Jednak bardzo ważne jest, aby oznaczyć go jako etap alfa lub beta i, jeśli to możliwe, powiedzieć (np. W pliku READMElub TODO, a także na blogu itp.), Czego brakuje, nie przetestowano lub jest w złym stanie. Należy również użyć numeru wersji, aby przekazać takie informacje.

W przypadku bezpłatnego oprogramowania najlepsze, co powinno się zdarzyć, to to, że ktoś zajrzy do kodu źródłowego i zaproponuje małą poprawkę. Dlatego czynisz swoje oprogramowanie darmowym!

^{Dlatego musisz uwidocznić swoją codzienną pracę nad bezpłatnym oprogramowaniem! Współtwórcy zewnętrzni byliby wkurzeni, gdyby ich łatka nie współpracowała z twoim ostatnim kodem źródłowym oprogramowania lub jest jego duplikatem.}

To, czego powinieneś się obawiać, to to, że nikt nie zainteresuje się twoim oprogramowaniem (i nie przyczyni się do niego). Przyciąganie zewnętrznego zainteresowania wolnym oprogramowaniem (w szczególności przyciąganie zewnętrznych współpracowników) to długa podróż.

TL; DR:

Zwolnij wcześniej. Zwolnij często.

Osobista anegdota:

Byłem bardzo podekscytowany projektem, nad którym pracowałem. Bardzo podekscytowany. Nie mogłem spać w nocy podekscytowany. Więc pchnąłem mojego współtwórcę do wydania wersji 1.0 szybciej, niż chciał.

To było okropne. Nic nie działało tak, jak powinno. Błędy występowały na każdym kroku, ale zarejestrowaliśmy je i naprawiliśmy. Mieliśmy nawet kilku wczesnych użytkowników, którzy zgłaszali błędy, których mogliśmy nie znaleźć. Tydzień lub dwa później wydaliśmy nową wersję, która rozwiązała wiele problemów, a następnie wróciliśmy do tworzenia nowych funkcji.

Wcześniejsze wydanie było najlepszą rzeczą, jaką mogliśmy zrobić. To stawia nasz produkt przed prawdziwymi użytkownikami. Robiąc te ujawnione błędy, mogliśmy znaleźć lub ulepszyć nasz projekt. Informuje również tych pierwszych użytkowników, że poważnie podchodzimy do tego projektu. Będzie więcej wydań i aktywny rozwój.

Mogłoby to jednak łatwo pójść w drugą stronę. Mogliśmy zignorować te zgłoszenia błędów. Albo nie moglibyśmy zareagować szybko. Mogłoby to być inna historia, gdyby wydanie wersji 1.1 zajęło nam 3 miesiące zamiast kilku tygodni.

Jest tak samo, jak w przypadku oprogramowania o zamkniętym źródle. Komunikacja jest ważna.

Poinformuj użytkowników, jaki jest stan oprogramowania i dlaczego jest on dostępny do pobrania.

Oprogramowanie zawsze prowadzi do problemów klientów, bez względu na to, czy jest w pełni przetestowane, czy nie. Większość klientów akceptuje ten fakt, a niektórzy klienci nigdy. Ale jeśli oprogramowanie spowoduje więcej problemów, niż można się spodziewać, istnieje moralny obowiązek poinformowania klienta o podejmowanym przez niego ryzyku. Informacje powinny być zarówno w formie skróconej (etykiety „Alpha / Beta / EarlyAccess”) *, a szczegółowo: Lista znanych problemów, obejść i specjalnych uwag, np. Jeśli istnieje prawdopodobieństwo, że dane mogą zostać uszkodzone.

* Należy pamiętać, że niektóre duże firmy programistyczne wyszkoliły użytkowników, aby myśleć o „Beta” jako o stanie, w którym oprogramowanie jest dość solidne, dlatego informowanie użytkownika, że ​​oprogramowanie to „Beta”, często nie jest wystarczającą informacją.

Nie ma żadnej moralnej odpowiedzialności. Nikt nie jest zmuszany do korzystania z na wpół upieczonego oprogramowania.

Jedyną rzeczą, o którą należy się martwić, jest twoja wiarygodność.

Z mojego doświadczenia wynika, że ​​należy osiągnąć równowagę.

W tej chwili pracuję (w sensie odpowiadania na pytania i dostarczania sugestii programistycznych, nie widząc żadnego kodu) z programistą, który tworzy coś, co wygląda na bardzo ekscytujący projekt FOSS, który wykorzystuje napisany przeze mnie kod. Publiczne wydanie było kilkakrotnie opóźniane przez wprowadzenie zmian w projekcie, które znacznie poprawią projekt w perspektywie długoterminowej, ale wymagają znacznych przeróbek kodu, który już został napisany i już działał. Moim zdaniem, gdyby działająca, ale niedoskonała wersja została wydana, gdy tylko pojawiło się coś do pokazania, pomysły na zmiany (i faktyczne łatki) mogły pochodzić od szerszej społeczności, która jest zainteresowana tym projektem, przyspieszając go, a nie mając problemy pojawiają się powoli, pojedynczo, tak jak myśli o nich deweloper i prosi o opinie zwrotne ode mnie i innych zainteresowanych członków społeczności. Z tego punktu widzenia jestem zwolennikiem „wczesnego wydania, częstego wydania”.

Z drugiej strony, wydania niskiej jakości mogą sprawić, że nowy projekt będzie wyglądał źle, zanim jeszcze powstanie. Niektóre pułapki, które widziałem to:

• Szkielety z definicjami interfejsów, ale bez kodu.
• Kod, który nie kompiluje się pomyślnie dla nikogo oprócz programisty.
• Brak instrukcji jak zbudować / uruchomić program.
• Brak dokumentacji dotyczącej tego, jakie aspekty można oczekiwać.
• Niejasny opis tego, co program nawet robi lub zrobi.
• Brak jakiegokolwiek wykazania przydatności.

W ostatnim punkcie myślę o takich rzeczach jak:

• Kompilator / interpreter, który nie potrafi nawet skompilować / uruchomić programu typu hello-world.
• Emulator, który nie może przynajmniej uruchomić przykładowego programu lub w inny sposób wykazać, że coś robi.
• Narzędzie do przetwarzania obrazu, które nie może zrobić nic innego, jak załadować i ponownie zapisać niezmodyfikowany obraz.
• Gra bez ekranu tytułowego.

Tego rodzaju problemy sprawiają, że obraz „vaporware” może być trudny do potrząśnięcia, chyba że jesteś bardzo otwarty na temat braku działającego kodu na początek.

Wreszcie, nadaj swoim numerom wersji sens. Nie nazywaj swojego projektu „1.0”, dopóki nie zrobi tego, czego oczekują użytkownicy bez awarii. Zawsze miałem szczęście używać numerów wersji około „0,5” do pierwszego publicznego wydania i stamtąd, ale widziałem też takie rzeczy jak „0.1” lub „0.10”, które mają sens.

Istnieje jeden przypadek, w którym wydanie wolnego oprogramowania może mieć negatywne konsekwencje. Niektóre specyfikacje są publicznie licencjonowane pod warunkiem, że wszystkie implementacje rozpowszechniane publicznie będą całkowicie zgodne ze specyfikacją przy pierwszej publikacji. Wydawca prawnie zabrania rozpowszechniania implementacji specyfikacji w toku. Bez konkretnej wynegocjowanej licencji od wydawcy specyfikacji musisz udostępnić ją nikomu, dopóki nie przejdzie wszystkich testów. Wymusza to „model katedralny” (jak to nazwał Eric S. Raymond) przy implementacjach specyfikacji.

Jedną specyfikacją w ramach takiej licencji jest specyfikacja języka Java . To ograniczenie dotyczy twórców maszyn wirtualnych zgodnych z JVM, ale na szczęście nie twórców aplikacji działających w JVM.

W artykule „ 4 zmienne szczegóły na temat„ Open Source ”.NET Microsoftu autorstwa Liu Qihao i Ciarana O'Riordana wspomina się o możliwości interpretacji obietnicy patentowej Microsoft dla bibliotek .NET i komponentów wykonawczych w celu wykluczenia niepełnych implementacji CLR w podobny sposób . Ale znowu nie dotyczy to aplikacji działających w CLR.