Mądrość wykorzystania kodu open source w komercyjnym oprogramowaniu

13

Patrzę na używanie jakiegoś kodu open source w mojej aplikacji sieci web ASP.NET (konkretnie eleganckiej ). Zarządzanie nie jest fanem, ponieważ otwarte oprogramowanie jest postrzegane jako ryzyko, które nas wcześniej gryzie. Najwyraźniej poprzedni programiści musieli przepisać rzeczy po awarii komponentów open source.

Profesjonaliści wydają się być:

  • Robi dla mnie wiele rzeczy, które w innym przypadku wymagałyby albo dużego kodu źródłowego, albo zalecanego, ale wolniejszego rozwiązania Microsoftu (Entity Framework).

Cons:

  • Jest na tyle skomplikowany, że gdyby nagle miał się nie udać w produkcji, trudno byłoby mi to naprawić. Jest jednak używany w witrynie o większym natężeniu ruchu niż moja, więc nie sądzę, że będzie to część projektu wysokiego ryzyka.

Jaki jest tutaj konsensus? Czy nierozsądne jest używanie w moim projekcie kodu open source, którego nie znam / nie rozumiem tak dobrze, jak własnego kodu?

Pan Jefferson
źródło
15
ASP.NET i jego stos są otwarte.
Andrew T Finnell
11
„Czy nierozsądne jest używanie w moim projekcie kodu open source, którego nie znam / nie rozumiem tak dobrze, jak własnego kodu?” W przeciwieństwie do bibliotek zamkniętego źródła, które są czarnymi skrzynkami?
user16764
5
@AndrewFinnell: Nie według własnej definicji ruchu FLOSS.
tdammers
6
Jeśli chodzi o konkretny projekt systemu operacyjnego, o którym myślisz, może być interesujące, że Dapper jest używany przez StackExchange ...
Marjan Venema
4
To nie jest pytanie techniczne, nie chodzi o to, co jest lepsze. Który pójdzie źle. MFC nie żyje, XP nie żyje za mniej niż 2 lata itp. Darmowy projekt open source nie umrze, jeśli będzie dobry, ponieważ ty lub ktoś inny możesz go przejąć. Chodzi o to, kto będzie obwiniony. Jeśli wybierzesz Microsoft, jeśli będzie nieprzewidziane, lub błąd Microsoftu. Jeśli wybierzesz Free / opensource, będzie to twoja wina.
ctrl-alt-delor

Odpowiedzi:

20

To wybór, który będziesz musiał podjąć w zależności od konkretnych okoliczności. Możesz ograniczyć swoje ryzyko poprzez:

  • dokładne przetestowanie frameworka, unikając prawdopodobieństwa przykrych niespodzianek, które gryzą cię w środowisku produkcyjnym, i
  • używając luźnego sprzężenia, aby zminimalizować ilość kodu, która zależy bezpośrednio od frameworka, dzięki czemu możesz przejść do własnej implementacji, jeśli musisz, bez przepisywania całego produktu.

Ostatecznie, przy mocno używanym projekcie typu open source prawdopodobnie poświęcisz dużo więcej czasu na napisanie własnego, niż na naprawienie kilku problemów, na które napotkasz.

StriplingWarrior
źródło
16

Posunę się nawet do stwierdzenia, że ​​jeśli twoją początkową reakcją jest napisanie czegoś sam, a nie sprawdzenie, czy ktoś to napisał, jesteś skazany na porażkę. Nie bierz pochopnie wszystkich godzin pracy i naprawiania błędów, które trafiły do ​​głównych projektów open source.

Gdy zaczniesz wchodzić do domeny biznesowej, będziesz miał trudność ze znalezieniem OSS, który spełnia Twoje potrzeby. Ale nie ma potrzeby ponownego wdrażania jeszcze jednego produktu ORM. Jeśli elegancki program jest na tyle skomplikowany, że nie byłbyś w stanie debugować i naprawić ich kodu, jak usprawiedliwiałbyś spędzanie wszystkich godzin pracy na pisaniu go od zera? Poza tym zawsze możesz (powinieneś?) Zawsze patrzeć nieszablonowo na rozwiązania NoSQL.

Nawet Linus przyznał, że zanim opracował Git, próbował znaleźć rozwiązanie SCM spełniające wszystkie jego kryteria. Przynajmniej potrafił wyjaśnić, dlaczego żadne z istniejących rozwiązań nie było wystarczająco dobre.

W pewnym momencie mojego życia przestałem chcieć przepisać wszystko sam i chciałem skoncentrować się na rozwiązywaniu problemów w świecie rzeczywistym. Większość problemów, które należy rozwiązać w firmie, dotyczy konkretnej domeny. Znajdź sposoby na pisanie mniej kodu, a nie więcej.

Andrew T Finnell
źródło
2
+1 Zgadzam się z tym wszystkim, z wyjątkiem tego, gdzie mówisz, że „(powinien)” spojrzeć na NoSQL; każde rozwiązanie do przechowywania danych NoSQL - jest ich wiele - ma określony zestaw kompromisów w stosunku do „standardowej” relacyjnej bazy danych SQL, więc trudno powiedzieć „powinien” bez dużej ilości informacji. Czasami są to dobre kompromisy, a czasem nie, ale nie można na ten temat wydawać ogólnych oświadczeń. „NoSQL” to po prostu marnotrawstwo śmieci wokół szeregu technologii, które mają niewiele wspólnego, oprócz tego, że nie są najbardziej rozpowszechnionym schematem przechowywania danych.
Donal Fellows
Ale wszystko, co piszesz, zdecydowanie się z tym zgadzam. Dobry OSS wymaga dużo wysiłku od zwykłego pracującego programisty (a kto chciałby użyć złego OSS?)
Donal Fellows
Wytworny jest złożony, ponieważ jest uogólniony. Gdybym miał napisać własne rozwiązanie, zrobiłbym dużo kodu konwersji zestawu danych do obiektów (tj MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString().).
Pan Jefferson
Gdy zaczniesz wchodzić do swojej domeny biznesowej, trudniej będzie ci znaleźć - OSS - wszystko , co spełni twoje potrzeby. Chyba że firma Microsoft jest Twoją firmą. (ale podoba mi się reszta tego, co powiedziałeś).
ctrl-alt-delor
@richard Niektóre z moich odpowiedzi mogą być niejasne. Twoje oświadczenie jest również tym, co mówię. Po co skupiać się na elementach rozwiązanych raz po raz, takich jak ORM. Skoncentruj się na domenie biznesowej. ORM nie jest domeną biznesową, chyba że sprzedajesz produkt ORM.
Andrew T Finnell
15

Uwaga: nie jestem pracownikiem Microsoft. Opinia jest całkowicie osobista. Wiele myśli pochodzi z ostatnich 5-7 lat używania obu programów typu open source w połączeniu z dużymi dostawcami jako programistami.

Monokultura jest dobra: moją osobistą zasadą dla ASP.NET jest dawanie pierwszeństwa Microsoftowi i nie wybieranie kodu innej firmy (open source lub nie), chyba że nie ma innego wyboru. Monokultura jest satysfakcjonująca, ponieważ jesteś prowadzony przez dużego sprzedawcę, a liczba użytkowników powtarzających to samo doświadczenie jest wystarczająco duża, aby uzyskać pomoc i znaleźć obejście.

Miasta widmo: Problem z otwartym oprogramowaniem w 2012 roku polega na tym, że nie jest to już rok 2000 ani 2005. Ilość projektów stale rośnie, gdy liczba użytkowników, adopcji, współpracowników jest mniej więcej taka sama jak przed laty. Widownia jest rozciągnięta. Wiele interesujących projektów stało się przestarzałe, porzucone. Nie ma czegoś takiego jak budżet projektu typu open source. Kiedy więc zainteresowanie się kończy, nikt nie może uczciwie ogłosić, że wsparcie się skończyło i zgasić światła. Projekty nigdy nie umierają, aby zwrócić uwagę opinii publicznej na coś lepszego i nowego. Tak więc open source zawsze będzie się powiększać i fragmentować. Nie mając żadnej informacji zwrotnej w postaci nagrody pieniężnej lub śmierci finansowej, są oni nieśmiertelnymi bytami, istniejącymi ze względu na wieczną chwałę.

20 stopni separacji: każda twoja nowa biblioteka oddziela cię od głównego nurtu, przenosi cię do mniejszości przypadkowych przypadków. Po 20 krokach, takich jak wybranie konfiguracji zabezpieczeń, użycie konkretnej wersji, frameworka, wtyczki itp. Twoje rozwiązanie staje się pojedynczą globalną unikalną kombinacją szczegółów. Google pomoże jedynie udowodnić, jak rzadki lub wyjątkowy jest problem. Jest to zawsze jakiś samolubny problem, czysto techniczny. Nigdy nawet nie dotyczy prawdziwego biznesu.

Jakość jest skoncentrowana, pieniądze nie mają znaczenia: oprogramowanie komercyjne nie różni się od oprogramowania open source. Cała społeczność devellopersów jest jak zawsze jedną społecznością. Duzi dostawcy mają po prostu tę zaletę, że starzeją kod dłużej, w lepszych warunkach, z szerszą grupą odbiorców niż grupy open source.

Konsensus: Pytasz, czy istnieje konsensus. Prawdopodobnie nie. Niestety duża liczba użytkowników open source jest zbyt upolityczniona. W końcu open source to ruch społeczny. Otwarte oprogramowanie jest odporne na krytykę, ponieważ bardzo często negatywna opinia będzie postrzegana jako antytechnologiczny, osobisty atak. Mój osobisty konsensus: trzymaj się Microsoft.


źródło
3
+1: Nie mogę powiedzieć, że całkowicie się zgadzam, ale zbyt dobrze argumentowałem, aby nie .....
mattnz
14
„Nie ma czegoś takiego jak budżet projektu typu open source”. jest nieprawdziwe. Google ma budżet na projekty typu open source, a Red Hat Inc., na przykład, nie może prowadzić działalności, jeśli nie włoży wystarczającej ilości programistów w swoje oprogramowanie. A co z tym? microsoft.com/opensource/directory.aspx
ONOZ
14
Nie zgadzam się z jednym słowem, które wypowiedziałeś.
Avio
11
Wszystkie te punkty dotyczą w równym stopniu projektów o zamkniętym źródle. Dodanie niszowych zamkniętych bibliotek / frameworków źródłowych dodaje różnorodności. Stare zastrzeżone technologie są porzucane, jeśli nie zarabiają na nich pieniędzy. Nadal możesz skonfigurować IIS, aby był swoim własnym unikalnym motylem. Komentarz dotyczący jakości ignoruje fakt, że projekt open source może być większy niż (niektórzy) dostawcy. Świat biznesu jest bardzo upolityczniony, szczególnie w przypadku Microsoftu.
Philip
3
Miałem odwrotne doświadczenie. Przeniesiliśmy SQLite na urządzenie i byliśmy w stanie uzyskać wsparcie bezpośrednio od faceta, który napisał większość z nich. W żaden sposób nie uzyskalibyśmy takiego poziomu usług od firmy z zamkniętym źródłem. Niektóre projekty open source są absolutnie bardziej niezawodne i mają lepsze wsparcie niż niektóre projekty typu open source. Mógłbym opowiedzieć historię o użyciu „standardu branżowego” kompilatora Microsoft C ++ dla OS / 2 oraz o tym, jak poszło wsparcie, kiedy Microsoft zdecydował się na zwolnienie za kaucją na OS / 2.
Gort the Robot
7

Pracowałem nad wieloma udanymi projektami dla dużej firmy, która wykorzystała znaczne ilości oprogramowania typu open source. W szczególności użyłem Curl, SQLite i Webkit dla bardzo dużej firmy przy udanych projektach wysyłanych do użytkowników końcowych. Jak powiedzieli inni, to tylko kwestia uważności na licencje i idealnej opieki ze strony prawnika.

Istnieją setki licencji typu open source, ale ogólnie dzielą się one na dwie kategorie: styl BSD i styl GPL. Licencje w stylu BSD nie wymagają otwierania własnego kodu źródłowego i generalnie mają po prostu klauzulę atrybucji. Licencje w stylu GPL wymagają otwarcia kodu źródłowego. Większość firm (w tym moja) generalnie patrzy na to z niechęcią, więc będziesz chciał unikać stylu GPL. Wygląda na to, że Dapper używa licencji Apache, która jest w stylu BSD. Przed rozpoczęciem kodowania zawsze dowiedz się, jakie są ogólne warunki licencji.

Istnieje również LGPL, która jest interesującym przypadkiem na granicy, ponieważ możesz z nich korzystać, nie otwierając własnego kodu, jeśli ograniczysz dostęp do granicy binarnej. (Tj. Dostęp do biblioteki tylko jako biblioteka dynamiczna.) Korzystanie z biblioteki LGPL jest bardzo wykonalne, musisz być bardziej ostrożny.

Z mojego doświadczenia wynika, że ​​bardziej prawdopodobne jest, że kod open source nie będzie działał nieprawidłowo lub nie będzie działał tak samo, jak rozwiązania płatne lub, jeśli o to chodzi, rozwiązania własne. Jeśli spojrzysz na niektóre z bardziej znanych narzędzi open source, jakość jest bardzo wysoka.

Prawdopodobnie chcesz uniknąć projektów, które są małe lub niekompletne. Może być kuszące, aby złapać coś, co wydaje się odpowiadać twoim potrzebom, ale jeśli były to coś złożonego przez kilka osób, nigdy nie ukończone i nieobsługiwane, prawdopodobnie nie jest to warte wysiłku. (Chyba że chcesz bezpośrednio pracować nad kodem).

Gort the Robot
źródło
7

Czy nie miałeś nigdy wcześniej problemów z zastrzeżonymi komponentami? Napotkałem wiele błędów w oprogramowaniu dużych i małych firm. Ten problem nie jest problemem sam w sobie z otwartym kodem źródłowym, a raczej o dojrzałości projektu.

Wygląda na to, że chcesz korzystać z dojrzałych projektów oferujących wsparcie. Niektóre projekty open source oferują płatne wsparcie lub mają wystarczająco dużą społeczność, aby uzyskać odpowiedzi na forum publicznym. Być może powinieneś wybrać priorytety dojrzałości i kryteria wsparcia przy wyborze biblioteki, niezależnie od tego, czy jest ona zamknięta czy otwarta.

Musisz potwierdzić, że podejmujesz większe ryzyko, jeśli zdecydujesz się na niedojrzały projekt lub projekt o ograniczonym wsparciu. Jako taki musisz ustalić, jaki jest twój plan ograniczania ryzyka. Możesz na przykład wykonać więcej testów na oprogramowaniu innej firmy.

M. Dudley
źródło
6

Zakładając, że problemy licencyjne nie są tutaj problemem: po krótkim spojrzeniu na Dapper zauważyłem, że ma tylko 2255 linii dobrze udokumentowanego, czytelnego kodu . To jest

  • na tyle duży, że możesz zainwestować kilka dni lub tygodni, aby stworzyć kod porównywalnej jakości, robiąc to samo
  • wystarczająco małe, aby zrozumieć, co robi i naprawić wszelkie błędy w tym kodzie, jeśli pojawią się w środowisku produkcyjnym

Jeśli zamierzasz napisać coś takiego na własną rękę i „wymyślić koło”, masz znacznie większe ryzyko, że twój własny kod wyświetli błędy produkcyjne, i będziesz naprawdę „mocno zmuszony do ich naprawienia”.

Co jednak musisz tutaj zrobić, jeśli wprowadzasz do swojego projektu taki kawałek oprogramowania typu open source, musisz wziąć pełną odpowiedzialność za ten kod, tak jakbyś sam go napisał. Upewnij się, że kod jest w stanie, w którym możesz go zachować, jeśli to konieczne. Nie obwiniaj „autorów” tego kodu, jeśli coś nie działa zgodnie z oczekiwaniami.

W jednym z naszych projektów również wprowadziliśmy niektóre komponenty open source, od małych rozmiarów, takich jak Dapper, po biblioteki zawierające około 20 000 do 30 000 wierszy kodu. Mieliśmy zawsze dokonać pewnych zmian, naprawić kilka błędów, zmniejszać coś itd, ale to było ok, ponieważ spodziewaliśmy się tego. Nawet czas na debugowanie, użycie open source zaoszczędziło nam dużo pracy.

Jedną rzecz do przemyślenia tutaj: w twoim przypadku wspominasz, że istnieje szeroko akceptowana alternatywa od dużego dostawcy (MS Entity Framework, za którą nie musisz płacić żadnych dodatkowych opłat licencyjnych!). Nie chcesz go używać ze względu na wydajność. Poważnie zalecam, aby wydajność nie była jedynym lub najważniejszym punktem do rozważenia. Pytania, które powinieneś tutaj zadać: czy Dapper ma wszystkie potrzebne funkcje i oczekiwany okres użytkowania oprogramowania? Czy możesz przewidzieć, że szybko osiągniesz granice Dappera i będziesz musiał dodać wiele brakujących funkcji wokół niego, czego prawdopodobnie nie musiałbyś, gdybyś zdecydował się na użycie EF? W takim przypadku odradzam używanie Dappera. Zadaj też sobie pytanie: czy EF naprawdę nie jest wystarczająco szybki dla twojej aplikacji,

Doktor Brown
źródło
1
+1 za problemy licencyjne. Sprawdź dokładnie, czy użycie jakiegoś komponentu open source nie zmusi cię również do otwarcia własnego kodu. Nie sądzę, że tak będzie w przypadku większości programów typu open source, a jeśli używasz go tylko do tworzenia lub hostowania swojego kodu, będzie więcej dostępnych, ale mimo to warto to sprawdzić.
Lunivore
Nawet jeśli wydajność jest mniej istotna, EF daje mi mniejszą kontrolę. Wprowadzenie buforowania jest nieco trudniejsze, jeśli stanie się konieczne na późniejszym etapie; Dapper byłby łatwiejszy do dopasowania do bardziej niestandardowego rozwiązania, poza tym, że w pierwszej kolejności spychałaby konieczność buforowania w dalszej części drogi.
Pan Jefferson
Z drugiej strony, pragnienie niestandardowego rozwiązania w stosunku do EF brzmi trochę jak NIHS. Mój schemat danych jest dość złożony, z wieloma relacjami (kluczami obcymi), i dotarcie do punktu, w którym moje niestandardowe rozwiązanie zarządza tymi relacjami, a także EF nie byłoby gotowe po wyjęciu z pudełka.
Pan Jefferson
@ Mr.Jefferson: na poważnie, nie mogę udzielić ci dobrej rady, co jest lepszym rozwiązaniem w twoim przypadku, to jest coś, co musisz sam wypracować. Chciałem tylko dać ci kilka wskazówek, które powinieneś wziąć pod uwagę.
Doc Brown
+1. Podniosłeś kilka bardzo doskonałych punktów z tym postem. @ Mr.Jefferson: Używam Entity Framework od jakiegoś czasu i odniosłem sukces w zarządzaniu wydajnością poprzez buforowanie ad-hoc w określonych repozytoriach po ustaleniu, gdzie są wąskie gardła. Ponadto nasz produkt jest dość złożony, ale nadal nie musiałem uciekać się do pisania pojedynczego zapytania SQL. Czuję, że EF dał mi dużą kontrolę.
StriplingWarrior
2

Moim zdaniem jest to działanie równoważące.

Jeśli uzależnisz się od dostawcy, jest prawie pewne, że wsparcie zniknie wkrótce

  • Ponieważ mają programistów do zapłaty, muszą więc ciągle tworzyć nowe wersje i upewnić się, że starych nie da się zdobyć i nie działają (na nowszych platformach), aby nowe mogły mieć rynek.

  • Jeśli nie mogą sprzedać wystarczająco dużo, aby uzasadnić model biznesowy, przekazują go od firmy A do firmy B do C, z których każda zmienia go wystarczająco, więc ponownie nie można użyć nowego bez przeprogramowania i można „ t dostać stary, który działa.

  • Po prostu postanawiają, że nie będą już go wspierać, ponieważ jest to zbyt wielki problem i nie ma w tym pieniędzy. Wszystkie pieniądze są w nowych aplikacjach.

Więc jeśli chcesz zbudować coś, co nie musi być ciągle przepisywane co kilka lat, open source może być twoim przyjacielem.

Mike Dunlavey
źródło
1

Myślę, że rozsądnie jest zrobić wystarczająco staranną pracę i wydaje się, że odrobiłeś już lekcje z historii i działalności konkretnego projektu. Możliwość rozszerzenia / dodania funkcji w kodzie źródłowym jest również dużym pro. Dzięki wystarczającym testom możesz zminimalizować ryzyko po stronie. Trudno jest w pełni zrozumieć wszystkie zależności w kodzie, ale przynajmniej w takim przypadku będziesz w stanie w pełni debugować i wyświetlić kod, jeśli to konieczne.

Zapytaj kierownictwo, dlaczego zawiodło wcześniej, czy wykonano wystarczającą należytą staranność?

Dozorca więzienny
źródło
Nie wiem wiele o tym, co się stało. To było zanim tu przybyłem.
Pan Jefferson
0

jquery ma opcję korzystania z licencji MIT, więc wiele witryn komercyjnych i rządowych również używa jquery. Witryna Microsoft również używa jquery! Więc problemem jest licencjonowanie. Wystarczy unikać GPL / LGPL.

„Jak długo można naprawić zgłoszoną usterkę?” Po zgłoszeniu błędu może on zostać naprawiony w ciągu kilku minut, godzin lub dni. W nagłej sytuacji personel może po prostu „pociągnąć”, aby zdobyć źródło i sam je skompilować. Po prostu zgłasza zarządowi wersję, taką jak „v1.2.3-101-gd62fdae”, która jest identyfikowalna.

linquize
źródło
0

Open source tak naprawdę dotyczy legalności, a nie jakości kodu. Istnieją dobre i złe produkty typu open source, podobnie jak dobre i złe produkty typu open source. Uważam, że waszym dylematem jest to, czy skorzystać z projektu opracowanego przez społeczność wolontariuszy.

Nemanja Trifunovic
źródło
-1

Czy na pewno problem zarządzania dotyczy problemów technicznych?

Mówię to, ponieważ łączenie OS i działalności komercyjnej jest legalną dziedziną kopalni, a więcej niż jeden menedżer otrzymał „Proszę wyjaśnić” od zespołu prawnego / dyrektora generalnego lub, co gorsza, z innej organizacji. Większość menedżerów, których znam, nawet ci, którzy aktywnie korzystają z oprogramowania systemu operacyjnego, są (słusznie) bardzo ostrożni, aby w pełni zrozumieć sytuacje prawne, w których ujawniają swoje pochodzenie. W przypadku przyjęcia oprogramowania systemu operacyjnego i wprowadzenia zmian użytkownik jest zobowiązany do zwrócenia tych zmian społeczności. W niektórych przypadkach obowiązek ten jest legalny, w innych moralny. W niektórych licencjach na system operacyjny wszystko, co robisz, staje się systemem operacyjnym po prostu poprzez połączenie z nimi.

Z technicznego punktu widzenia jest to tak naprawdę decyzja pomiędzy konkurującymi produktami - zadaj kilka podstawowych pytań - czy możesz uzyskać wsparcie, którego potrzebujesz dla wybranego pakietu ?, jak długo można naprawić zgłoszoną wadę, ile to będzie kosztowało programista, rocznie lub jednorazowo itp. System operacyjny ma wiele zer w kolumnie $, ale często ma puste w pozostałych - tylko ty i twój szef możecie zdecydować, czy zero jest zerowe, czy nie.

I jeszcze jeden punkt do zapamiętania - „Nikt nigdy nie został zwolniony z zakupu IBM”. (tj. kierownictwo mówi za „Jeśli wydajesz dużo pieniędzy, musi to być lepszy produkt niż darmowy”

mattnz
źródło
5
Ironiczne jest to, że IBM jest prawdopodobnie największym na świecie sprzedawcą oprogramowania opartego na Open Source. Serwer http Apache, Eclipse itp.
James Anderson
7
Sprzedaż OSS nie jest nielegalna. Dlaczego miałoby to być?
tdammers
1
IBMS httpServer jest czystym apache, tylko zawiera umowę wsparcia.
James Anderson
2
Rzeczy się zmieniają. Teraz zarząd zaczyna myśleć, że jeśli zmusisz firmę do płacenia za komponent, który inne firmy miały za darmo, jesteś głupcem.
Avio
2
„Inne kolumny” rzadko są puste w przypadku oprogramowania typu open source. Zawsze możesz uzyskać wsparcie od konsultantów, sprzedawców lub innych osób, a także sam. Więcej kolumn jest często pustych dla oprogramowania komercyjnego, ponieważ nie znasz z góry jakości ich wsparcia i rzadko jest to tak pomocne, jak potrzebujesz.
Jan Hudec