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

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?

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.

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.

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.

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).

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.

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,

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.

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ść?

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.

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.

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”