Dlaczego niektóre biblioteki open source nie zapewniają plików binarnych?

Dlaczego niektóre biblioteki open source nie zapewniają plików binarnych? Zauważyłem, że niektóre projekty odkładają się na strony trzecie, które utrzymują bieżące wersje oprogramowania, szczególnie dla wersji Windows.

Pytam, ponieważ wydaje się to barierą dla przyjęcia biblioteki. To więcej pracy dla programisty, ponieważ musi on skonfigurować swoje środowisko, aby je zbudować. Deweloper musi się również martwić, że wprowadził błędy, nieprawidłowo budując bibliotekę.

EDYCJA : Niektóre aktualizacje dotyczące komentarzy i odpowiedzi. Usunąłem przykłady, ponieważ nie są one kluczowe w dyskusji. Przeformułowałem również moje pytanie, ponieważ „niektóre biblioteki open source zapewniają” zamiast „biblioteki open source mają tendencję do dostarczania” ... nie zdawałem sobie sprawy, że ludzie będą się obrażać.

Ponieważ tworzenie plików binarnych dla systemu Windows to zupełnie inne zadanie, wymagające zupełnie innej bazy wiedzy i zestawu narzędzi. Wydaje się, że ludzie mają trudności z zrozumieniem tego o programistach Linuksa, więc pozwól mi to odwrócić.

• Używałeś systemu Windows do czegoś, co wydaje się wieczne.
• System Windows jest zainstalowany tylko w domu.
• Używałeś Linuksa tu i tam w pracy, ale tylko jako użytkownik, nie administrując ani nie rozwijając dla Linuksa.
• Wiesz, że gcc jest najczęściej używanym kompilatorem dla Linuksa, ale nigdy nie instalowałeś go na swoim komputerze.
• Pracujesz głównie nad oprogramowaniem dla systemu Windows, ale nie przeszkadza ci poprawianie błędów w systemie Linux, jeśli ktoś inny pracuje nad tym, aby był on kompatybilny i rozpowszechniał pliki binarne.
• Nie chcesz płacić za inny system operacyjny i zestaw narzędzi, gdy ktoś, kto już go ma, jest całkowicie skłonny do tworzenia kompilacji.

Kair to biblioteka, a nie aplikacja. Postgres wydaje się mieć pliki binarne Windows . Mniejsze projekty często nie zapewniają kompilacji, ponieważ nie mają infrastruktury / zasobów.

Jest to część filozofii open source: „jeśli chcesz coś zrobić, weź łopatę”. Oczywiście zmniejsza obciążenie programistów, jeśli użytkownicy po prostu sami skompilują program. Nie musisz się martwić wszystkimi architekturami, systemami operacyjnymi itp.

Ale jeśli tworzysz produkt na poziomie konsumenckim (Firefox, Paint.NET, Audacity, Keepass itp.) I zależy ci na pozyskiwaniu użytkowników, zawsze, zawsze, zawsze! obejmują pliki binarne. Prawdopodobnie tylko 2% osób, które natkną się na twoją stronę internetową i są zainteresowane twoim produktem, zamierza:

• Pobierz odpowiedniego klienta SCM
• Sprawdź całą kopię drzewa źródłowego
• Pobierz potrzebne narzędzia IDE lub kompilatora (łatwo kilkaset MB dla niektórych projektów)
• Pobierz i zainstaluj wszystkie potrzebne zależności (i ustaw zmienne środowiskowe)
• Uruchom świeżą kompilację (w niektórych projektach łatwo 10-minutowy proces)
• Radzimy sobie z wszelkimi błędami lub problemami lub pojawią się (które w małych projektach prawdopodobnie nie są udokumentowane - „o tak, najnowsze są w rzeczywistości przepisywane przez oddziały, a nie pień!”)
• Odinstaluj wszystko lub pozostaw to wszystko na komputerze i ponownie skompiluj w celu uzyskania aktualizacji.

(Oczywiście w systemie Linux rzeczy są znacznie zdrowsze, ale większość konsumentów nadal korzysta z systemu Windows).

Nowicjuszom jest o wiele łatwiej powiedzieć „och, wersja Windows! Pobierz. Uruchom”.

Jednak wiele projektów typu open source nie ma poziomu konsumenckiego; są skierowane do programistów, którzy mają znacznie wyższą tolerancję na tego rodzaju próby, więc pliki binarne to majsterkowanie. Z mojego doświadczenia wynika, że ​​programiści mogą być tak samo leniwi jak użytkownicy, więc ostrzegam. :)

Twórcy aplikacji napisanych w środowisku Write Once Compile Anywhere (C, C ++, itp.) Czerpią korzyści z przesunięcia kroku kompilacji do dystrybutorów (apt, rpm, yum itp.), Którzy tworzą i pakują pliki binarne dla popularnych architektur. Pozwala to uzyskać maksymalnie przenośną aplikację przy mniejszym wysiłku ze strony twórców i pozwala im poświęcić więcej czasu na skupienie się na ich podstawowych kompetencjach (rozwijaniu aplikacji, a nie kompilowaniu i hostowaniu jej dla wielu architektur). Niektórzy twórcy aplikacji WOCA są gotowi ponieść dodatkowy koszt w szczególnych przypadkach, takich jak Windows, ponieważ - no cóż - nikt inny tego nie zrobi, użytkownicy tego oczekują i nie chcą rezygnować z rynku.

Z drugiej strony aplikacje napisane w środowisku Write Once Run Anywhere (Java) lub dla określonej architektury docelowej (na przykład aplikacje OS X) są w stanie dostarczyć jeden plik binarny i często to robią, ponieważ muszą płacić tylko za kompilację kosztować raz.

Wreszcie, ich użytkownicy zazwyczaj czują się komfortowo, budując ze źródła lub używając menedżera pakietów systemu operacyjnego, więc ten model zapewnia również lepszą użyteczność. Użytkownicy wiedzą, skąd wziąć pliki binarne (menedżer pakietów), mają spójne doświadczenie w zakresie instalacji i zarządzania pakietami, a także wiedzą, gdzie uzyskać źródło, jeśli jest to potrzebne.

Dlaczego miałbym chcieć zwiększyć przepustowość, zapewniając kompilację (która oczywiście może być bardzo duża), a nie budować źródło, które i tak zapewniam? Nie wspominając już o tym, że zbudowanie projektu na własnej maszynie zawsze da lepsze wyniki, ponieważ jest skompilowane specjalnie dla Twojej platformy.

Mogę wymyślić dwa powody.

Po pierwsze, masz wiele systemów operacyjnych działających na wielu typach sprzętu; liczba binarnych celów, które musiałbyś zbudować, staje się niemożliwa do zarządzania. Istnieją trzy wersje systemu Windows nadal powszechnie używane (XP, Vista, 7) działające na sprzęcie 32-bitowym lub 64-bitowym; to 6 celów binarnych. Gorzej jest po stronie Linuksa, ze znacznie większą różnorodnością dystrybucji działających na Bogu wie, jaki sprzęt (x86, PPC, MIPS, SPARC, PA-RISC itp.). Czy zamierzasz budować dla każdej możliwej kombinacji? Czy masz do tego sprzęt i / lub oprogramowanie? Jeśli ktoś jeszcze tam działa (Boże, pomóż nam) NT na PII, czy zbudujesz dla nich plik binarny?

Po drugie, źródło wysyłki oznacza, że ​​użytkownicy mogą zoptymalizować kompilację pod kątem konkretnego środowiska; mogą włączyć wszelkie optymalizacje, których potrzebują, lub w razie potrzeby dostosować samo źródło.

Zazwyczaj wartość projektu typu open source, czy to aplikacji, systemu, modułu czy biblioteki, polega na tym, że można go badać i / lub modyfikować w razie potrzeby. Dystrybucja źródła jest nieodłącznym elementem modelu publikowania.

Dystrybucja pliku binarnego wiąże się z ryzykiem, że został zmodyfikowany w jakiś sposób w niecnych celach. Kompilowanie projektu ze źródła próbuje zminimalizować to ryzyko.

Może to mieć kilka przyczyn. Wiele (jeśli nie większość) projektów typu open source rozpoczyna się w systemie Linux. Tak więc początkowy projekt jest wykonywany dla tego systemu, a pakowanie jest wykonywane przez członków zespołu.

Tworzenie instalatora Windows to dodatkowa praca, która wymaga wiedzy, której mogą nie mieć programiści systemu Linux. Więc jeśli ktoś spoza podstawowego zespołu podejmie tę pracę, często jest o tym wspominany.

To samo może dotyczyć innych systemów, takich jak OS X, a nawet określonych dystrybucji Linuksa. Wszystko zależy od tego, kto ma wiedzę i czas na wykonanie dodatkowej pracy.