Dlaczego NIE otwierać kodu non-profit typu open source? [Zamknięte]

34

Jestem wielkim fanem kodu open source. Myślę, że rozumiem większość zalet korzystania z oprogramowania typu open source. Jestem studentem nauk ścisłych i muszę pracować z dość zaskakującą ilością oprogramowania i kodu, które nie są oprogramowaniem typu open source (albo jest zastrzeżone, albo nie jest publiczne). Naprawdę nie widzę dobrego powodu i widzę, że kod i ludzie, którzy go używają, z pewnością skorzystaliby na upublicznieniu (jeśli nic innego, w nauce ważne jest, aby w razie potrzeby można było powielić wyniki, i jest to o wiele trudniejsze, jeśli inni nie mają dostępu do Twojego kodu).

Zanim wyjdę i zacznę prozelityzm, chcę wiedzieć: czy istnieją jakieś dobre argumenty za tym, aby nie publikować publicznie kodu organizacji non-profit i mieć licencję zgodną z OSI?

(Zdaję sobie sprawę, że wokół jest kilka podobnych pytań , ale większość skupia się na sytuacjach, w których kod służy przede wszystkim do zarabiania pieniędzy, a odpowiedzi nie były zbyt istotne).

Wyjaśnienie:Nienastawione na zysk” włączam motywy związane z zyskiem, takie jak rozpoznawalność marki firmy macierzystej i oczekiwania zysku inwestorów. Innymi słowy, pytanie dotyczy tylko oprogramowania, dla którego nie ma ŻADNEGO motywu zysku związanego z oprogramowaniem.

naught101
źródło
+1, gdy uważam to za interesujące pytanie. Ale zastanawiam się, czy jest to właściwe miejsce, aby o to zapytać. Być może uzyskasz inne perspektywy od innych witryn SE, takich jak strona PM.SE. Tylko sugestia.
haylem
@haylem, nie widziałem PM.SE, ale wygląda na to, że dotyczy to bardziej technicznych aspektów zarządzania projektami?
naught101
Czy później aktywnie utrzymasz projekt, czy jest to cmentarz kodowy? Innymi słowy, jaka jest przyszłość projektu.
@ ThorbjørnRavnAndersen: tak, zakładam aktywne utrzymanie, rozwój i użycie kodu.
naught101

Odpowiedzi:

28

Musisz wziąć pod uwagę, że otwarty dostęp do kodu może wymagać dodatkowego wysiłku.

Jako przykład, w tym wpisie na blogu inżynier Sun / Oracle opisuje wysiłki, jakie musieli podjąć, gdy open source pozyskiwał swój kod: Open Source czy Dirty Laundry?

Gdy przygotowujemy się do nurkowania w świecie open source, jednym z wielu działań, które mają miejsce, jest przygotowanie kodu do otwartego dostępu. Jest kilka oczywistych rzeczy, które należy zrobić. Na przykład nasz kod źródłowy zawiera mieszankę kodu, który napisaliśmy, oraz kodu, na który mamy licencję od innych. Będziemy musieli wyodrębnić ten ostatni i open source tylko odpowiednie fragmenty kodu.

Kolejnym działaniem przygotowawczym jest „szorowanie” kodu zastrzeżonych informacji, wzmianki o konkretnych klientach, programistach, technologiach itp. Jest to nieco mniej oczywiste, ale rozważ następujący przykład:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Chociaż wszystkie powyższe kwestie mogą być prawdziwe, prawdopodobnie mamy jakiś związek z Intertrode Tech, a umieszczanie takich komentarzy w kodzie może w jakiś sposób zaszkodzić naszej działalności i dlatego należy ją usunąć. Prawdopodobnie nie powinien był tam być, ale teraz nadszedł czas, aby go wyjąć.

Inną częścią działania „szorowania” jest usuwanie wulgaryzmów i innych „niepożądanych” słów ...

Zauważ, że wszystkie powyższe zmiany musiały zostać wprowadzone w kodzie, który został uznany za całkowicie OK jako zamknięte źródło - co sprawia, że ​​jest to dodatkowy wysiłek .

komar
źródło
2
Dotyczy to dużych firm z istniejącą bazą kodu, a tym bardziej kodu napisanego od podstaw jako Open Source.
Konrad Rudolph
1
@KonradRudolph OP wspomniał, że muszę pracować z ... kodem, który nie jest open source (albo jest zastrzeżony, albo nie jest publiczny), co oznacza, że ​​nie był tam od zera
gnat,
Czy to samo nie stało się z DOOM 3? Wydanie patentu
opóźnia
11

Bezpieczeństwo.

Załóżmy na przykład, że budujesz framework internetowy i sam go używasz.

Jako projekt non-profit nie miałeś czasu poświęcić na sprawdzenie każdego fragmentu kodu pod kątem podatności na taki lub inny atak:

  • CSRF
  • XSS
  • Wstrzyknięcie SQL
  • Utrwalanie sesji
  • Korzystanie z błędnych bibliotek stron trzecich, a nawet języków

Teraz, mając projekt open source, pozwalasz przyjaznym oczom wnieść swój wkład, ale również pozwalasz złośliwym oczom na pełny wgląd w twoją pracę, a jeśli znajdą serwer, na którym działa twój kod, wyeliminowałeś możliwość ukrywania swojego niedoskonałości w zaciemnieniu.

Oczywiście może to nie dotyczyć rodzaju oprogramowania, nad którym pracujesz; i jak zawsze niejasność nie usprawiedliwia lenistwa w bezpieczeństwie.

Jednak, tak jak znalazłem na kilku poziomach, przez które przeszedłem w grze Stripe capture the flag game , wiedząc, że kod jest jednym z najłatwiejszych sposobów na znalezienie luk (i czasami może to być jedyny sposób).

Nicole
źródło
7
Ta debata trwa od wieków i mam wrażenie, że open source jest lepszy dla bezpieczeństwa, ale tylko wtedy, gdy projekt jest dość popularny (przynajmniej wśród deweloperów). Dziwne, że nigdzie w sieci nie ma naprawdę dobrej analizy argumentów (którą i tak mogę znaleźć).
naught101
1
W połączeniu z komentarzem naught101s ma to sens. Jeśli mniej ludziom zależy na twoim źródle, a ty używasz go w produkcji, są całkiem spore szanse, że ktoś „zło” to sprawdzi i użyje przeciwko tobie (ostatecznie)
schlingel,
1
Bezpieczeństwo dzięki niejasnościom?
Danubian Sailor
3
@lechlukasz Czy przeczytałeś nawet cały post?
Nicole,
1
@Oleksi Dzięki, ale ja to wiem. Powiedziałem: „niejasność nie usprawiedliwia lenistwa w bezpieczeństwie”. To pytanie nie dotyczy otwartego kontra zamkniętego, lecz otwarcia wcześniej zamkniętego systemu. Zdarza mi się całkowicie zgodzić z linkiem, który opublikowałeś, ale programiści nie są idealni, a kiedy otworzysz system, istnieje szansa, że ​​pierwsi użytkownicy, którzy znajdą błąd, wykorzystają go zamiast go naprawić.
Nicole,
10

Dobrym powodem, aby nie otwierać źródła, jest to, że niektóre z Twoich źródeł mogą być chronione prawami autorskimi. Jak często nie przeszukujesz sieci w celu szybkiego rozwiązania problemu i po prostu weź znaleziony fragment kodu?

Cóż, mogą być chronione prawem autorskim i nie wiem, czy autor chciałby znaleźć licencję na swój kod na innej licencji.

Pieter B.
źródło
1
+1 za prawa autorskie. Chciałem tylko dodać patenty. Możesz po prostu dowiedzieć się, że twój projekt typu open source narusza niektóre z tysięcy patentów na oprogramowanie zamieszkiwane przez „korpus”. Streaming wideo? Patentowany. Reklamy pay-per-click? Patentowany. Tylko kilka przykładów. Jednak są szanse, że „korpus” nie ma znaczenia - chyba że jesteś konkurentem.
Amadeus Hein,
1
Hehe To nie jest tak naprawdę argument przeciwko open source, ale przeciwko piractwu. Ale masz rację, założę się, że jest to problem związany z dużym prywatnym kodem.
naught101
1
@ naught101 Agreed. Otwarte źródło ujawnia tylko problem. Zamknięta własność w tym przypadku polega na tym, by nie dać się złapać;)
Andres F.
Mówisz, że jednym z powodów, dla których źródło powinno być zamknięte, jest umożliwienie ci ukrycia przypadkowych naruszeń praw autorskich? Czy nie sądzisz, że to raczej nieetyczny powód do korzystania?
Mark Booth
1
Nieetyczne… może z pewnością bardzo dobry powód, aby nie otwierać kodu źródłowego.
Pieter B
6

Musisz ostrożnie wybierać licencję, aby uniknąć potencjalnych problemów z odpowiedzialnością.

Prawnik może być lepszą osobą, z którą można porozmawiać na ten temat, ale ogólną ideą jest to, co się stanie, jeśli ktoś użyje (lub niewłaściwie użyje) aplikacji i spowoduje to pewne szkody? Jesteś odpowiedzialny? Oczywiście będzie to zależeć od rodzaju oprogramowania, które piszesz, ale zawsze musisz uważać na to, co mówi licencja na temat twojej odpowiedzialności. To może być trudna rzecz, aby zrobić to dobrze, więc może być łatwiej po prostu nie zwolnić kodu źródłowego.

Oleksi
źródło
1
Tak, to dobra uwaga, a większość licencji na system operacyjny zwykle zawiera gdzieś tekst opisujący tyłek. Chyba zakładałem licencję typu „bez odpowiedzialności”.
naught101
4

Ostrzeżenie: nie jestem prawnikiem .

Cóż, jeśli jest to organizacja non-profit, a jej własność intelektualna jest silnie związana z kodem oprogramowania, niektórzy mogą chcieć zabezpieczyć go przed komercyjnym ponownym wykorzystaniem, a nawet nadużyciem w celu stworzenia kopii oprogramowania.

Niektóre inne powody - które prawdopodobnie są głęboko zakorzenione w pierwszym - są takie, że w twoim przypadku wiele wysokiej klasy badań odbywa się przy prywatnym finansowaniu i zwykle inwestorzy chcą zobaczyć ROI. Jak dotąd nie wszyscy aktorzy branży oprogramowania (lub nowicjusze) zostali w pełni przekonani o opłacalności modelu open source (najprawdopodobniej z powodu braku wiedzy i zrozumienia licencjonowania lub po prostu z obawy, że licencjonowanie nie zapobiegnie złośliwym używa i kopiuje).

Dodatkowo, firmy te nie chcą zostać pozwane przez tych, którzy próbowali zarobić na swoich plecach, a licencjonowanie jest również postrzegane jako zabezpieczenie w tym względzie, bez uzasadnionego powodu.

Może się tak nie wydawać, ale być może organizacje non-profit są opłacalne dla ich założycieli lub inwestorów. Korzyści po prostu nie są bezpośrednie. Są więc bardzo zainteresowani silnymi punktami NFP i brakiem możliwości bicia ich przez konkurencję (nawet jeśli często nie myślisz o „konkurentach” na rynku non-profit) i chcą zachować swoje Własność intelektualna, nawet jeśli kosztem nie jest uzyskanie więcej darmowych gałek ocznych, aby przejrzeć kod, aby znaleźć problemy i poprawić go na wczesnym etapie.

Pamiętaj również, że prawa autorskie różnią się w poszczególnych krajach. Wiele krajów europejskich uważa na przykład amerykańskie przepisy dotyczące praw autorskich i amerykański system patentowy za raczej głupie, więc trudno jest zrzucić kulturowe pochodzenie i wagę.

Po prostu moje 2 centy na ten temat.

(Dużo współpracowałem z uniwersytetami, a ostatnio w bioinformatyce i opiece zdrowotnej ... To powtarzające się pytanie dla mnie i moich kolegów :))

Haylem
źródło
Hrm .. W swoim pytaniu zastanawiałem się razem nad kodem i adresem IP. Może powinienem to wyjaśnić. Pomyślałbym o ROI i rozważaniach związanych z brandingiem jako motywach zysku ... (Zdaję sobie sprawę, że „nauka” była nieco niejasna i że wiele nauki przynosi zyski - moja dziedzina (nauki o systemie ziemi zdecydowanie nie są).
naught101
Wyjaśniłem pytanie. Przepraszam za kłopot.
naught101
Uważam, że twoje pole jest opłacalne. Może nie mieć szerokiego rynku, ale to nie znaczy, że nie jest opłacalny. W praktyce uważam, że wiąże się to z dość dużymi pieniędzmi. Dlaczego uważasz inaczej?
haylem
Jestem w modelowaniu klimatu. Nikt nie płaci za modele klimatyczne. Nikt nie płaci za korzystanie z modeli klimatycznych. Korzystanie z oprogramowania nie przynosi żadnych zysków. Ludzie otrzymują wynagrodzenie za badania przy użyciu tych modeli (co często obejmuje pisanie modeli), a czasem obliczenia są czasem opłacane, ale oba te oznaczają, że dzielenie się kodem sprawiłoby, że rzeczy byłyby tańsze (więcej czasu na badania zamiast pisania kodu , mniej czasu traconego na urządzenia HPC). Naprawdę nie rozumiem, w jaki sposób oprogramowanie jest powiązane z zyskownością.
naught101
1
@psr: Myślę, że to nie ma sensu: wyniki korzystania z modelu przynoszą zyski, ale niekoniecznie dużo pieniędzy zarabia się na sprzedaży oprogramowania implementującego model. Zaskakuje mnie również, ale równie dobrze może być.
haylem
1

Istnieją co najmniej dwa różne rodzaje otwartego oprogramowania.

Jeśli twoje podejście jest „tutaj jest coś użytecznego, skończyłem z tym” (a to okazuje się być trafne), to ma to niewielką wadę.

Z drugiej strony, jeśli twoja postawa brzmi: „Jestem naprawdę podekscytowana i chcę, aby niektórzy prawdziwi użytkownicy pomogli w rozwoju w przyszłości”, pomyśl bardzo ostrożnie. Będziesz musiał poświęcić czas na wspieranie użytkowników, z których wielu nie ma pojęcia. Będziesz musiał rozważyć sprzeczne żądania dotyczące funkcji i ulepszeń. Coraz trudniej będzie wprowadzać zmiany, aby zachować kompatybilność wsteczną.

ddyer
źródło
3
Naprawdę nie rozumiem, w jaki sposób wydanie kodu zobowiązuje kogokolwiek do zapewnienia wsparcia? I przynajmniej w nauce większość użytkowników jest dość zorientowana, przynajmniej jeśli chodzi o proces, jeśli nie sam kod.
naught101
1
@ naught101: obliguje nie, ale jeśli ktoś wykorzystuje swój kod, to będzie uzyskać e-maile, pytania, sugestie ... który będzie trochę wysiłku do uchwytu, chyba po prostu wybrać, aby je zignorować. Poza nauką wielu użytkowników nie jest zbyt dobrze poinformowanych, więc może się okazać, że pomagasz ludziom z podstawowymi problemami z konfiguracją itp. Po prostu dlatego, że zdarzyło ci się zwolnić trochę kodu. Przynajmniej tego doświadczyłem. Nawet wyłączenia odpowiedzialności w stylu BSD „zapewniono takie, jakie są” itp. Nie powstrzymują - i nie powinny - powstrzymywać ludzi przed proszeniem o pomoc.
Joonas Pulakka
1
Pozytywnie oceniany, ponieważ ta odpowiedź nie jest tak samo przydatna jak wiele innych. @JoonasPulakka: oczywiście nie powinno to powstrzymywać ludzi przed proszeniem o pomoc. Ale to powinno powstrzymać ich przed oczekiwaniem odpowiedzi. Ponadto, jeśli faktycznie udostępniasz oprogramowanie, to prawdopodobnie ponosisz taką samą odpowiedzialność wobec użytkowników, niezależnie od tego, czy Twój kod jest publiczny (być może w zależności od umowy EULA). Być może będziesz musiał spodziewać się więcej zapytań od deweloperów, jeśli wydasz kod, ale fajnie byłoby pomyśleć, że większość z nich będzie miała jakiś podpowiedź i może odpłacić jakąś radę łatką lub dwiema.
naught101