Pisanie open source w pracy

Prowadzący zajęcia parę razy wciskał nam coś, co później okazało się być bzdurą, np. że nazwa "round robin" wzięła się od ptaka - rudzika albo że jedynym poważnym źródłem zarobków Microsoftu jest subskrypcja Office365 i praktycznie nic innego już nie sprzedają.

Ostatnio znowu coś powiedział, a ponieważ pierwszy raz usłyszałem o czymś takim, postanowiłem napisać tutaj pytanie z prośbą o weryfikację.

W wielu firmach, w których programiści pracują nad projektami komercyjnymi, podpisują specjalne umowy zabraniające im w razie opuszczenia firmy pisania podobnego kodu przez następne parę lat. Programiści omijają ten proceder, publikując napisany przez siebie kod na licencji otwartej typu MIT, po czym importując go do projektu komercyjnego jako bibliotekę. W razie zmiany miejsca pracy, będą mogli w ten sposób skorzystać z już gotowego kodu swojego autorstwa i jednocześnie nie złamią postanowień umowy.

Wiem, że to brzmi śmiesznie, ale mimo wszystko chciałbym rozwiania moich wątpliwości przez osoby z doświadczeniem komercyjnym xD

Hm generalnie to bzdura, bo nie możesz ot tak sobie opublikować kodu pisanego w pracy, bo tenże jest własnością twojego pracodawcy. Pewnie mógłbyś po godzinach sklecić jakąś bibliotekę a potem użyć jej w pracy, ale znów często umowa zabrania ci takich rzeczy, jeśli ta biblioteka jest związana z tym co robisz w pracy. No i też zwykle nie możesz ot tak importować sobie biblioteki noname z d**y w projekcie w pracy, bo cie jakiś architekt nabije na pal :D

Niemniej wiele firm pisze rzeczy open source i faktycznie udostępnia je dla innych, ale to wszystko odbywa się za zgodą i wiedzą pracodawcy.

Dokładnie tak samo myślałem, ale według tego pana tak robią wszyscy, którym umowa zabrania pisania podobnego kodu w przyszłości. Podobnie twierdzi w kwestii używania zewnętrznych bibliotek: jeśli tylko licencja na to pozwala, można używać wszelkich bibliotek, jakie się znajdzie, bo "po co wynajdować koło na nowo".

Pewnie mógłbyś po godzinach sklecić jakąś bibliotekę a potem użyć jej w pracy, ale znów często umowa zabrania ci takich rzeczy, jeśli ta biblioteka jest związana z tym co robisz w pracy. No i też zwykle nie możesz ot tak importować sobie biblioteki noname z d**y w projekcie w pracy, bo cie jakiś architekt nabije na pal :D

U nas w projekcie (w międzynarodowym banku) jest sporo takich bibliotek naklepanych przez poprzedni zespół po godzinach. Biblioteki są dostępne na Google Code i/ lub GitHubie.

@ShookTea a jeśli w tej bibliotece jest jakaś luka bezpieczeństwa albo poważny bug to co? ;) Jasne że "można", ale często architekt na to nie pozwoli. Widziałem już takie biblioteki co to fajnie działały dla HelloWorld, ale w dużym projekcie powodowały wywalenie się aplikacji z out of memory :D I co potem powiesz klientowi któremu system nagle przestaje działać? ;) Zewnętrzne zależności zawsze niosą pewne ryzyko, ale jednak można mieć nadzieje że bibliotekę standardową języka ktoś przetestował, tak samo jakiś popularny framework. Ale już noname lib z randomowego githuba?
@Wibowit jw, pytanie kto to utrzymuje potem.

dobrze, że ktoś zadał to pytanie, bo się nad tym zastanawiałem
Z drugiej strony ciekawi mnie postać prowadzącego, bo jego myślenie jest zaskakujące: napisz liba na licencji MIT, idź do pracy, praca się nie podoba to zmieniasz i idziesz do innej, korzystasz z tego samego liba. Same profity a manna leci z nieba. Trzeba mieć tylko wyjątkowy fart, żeby np. na przestrzeni choćby 2 lat, trafić do innej firmy, która robi konkurencyjny projekt i jest na tym samym etapie co pierwsza firma 2 lata temu. Teoria światów równoległych to przy tym betka.

Nie ma czegoś takiego jak zakaz pisania podobnego kodu.
Jak niby sprawdzić podobieństwo nie mając dostepu do kodu w nowej firmie byłego pracownika?
Jeżeli zakaz dotyczyłby konkretnych sektorów, to już zupełnie bzdura, bo to by oznaczało, że jak pracujesz w bankowości to później już nie możesz i bardzo szybko ścieżk by się pozamykały.

Jeżeli ktoś coś takiego w umowei ma, to to jest tyle samo warte ile zakaz konkurencji jeżeli pracodawca nie spełni dodatkowych warunków.
Konkretnie każdy tego typu zapis który stawia Cię w gorszej pozycji po zakończeniu współpracy wiąże się z koniecznością jawnego podania kwoty rekompensaty za taki zakaz.

Jeżeli nie będzie w umowie konkretnie napisane, że za to, że nie możesz konkurować dostajesz X zł miesięcznie lub X rocznie to wtedy w sądzie znaczy to tyle samo co jakby pracodawca napisał zamiast tego punktu, że lubi placki ziemniaczane.
Znaczy, że zapis jest zupełnie bez mocy prawnej.

Nie wiem co nawygadywał prowadzący (dokładnie). Niemniej jednak bibliotek nie wprowadza się do projektu bezrefleksyjnie. Często architekt lub wymagania projektu określają by było szybkie i merytoryczne komercyjne wsparcie dla wprowadzonego elementu kodu. Często może to wykluczyć bibliotekę Open Source (np. ma wsparcie ... żadne....). Inną sprawą jest potencjalny brak kontroli nad procesem rozwoju takiego włączanego produktu. Nie wiadomo czy i kiedy zmieni się jego API lub w jakim kierunku będzie rozwijała się nowsza wersja modułu/biblioteki/narzędzia oraz czy nie zostanie porzucona.
Co do twierdzenia odnośnie pisania na licencji MIT w pracy i "chytrej operacji".. Jeśli to ma być "chwyt" na "krwiopijcę-pracodawcę" to ... jest to działanie nieetyczne. Dobrym programistom raczej dobrze się płaci i mają szacunek tak do pracodawcy jak i do swojej pracy. Ci inni... opowiadają klechdy z krainy mchu i paproci :-) Także IMHO warto skupić się na merytorycznych zagadnieniach przedstawianych przez prowadzącego a te inne pominąć milczeniem :-)

W wielu firmach, w których programiści pracują nad projektami komercyjnymi, podpisują specjalne umowy zabraniające im w razie opuszczenia firmy pisania podobnego kodu przez następne parę lat.

Nie ma czegoś takiego. Jeśli już jest zakaz konkurencji i tyczy się on tylko krytycznych stanowisk w każdej firmie, a nie każdego podrzednego programisty. Jakby to miało wyglądać? Pracujesz w firmie A jako developer Django i po tym nie możesz przez 5 lat pracować z Django? Dwa zakaz konkurencji jest odpowiednio regulowany przez prawo, a także rekompensowany przez pracodawce. To poważne i i obudowane wieloma paragrafami umowy. Nie ma opcji by obejść to bez wyroku sądu. Nie ma czegoś takiego jak zakaz pisania "podobnego kodu". Nie możesz korzystać z własności intelektualnej swojego poprzedniego pracodawcy bez jego zgody, jest to przestępstwo, ale nie możesz być ograniczony do wytwarzania czegoś własnego. Co za bzdury.

Typowy kod w pracy jest osadzony w jakimś stosie technologicznym, w architekturze projektu, i rozwiązuje projektowe problemy. Jak to niby zbibliotekować, a potem przenieść do innego projektu?

Typowy kod w pracy jest osadzony w jakimś stosie technologicznym, w architekturze projektu, i rozwiązuje projektowe problemy. Jak to niby zbibliotekować, a potem przenieść do innego projektu?

Dużo zależy od tego jak rozwinięty jest ekosystem dla języka w którym piszesz. Gdy poprzedni zespół zaczynał tworzenie systemu to ekosystem Scali był dużo mniej rozbudowany niż teraz. Wobec tego popisali sami biblioteki, które dzisiaj już czasem mają popularne odpowiedniki. Przykłady:

• klient HTTP,
• biblioteka do obsługi CSV,
• mikroframework do RESTowych enpointów z próbkami (healthchecki) oraz proste narzędzie monitorujące odpalające te próbki w kółko na bieżąco i pokazujące stan systemu,
• infrastruktura dla testów integracyjnych dla mikroserwisów: mikroframework do RESTowych endpointów w serwisach by wywołać konkretne akcje czy sprawdzenia + narzędzie pozwalające odpalać testy napisane we własnym DSLu, które korzystają z tych endpointów,
• testy przeglądarkowe, czyli:
  • nakładka na selenium (fluent interface)
  • mechanizm, który pozwala odpalać pulę JVMek i przeglądarek, by odpalić N instancji aplikacji i mieć szybsze wykonanie testów,

Jako że ekosystem Scali mocno się zmienił w ciągu ostatnich kilku lat to obecnie staramy się raczej szukać sprawdzonych otwartych bibliotek, niż rozwijać biblioteki od kolegów z poprzedniego zespołu, bo przede wszystkim te biblioteki nie mają żadnej dokumentacji albo jakieś szczątkowe. Na pierwszy ogień poszedł klient HTTP, później biblioteki do CSV w razie potrzeby. Dodajemy też nowe sposoby monitorowania (Kamon/ Grafana). Następna w kolejności będzie infrastruktura testowa dla testów przeglądarkowych jeśli zmienimy architekturę systemu i zastąpimy komponentowy framework server-side za pomocą RESTa na backendzie i SPA na frontendzie.

@ShookTea a jeśli w tej bibliotece jest jakaś luka bezpieczeństwa albo poważny bug to co? ;) Jasne że "można", ale często architekt na to nie pozwoli. Widziałem już takie biblioteki co to fajnie działały dla HelloWorld, ale w dużym projekcie powodowały wywalenie się aplikacji z out of memory :D I co potem powiesz klientowi któremu system nagle przestaje działać? ;) Zewnętrzne zależności zawsze niosą pewne ryzyko, ale jednak można mieć nadzieje że bibliotekę standardową języka ktoś przetestował, tak samo jakiś popularny framework. Ale już noname lib z randomowego githuba?

Poważne luki bezpieczeństwa są wszędzie. Banki mają specjalizowane zespoły, które wykrywają luki bezpieczeństwa w aplikacjach jako całości i komunikują się z zespołami tworzącymi te aplikacje.

Naszych klientów nie interesują specjalnie biblioteki jakich używamy. Ich interesuje to czy system działa. Jeśli coś się spieprzy to nie mówimy, że biblioteka X ma błąd i rozkładamy ręce tylko szacujemy ile coś nam zajmie czasu by to poprawić i co można zrobić na szybko by kupić sobie czas (bo np za chwilę przyjdą ważne transakcje i wtedy np trzeba zrestartować jeden mikroserwis). Równocześnie w zasadzie nie zdarza się by te biblioteki, które przytoczyłem sprawiały jakieś problemy na produkcji, bo tylko trzy na produkcji lądują i są to proste i rzadko zmieniane rzeczy: klient HTTP, biblioteka do CSV i REST z próbkami.

@Wibowit i co, bierzecie się za klepanie fixów w kompilatorze Scali albo w bibliotece standardowej? Wątpie. Co najwyzej wystawicie ticket developerom Scali/Akki/czego tam używacie a u siebie będziecie w międzyczasie jakieś workaroundy pakować. I to wszystko działa, dopóki jest komu wystawić ticket. Jeśli polegacie mocno na bibliotece noname ściągniętej kiedyśtam z githuba, która juz nie jest rozwijana to sytuacja wygląda trochę inaczej, bo nagle zostajecie z ręką w nocniku, bo nikt tego nie naprawi.

Przecież to jest jeden z głównych powodów czemu ludzie kupują soft of dużych firm w stylu IBM. Nie dlatego że ten soft jest jakiś specjalnie dobry, ale dlatego że jest gwarancja że ktoś to będzie utrzymywał.

Programiści omijają ten proceder, publikując napisany przez siebie kod na licencji otwartej typu MIT, po czym importując go do projektu komercyjnego jako bibliotekę. W razie zmiany miejsca pracy, będą mogli w ten sposób skorzystać z już gotowego kodu swojego autorstwa i jednocześnie nie złamią postanowień umowy.

1. Wszystkie projekty open source, z jakich korzystamy w korpo, muszą być zgłoszone w specjalnym miejscu, więc ktoś mógłby zauważyć, że daję linki do własnego githuba...
2. Moje korpo nie przejmowałoby się niuansami technicznymi i wytoczyłoby przeciwko mnie wszystkie procesy... Akurat wiem, że mają tu bardzo negatywne spojrzenie na działalność konkurencyjną i nie odpuszczają. Trzeba pamiętać o tym, że sędzia też niespecjalnie rozumie niuanse technologiczne, za to łatwo będzie mu zrozumieć intencję "wyniósł kod z firmy".
3. Czemu w ogóle miałabym to robić? Jaki w tym sens? Przecież nowa firma zapłaci mi za napisanie tych narzędzi od nowa... Byłaby to super okazja do napisania ich lepiej...
4. Jakby to wyszło na jaw, to przecież żadna poważna firma by cię już nigdy nie zatrudniła, bo po prostu nie będą chcieli, żebyś w przyszłości wyniósł ich kod...

@Shalom:
Temat nie jest o zaciąganiu losowych bibliotek z GitHuba, tylko o wrzucaniu własnych. Z tych bibliotek korzystali ci sami goście, co je pisali. Więc jeśli mieli wystawiać tickety, to samym sobie, bo sami byli autorami. Sytuacja oczywiście zmieniła się po wymianie zespołu i teraz my jesteśmy trochę z ręką w nocniku, ale z drugiej strony biblioteki te są sprawdzone mocno w naszym projekcie.

@Wibowit czytaj wątek ze zrozumieniem w takim razie. Chodziło tu o sytuacje kiedy jeden z developerów w firmie część kodu klepie w domu jako swoją libkę a potem "na krzywy ryj" wrzuca ją do projektu w pracy. Developer kiedyś się zwolni, libka będzie miała bugi i nie będzie rozwijana. Ba, może być nawet gorzej bo co jak koleś dorzuci tylko skompilowaną wersję w projekcie? ;)
Wszystko jest ok dopóki macie do tego źródła i traktujecie to trochę jako in-house development i ktoś jednak ogarnia co się tam dzieje pod spodem. Jednocześnie nie wierzę że te bibliteki ot tak ktoś sobie kiedyś wrzucił, bez konsultowania tego z architektami/tech leadmi i bez odpowiedniego przyklepnięcia tego przez jakiegoś managera.

No partyzantka to raczej nie była.

@Wibowit czytaj wątek ze zrozumieniem w takim razie. Chodziło tu o sytuacje kiedy jeden z developerów w firmie część kodu klepie w domu jako swoją libkę a potem "na krzywy ryj" wrzuca ją do projektu w pracy. Developer kiedyś się zwolni, libka będzie miała bugi i nie będzie rozwijana. Ba, może być nawet gorzej bo co jak koleś dorzuci tylko skompilowaną wersję w projekcie? ;)

Serio? Napisałeś wcześniej:

Jeśli polegacie mocno na bibliotece noname ściągniętej kiedyśtam z githuba, która juz nie jest rozwijana to sytuacja wygląda trochę inaczej, bo nagle zostajecie z ręką w nocniku, bo nikt tego nie naprawi.

Ściąganie losowych bibliotek z GitHuba jest czymś innym niż wrzucanie bibliotek do GitHuba przez członków zespołu.

Disclaimer: Nie czytałem całej dyskusji tutaj.
Są dwie rzeczy, które należałoby tu rozróżnić - zapisy o zakazie konkurencji po rozwiązaniu umowy oraz IP pracodawcy.

Pracodawcy mają tendencję do umieszczania wpisów zakazujących konkurencji po wygaśnięciu/rozwiązaniu umowy, jednak w znakomitej większości nie są one wiążące nawet jeśli pod takimi się podpisałeś. Generalnie po wygaśnieciu umowy nic Cię z byłym pracodawcą nie wiążę i nie masz obowiązku przestrzegania nieważnej już umowy. Chyba, że pracodawca będzie Ci wypłacał ekwiwalent za poniesione straty. Minimalna wysokość ekwiwalentu jest ustanowiona w jakiejś ustawie, ale jeśli nie ma jej ustalonej nigdzie w umowie to niemal pewne, że pracodawca nie będzie Ci jej płacił. Brak pierwszej wypłaty (do miesiąca po rozwiązaniu umowy) automatycznie uwalnia Cię z zapisów o zakazie konkurencji.

Inny temat to IP. Na to nie trzeba żadnych dodatkowych umów, jego ochrona jest przyznawana pracodawcom przez prawo. Tylko, że tutaj temat jest inny, w praktyce konkretny kod rzadko jest przedmiotem rozszczeń związanych z kradzieżą IP - bardzo łatwo jest udowodnić, że Twój kod jest inny niż kod należący do podmiotu oskarżającego. No chyba, że rzeczywiście ukradłeś i przekleiłeś kod a nie napisałeś go od nowa, wtedy to po prostu kradzież i nie powinieneś potrzebować zapisów w umowie żeby wiedzieć, żeby tego nie robić. Jeśli chodzi o IP to tutaj operujemy raczej w kontekście rozwiązań, które mogą dać znaczącą przewagę na rynku i wiązę się też z pewną innowacją. Kod formularza czy kolejny parser JSON do nich nie należą. Ale np. proces technologiczny tranzystorów 10nm albo swego czasu Carmack's Reverse już tak.

Wiesz, ja odpowiem tobie tak: na studiach od razu założyłem, że prowadzący przedmioty takie jak programowanie to po prostu idioci. Wiem (!) mocne założenie, jednak prawdziwe. Powiem więcej wcześniej usłyszałem, że wykładowca (magister, doktor, profesor) na studiach to "osoba, która nie poradziła by sobie na rynku pracy i dlatego jest na uczelni". Po jakimś czasie uważam to za słuszne stwierdzenie.

Czyli: nie słuchaj wszystkich pierdół które tobie prowadzący stara się sprzedać jako znawca tematu.

Skoro już o idiotach mowa, to idiotyczne jest założenie, że profesor albo doktor to ma być ktoś, czyim celem jest "radzenie sobie na rynku pracy".

A na niektórych uczelniach kursy technologiczne są prowadzone przez ludzi faktycznie pracujących w zawodzie. Można się zdziwić trafiając potem na prowadzącego zajęcia na rozmowie kwalifikacyjnej.