Jak ekonomicznie rozwija się oprogramowanie GNU?

Przepraszam, jeśli to pytanie jest nie na temat, ale jednocześnie jest to pytanie ekonomiczne i programistyczne. Jeśli powinien on przejść do innej wspólnoty SE, proszę wskazać mnie.

Teoretycznie oprogramowanie GNU jest w całości opracowywane przez wolontariuszy w czasie wolnym lub przez firmy, które dobrowolnie finansują programistów w celu opracowania oprogramowania GNU (poprzez wykorzystanie dochodów z innego sektora ich działalności).

Rozumiem, jak to może doskonale działać w przypadku projektów na małą skalę, które mogą być wykonane w kilka deszczowych weekendów przez pojedynczą osobę (powiedzmy na przykład grę sudoku), ponieważ w końcu programowanie komputerowe jest niezwykle zabawnym i satysfakcjonującym hobby, i nie mam problemu z widzeniem ludzi tworzących małe lub średnie programy w czasie wolnym i dzielących się nimi ze światem.

Problem polega na tym, że skaluje się wyjątkowo słabo w przypadku większych programów z następujących powodów:

1. Choć programowanie jest tak zabawne, że projekt, który trzeba wdrożyć, staje się większy, czas potrzebny do wdrożenia pożądanej funkcjonalności rośnie niezwykle szybko. Opracowanie programu na większą skalę zajmuje niewiarygodnie dużo czasu, na przykład może to zająć 15 lat wolnego czasu i urlopu dla osoby fizycznej na zaprogramowanie systemu operacyjnego, a do czasu wydania jego oprogramowania będzie całkowicie przestarzałe .
2. Podczas gdy inni piszą programy w inny sposób niż to, co byś zrobił, czytanie i rozumienie cudzego kodu zajmuje dużo czasu, w większości przypadków tak samo, jak pisanie własnego kodu od zera. Modyfikacja kodu innej osoby i próba jego ulepszenia, jak zachęca to filozofia GNU, jest prawie tak samo czasochłonna, jak opracowanie własnego klona wspomnianego programu z funkcjonalnością, którą chcesz dodać.
3. Gdy tylko 2 lub więcej osób będzie musiało współpracować, aby opracować większy program, powstaje wiele problemów związanych z podejmowaniem decyzji, które nigdy nie powstałyby w przypadku projektu jednego dewelopera. Rezultat jest taki, że na przykład, jeśli grupa 2 programistów współpracuje nad projektem, który zajęłby 10 lat dla jednego człowieka, nie zrobią tego za 5 lat, ale prawdopodobnie za 8.
4. Jeśli ludzie, którzy współpracują w ramach tego samego projektu, spotykają się wyłącznie w Internecie, łatwo jednemu z członków projektu może nagle zniknąć (albo dlatego, że stracił zainteresowanie, albo dlatego, że fizycznie nie może już być w Internecie), dzięki czemu współpraca nawet trudniej

Tak więc, choć doskonale rozumiem, jak proste programy można opracowywać w myśleniu GNU, absolutnie nie rozumiem, w jaki sposób tak duże programy, takie jak GNU / Linux lub gcc są możliwe w tym modelu. gcc to około 7 milionów linii kodu. Wiem, że wiersze kodu nie mają większego znaczenia, ponieważ na późniejszym etapie projektu bardziej produktywny programista to taki, który faktycznie usuwa wiersze kodu (upraszczając i / lub optymalizując projekt), ale daje to przegląd tego, jak ogromne jest jest gcc projektu.

Więc teoretycznie każdy może dowolnie modyfikować gcc w czasie wolnym, ale w praktyce? Został opracowany przez bardzo profesjonalnych ludzi jako praca, a nie hobby. Każdy, kto tworzy kompilator jako hobby, ostatecznie się podda, ponieważ koszt / korzyść nie jest tego warte:

• Opracowanie dużego programu to tak długofalowy ogromny projekt, że wolą spędzać wolny czas na innych zajęciach, które są bardziej satysfakcjonujące lub przyjemniejsze w krótkim okresie
• Gdyby mimo to opracowali duży program, woleliby to zrobić dla firmy, która je zapłaci, niż robić to za darmo

Aby zainteresować ludzi tworzeniem programu takiego jak GNU / Linux, gcc lub Open Office na dłuższą metę, powinno to być satysfakcjonujące. Więc moje pytanie brzmi: dlaczego ludzie wnoszą wkład w duży projekt GNU, skoro nie otrzymują za to wynagrodzenia?

Chciałbym zacząć od stwierdzenia, że ​​nie jestem programistą i nigdy nie brałem udziału w żadnym projekcie open source. Jednak od dłuższego czasu interesuję się open source i wierzę, że rozumiem ogólne koncepcje open source i jego działanie.

Na początek chciałbym powiedzieć, że open source nie oznacza, że ​​nie można zarabiać na oprogramowaniu. Oznacza to po prostu, że kod musi być publicznie dostępny. Firmy takie jak Red Hat i Canonical zarabiają nie poprzez sprzedaż oprogramowania, ale poprzez sprzedawanie swojej wiedzy specjalistycznej. Jeśli nie chcę, aby moja firma obsługiwała serwer Linux, mogę uzyskać oprogramowanie za darmo. Ale potrzebuję kogoś, kto go zainstaluje, skonfiguruje i zapewni wsparcie. Tutaj przychodzi specjalista np. Z Red Hat i zarabia pieniądze. Dla firmy ma to sens, ponieważ zatrudnienie własnego specjalisty byłoby prawdopodobnie znacznie droższe. To także zachęca te firmy do dodawania kodu. Chcą, aby ich produkt był dobry, aby ludzie mogli z niego korzystać i przez swoje usługi.

Ale pomówmy o twoich punktach dotyczących skalowalności.

1. Fajną rzeczą w open source jest to, że nie musisz rozwijać wszystkiego od zera. System operacyjny taki jak Ubuntu nie został zbudowany przez jedną osobę. Zamiast tego wiele osób przyczyniło się do różnych części systemu (tak naprawdę myślę, że trudno byłoby znaleźć jedną osobę posiadającą wszystkie umiejętności niezbędne do stworzenia i skutecznego systemu operacyjnego). Na przykład ludzie Ubuntu nie rozwijają jądra Linux. Używają tylko jednego opracowanego przez innych. Więc to, co było bez otwartego oprogramowania, prawdopodobnie niemożliwe, jest teraz możliwe, ponieważ możesz budować na pracy innych ludzi.

2. Czytanie i rozumienie innych nie zajmuje więcej czasu niż pisanie własnego. Przynajmniej nie w wielu przypadkach. Poza tym nie musisz rozumieć całego używanego kodu. Jeśli chcę napisać program dla systemu Linux, nie muszę rozumieć, jak szczegółowo działają wszystkie części tego programu. Muszę tylko wiedzieć, co oni robią. Następnie mogę wziąć te części i połączyć je z innymi częściami, aby utworzyć mój program. Albo mogę wziąć istniejący program i zmodyfikować go według własnych potrzeb.

3. narzędzia takie jak git i github sprawiają, że współpraca jest niezwykle łatwa. Po prostu dostajesz kod i modyfikujesz. Następnie przekazujesz je osobie odpowiedzialnej za projekt. Jeśli jest dobry, zostanie zaakceptowany.

4. ludzie cały czas wchodzą i wychodzą z projektów. Ale jeśli projekt jest popularny, wystarczy nad nim pracować.

Oto kilka powodów, dla których działa open source.

1. Myślę, że głównym powodem, dla którego oprogramowanie open source stało się tak dobre, jest to, że duża liczba osób pracujących nad projektem zapewnia poziom wiedzy, którą trudno zarchiwizować w małym zespole programistów. Choć może się to wydawać dziwne, ten pojedynczy fakt wydaje się przeważać nad wszystkimi negatywnymi problemami, które mogą pojawić się w otwartym oprogramowaniu.

2. W programowaniu komercyjnym projekt umiera wraz z firmą. Powiedzmy, że przez niektóre oprogramowanie firmy, która następnie zamyka. Potem wkręcasz się, ponieważ nie będziesz otrzymywać aktualizacji i poprawek błędów, a będziesz musiał przez nowe oprogramowanie, aby nadążyć. Dzięki oprogramowaniu typu open source możesz po prostu znaleźć inną firmę, która wesprze Twoje oprogramowanie lub sam je opracuje.

Jeśli nadal jesteś zainteresowany, sugeruję przeczytanie Katedry i Bazaru

Tworzenie oprogramowania typu open source odbywa się z różnych powodów, ale powszechne jest nieporozumienie, że dzieje się to przede wszystkim przez hobbystów lub profesjonalnie, ale jako projekt poboczny. Odpowiadam na to pytanie dotyczące ogólnie oprogramowania typu open source, a nie oprogramowania na licencji GNU. Ale moja odpowiedź jest włącznie.

Powiedzmy, że jestem programistą (jestem) i pracuję nad złożonym projektem oprogramowania (jestem). Dobra architektura dzieli problem na niezależne elementy, a w miarę rozwoju deweloperzy często rozpoznają, że potrzebny im kawałek jest wspólny dla wielu problemów. Oto kilka typowych ścieżek do przodu:

1. Sami opracowują ten kawałek i staje się on własnością firmy. Lub kupują rozwiązanie o zamkniętym źródle od innej firmy.
2. Znajdują projekt typu open source, który rozwiązuje ten problem i jest idealnie dopasowany, a licencja jest odpowiednia. Po prostu włączają go do swojego projektu, który może, ale nie musi, być typu open source, w zależności od licencji i sposobu jej wykorzystania. Nie wnoszą wkładu do projektu.
3. Znajdują projekt typu open source, który prawie rozwiązuje ten problem, ale ma wady lub braki. Udoskonalają go i mogą wnosić te ulepszenia z powrotem do projektu podstawowego.
4. Nie znajdują niczego, co im się podoba, więc rozpoczynają własny projekt i decydują się go otworzyć.

Zalety 2-4 polegają na tym, że więcej osób wnosi swój wkład zarówno w projekt, jak i kod projektu, i przechodzi w rodzaj ekosystemu, w którym przetrwają silne idee (poprzez prokreację), a słabe nie. Naprawianie błędów i dodawanie funkcji stają się wysiłkami społeczności. W scenariuszach 2 i 3 programiści przyjmujący projekt korzystają z rzetelnych zasad inżynierii i dojrzałego kodu. 3 i 4 są skorelowane. W scenariuszu nr 4 programiści odnoszą korzyści, gdy inne osoby przyjmują i ulepszają kod i oddają go (nr 3). Korzystne jest włączenie się z powrotem do projektu, aby Twoje ulepszenia zostały scementowane, gdy inne poprawki i ulepszenia będą nad nimi, z których nadal korzystasz. Z mojego doświadczenia wynika, że ​​wszystkie te scenariusze są powszechne.

W moim obecnym projekcie oprogramowania jestem jednym z około 12 programistów i pracuję nad systemem od około dwóch lat. Włączyliśmy około 5000 projektów typu open source! Stworzyliśmy tylko kilka nowych projektów FOSS i wnieśliśmy wkład z powrotem do około pół tuzina. W tym przypadku nie jesteśmy szczególnie dobrymi obywatelami (inne firmy są znacznie lepsze), ale pokazuje to samą skalę tego, jak to wszystko działa. Nawet w przypadku małych projektów wkład z oprogramowania typu open source może łatwo być liczony w dziesiątkach lub setkach. Gdybyśmy nie korzystali z oprogramowania typu open source, koszty rozwoju wzrosłyby 100–10 000 razy.

Skalowalność ma miejsce ze względu na modułowość projektu, a także dzięki tego rodzaju procesowi przetrwania najsilniejszego, w którym kod może zostać poddany refaktoryzacji, rozwidleniu itd. Przeżywalność jest zwykle lepsza niż zastrzeżone rozwiązania alternatywne, ponieważ nawet jeśli kod nie jest już utrzymywany, jest on dostępny, a inni ludzie, którzy znajdą w nim wartość, mogą zachować własne rozwidlenie. Firmy przychodzą i odchodzą, a pracownicy są zatrudniani i odchodzą jeszcze szybciej. Jeśli dodasz zależność od oprogramowania, której nie masz kodu źródłowego lub masz do utrzymania jedynie mały zespół wewnętrzny, ponosisz znaczne ryzyko. W dużych projektach, takich jak jądro Linux, gcc, Android i inne, często bierze udział duża liczba firm.

Nie jest prawdą, że łatwiej jest pisać dobry i poprawny kod niż go czytać (w większości przypadków). Nie musisz też czytać całego oprogramowania, którego używasz, nawet jeśli dokonujesz modyfikacji. Musisz głęboko zanurzyć się w jego części i dużo czytać, ale nie całość. Mógłbym powiedzieć tutaj więcej o testach jednostkowych, ale pominę to dla zwięzłości.

Większość oprogramowania typu open source nie jest rozwijana przez ludzi w wolnym czasie. Ta praktyka jest tak fenomenalnie korzystna, że ​​działa bez optymalizacji rynku. Osobiście podejrzewam, że jakieś podejście rynkowe bardzo by pomogło, ale nie wiem, jak mogłoby to wyglądać. Ludzie twierdzą, że istnieje rynek, na którym reputacja jest walutą, ale nie sądzę, że jest to dokładny model. Jedną walutą w pracy jest czas potrzebny na przyjęcie nowego oprogramowania. Chcesz znaleźć i używać czegoś, co jest aktywne, proste, ma dobrą dokumentację itp. Tak jak kupujący, szukasz produktu najlepszej jakości przy jak najmniejszym nakładzie czasu.