Jak zarządzać projektem wysokiego ryzyka zamkniętego źródła?

25

Obecnie planuję stworzyć witrynę J2EE i chcę sprowadzić do pomocy 1 programistę i 1 projektanta stron internetowych. Projekt jest aplikacją finansową na rynku niszowym.

Planuję trzymać źródło zamknięte. Obawiam się jednak, że moi potencjalni pracownicy mogliby z łatwością skopiować bazę kodów i wykorzystać ją lub sprzedać stronie trzeciej. Opracowanie aplikacji potrwa 4-6 miesięcy, a może nawet dłużej. Po uruchomieniu aplikacji mogę zatrudnić dodatkowych pracowników.

Ale jak zachować źródło dla siebie. Czy istnieją techniki stosowane przez firmy w celu ochrony swojego źródła?

Przewiduję wyłączenie napędów USB i nagrywarek DVD na moich komputerach programistycznych, ale przesyłanie danych lub załączanie kodu w wiadomości e-mail byłoby nadal możliwe.

Moje pytanie jest niekompletne. Ale programiści, którzy byli w mojej sytuacji, proszę o poradę. Jak mam to zrobić? Budowanie zespołu, zachowanie tajemnicy kodu itp.

Z niecierpliwością czekam na podpisanie umowy o poufności z pracownikami, jeśli zajdzie taka potrzeba. (Dodaj odpowiednie tagi)

Aktualizacja

Dziękuję za wszystkie odpowiedzi. Na pewno nie będę teraz wyłączał wszystkich portów USB i nagrywarek DVD. Ale myślę, że powinienem rejestrować aktywność (Jak dokładnie mam to zrobić?) Uważam na skalperów, którzy przyłączą się, a następnie uciekną z istniejącym kodem. Nie spotkałem żadnego, ale poradzono mi, aby się ich wystrzegać. Dodałbym klauzulę tajności, ale biorąc pod uwagę, że jest to startup bez finansowania i w wysoce konkurencyjnej niszy biznesowej z większymi graczami w terenie, wątpię, czy byłbym w stanie wykryć lub ścigać dowolnych scalperów.

Jak zatrudniać osoby, którym ufam, skoro nie znam ich osobiście. Ich CV będzie pomocne, ale w przeciwnym razie zaufanie rozwinie się z czasem.

Ale w końcu, nawet jeśli uciekną kodowi, ważna jest usługa po dokonaniu sprzedaży. Więc tak naprawdę nie martwię się na dłuższą metę.

version-control

— Abel
źródło

28

Wiem, że ja (i żaden inny rozsądny, kompetentny programista) rozważyłbym pracę w warunkach, o których wspominałeś (wyłączone pendrivy, nagrywarki DVD…).

— Jonathan Sterling

5

Po prostu trujący.

— Jonathan Sterling

53

Szczerze mówiąc, kiedy spotykam kogoś, kto odmawia rozszerzenia zaufania, zawsze myślę, że mówi więcej o ich własnej wiarygodności niż mojej - to znaczy, jeśli uważasz, że nie można mi ufać, to dlatego, że wiesz, że możesz zaufaj.

— James McLeod,

8

@abel: Sprowadzając niektóre z twoich wcześniejszych uwag, nie masz żadnego doświadczenia w profesjonalnym tworzeniu oprogramowania. Ale próbujesz wejść do „wysoce konkurencyjnej niszy biznesowej” i odnieść sukces w starciu z „większymi graczami”, gdy „nie masz prawie żadnych funduszy”. Masz dużo większe ryby do smażenia niż martwienie się o to, że programiści uciekną z twoim kodem. Gdybym był tobą, napisałbym biznesplan i poddał go przeglądowi biznesmenom, którym już udało się osiągnąć sukces w twoim obszarze docelowym, a następnie zastanowiłam się, czy naprawdę masz środki, aby odnieść sukces.

— Bob Murphy,

37

@abel: Po aktualizacji twoje pytanie jest takie. Nie masz dużo pieniędzy i nigdy nawet nie pracowałeś w restauracji, nie mówiąc już o prowadzeniu jednej. Ale i tak jesteś zdeterminowany, aby otworzyć restaurację - i w San Francisco, które ma już wiele wspaniałych restauracji, które walczą o zysk. Idziesz więc na zjazd szefów kuchni i pytasz, jak zatrudnić szefa kuchni, który nie zatruwa jedzenia. A kiedy mówią ci, że szefowie kuchni nie zatruwają jedzenia, przyznajesz, że nikt, kogo znasz, nie był zatruty, ale ktoś powiedział ci, że powinieneś się tym martwić, żebyś i tak się martwił.

— Bob Murphy,

77

Musisz zaufać swoim programistom.

Praktycznie wszyscy profesjonalni programiści nie ukradną Twojego źródła. Rozumie się, że jeśli pracujesz dla kogoś innego, to pracodawca jest właścicielem kodu, który piszesz. Programiści mogą kopiować kod w celach informacyjnych, ale jest bardzo mało prawdopodobne, że zaoferują go na sprzedaż komukolwiek innemu. Jeśli zaoferowali go na sprzedaż nowemu pracodawcy, prawdopodobnym rezultatem jest pokazanie im drzwi, a być może nawet ich aresztowanie (jak podkreśla Bob Murphy w swoim komentarzu ). Złapanie nie jest warte ryzyka.

Co ważniejsze, nieufność rodzi nieufność. Wyłączenie portów USB i nagrywarek DVD wywoła poczucie nieufności, co paradoksalnie zwiększy prawdopodobieństwo, że programiści skopiują kod.

Z całą pewnością dodaj klauzulę tajności do umowy, ale prawdopodobnie nie jest konieczne podkreślanie jej jako najważniejszej części umowy.

— ChrisF
źródło

2

Krótka klauzula tajności jest całkowicie normalna w umowach rozwojowych i umowach o pracę - ale jak powiedział ChrisF, nie przesadzaj z tym. Dla każdego, kto wykonał więcej niż kilka projektów rozwoju kontraktu, długa tajemnica z groźnymi zagrożeniami mówi tylko, że jesteś nieświadomym amatorem. Istnieją standardowe klauzule, które można znaleźć w Internecie, które działają w dowolnym miejscu od 6-20 wierszy tekstu. To dużo, jeśli chcesz poradzić się prawnika w przypadku naruszenia - a jeśli nie, każda umowa o tajemnicy jest bezcelowa.

— Bob Murphy,

46

Ponadto w prawdziwym świecie osoby trzecie nie chcą skradzionego kodu. Ryzyko jest zbyt duże. Kiedy w połowie lat 90. firma Informix i Oracle zajmowały się rynkiem relacyjnych baz danych dla przedsiębiorstw, jeden z programistów Informix zrezygnował z dołączenia do Oracle (co było dość powszechne) i zabrał ze sobą dysk twardy pełen źródła Informix (który nie był „t). Powiedział swojemu nowemu szefowi w Oracle, oczekując ciepłego powitania, ale zamiast tego dostał zespół bezpieczeństwa i aresztowanie. Następnie zabezpieczenia Oracle zwane zabezpieczeniami Informix, a dysk twardy wrócił do Informix, bez nikogo z Oracle.

— Bob Murphy,

1

@Bob Murphy Mam nadzieję, że wszyscy są tacy szczerzy, nawet na dole łańcucha pokarmowego.

— abel

1

Właśnie miałem wpisać tę dokładną odpowiedź. Zaufanie jest tak naprawdę kluczowe dla powodzenia projektu. Jak stwierdził ChrisF, wyłączenie komponentów komputerów programistów spowoduje jedynie zakłócenie relacji i poinformuje programistów, że nie są zaufani. Jedynym sposobem, aby naprawdę chronić swój kod, byłoby kontrolowanie miejsca, w którym programiści śpią, gdzie jedzą, z kim rozmawiają itp. Upewnij się, że masz dobrze napisaną umowę na dostarczenie ci legalnej amunicji, której potrzebujesz, aby ukarać każdego naruszającego prawo.

— TheBuzzSaw,

2

Dwa słowa: Edward Snowden ( en.wikipedia.org/wiki/Edward_Snowden ). Nawet najbardziej tajne podziały w rządzie federalnym USA nie mają dobrego rozwiązania tego problemu. Co sprawia, że Ty (PO) uważasz, że możesz zrobić coś lepszego? Zbuduj swoje rozwiązanie w oparciu o zaufanie i rozsądne zabezpieczenie, a nie powierzchowne ograniczenia technologiczne!

— rinogo

74

Jeśli ci programiści potrafią napisać oprogramowanie, to ...

NIE POTRZEBUJĄ TO STAL.

Mogą po prostu przepisać go w ułamku czasu potrzebnego na jego pierwotne opracowanie. Tak, to prawda, programiści nie są kompletnymi idiotami ... kiedy wymyślą, jak coś zrobić, często pamiętają, jak to zrobili.

Sądzę więc, że musisz im zaufać lub sam napisać oprogramowanie .

— Grandmaster B.
źródło

3

Czy to argument za zakazem konkurowania? ;)

— Tim

8

Rzeczywiście: twoi programiści już skopiowali twój kod, dzięki posiadaniu tej wiedzy w swoich głowach.

— Frank Shearar,

Rozumiem, że. Nie chcę, aby nowo dołączani programiści kodowali skalowanie.

— abel

3

@abel, skradziony kod nie jest tak przydatny, jak się wydaje. Aplikację można „sklonować”, nawet bez kodu źródłowego. zastrzeżone algorytmy , to jest to, co chcesz zachować bezpieczeństwo. Programiści nie muszą „kraść” kodu, aby się go nauczyć, wystarczy go przeczytać, a następnie odtworzyć. Do licha, samo użycie programu może wystarczyć do wywnioskowania algorytmu. Tak więc, jak powiedzieli inni, prosta klauzula o zakazie konkurowania załatwi sprawę i dotyczy wszystkiego, co możesz zrobić. Fizyczne zabezpieczanie kodu to tylko strata czasu, ponieważ każdy programista wart swojej soli może to łatwo ominąć.

— GrandmasterB

11

+1 za prawdę ... i za to, że spadam ze swojego krzesła ze śmiechu. Krowy nie muszą kraść mleka. 8D

— TheBuzzSaw

22

Słyszałem, że sam pomysł nie jest wart więcej niż 20 USD (a to dolary kanadyjskie!) Pomysł ma wartość tylko wtedy, gdy jest dobrze wykonany. Nawet jeśli chodzi o to, że kradną kod i próbują go sami spróbować, masz lepsze pojęcie o kolejnych krokach i więcej kontaktów z potencjalnymi nabywcami oprogramowania.

Zdecydowanie powinieneś zatrudniać tylko osoby, którym ufasz, ale nawet jeśli ukradną Twój kod i spróbują go sprzedać, jest mało prawdopodobne, aby zaszedł daleko.

— James McLeod
źródło

9

To jest absolutna prawda. Zapomnij o utrzymaniu w tajemnicy swojego wyjątkowego pomysłu i skoncentruj się na jego realizacji lepiej niż ktokolwiek inny. Większość pomysłów jest produktem ich czasu i przydarza się kilku osobom niezależnie. (Henri Poincaré również pracował nad względnością na początku XX wieku, ale Einstein pobił go do publikacji.) Jest szansa, że w tym miesiącu osiem innych ekip przemierza twój pomysł do VC na Sand Hill Road; to ci z wiarygodnymi biznesplanami i profesjonalnymi zespołami, którzy uzyskają finansowanie.

— Bob Murphy,

1

Powiązane: sivers.org/multiply . Złe pomysły nie byłyby nawet warte 2 pensy, ale dobre pomysły mogą być warte ponad 20 USD.

— Pacerier

6

Trudna prawda jest taka, że nikt nie chce twojego kodu. Możesz pomyśleć, że opracowujesz rozwiązanie, które każdy chce wiedzieć, jak to działa. Ale najczęściej nie.

Co byś zrobił, gdybyś przejął kod źródłowy swoich konkurentów? Nie możesz tego rozpowszechniać. Nie możesz skopiować żadnej jego części do swojego projektu (nawet jeśli nie było tak trudno zintegrować kod innej firmy z bazą kodu). Co możesz zrobić? Możesz się tego nauczyć. Ale często trudniej jest odczytać kod niż napisać go w pierwszej kolejności.

Spójrz na oprogramowanie open source. Jest to najbliższa analogia do skradzionego kodu źródłowego. Istnieje ogromna ilość nieobsługiwanego kodu. Duża część ma licencję, która nie odpowiada Twoim potrzebom. Inne mają niezgodny język programowania lub wymagają przeniesienia na Twoją platformę. Kod, który odpowiada Twoim potrzebom, zajmie dużo czasu.

Istnieje wiele projektów typu open source o mentalności zamkniętego źródła. Tzn. Nie akceptują łat. Wkrótce twoja wersja kodu będzie tak bardzo odchylać się, że niemożliwe będzie scalenie nowych wersji.

Powinieneś zrozumieć, że najcenniejszy jest Twój zespół, który utrzymuje Twój kod i posuwa go naprzód. Nie sam kod.

— Vanuan
źródło

5

Jeśli jest to jakiś start-up, najważniejszą rzeczą, którą musisz zrobić, to zbudować produkt. Potrzebujesz dobrych programistów, którzy będą ciężko pracować i będą oddani projektowi.

Jednym naprawdę łatwym sposobem na pozbycie się ich, a przynajmniej osłabienie ich morale i poświęcenia, jest pokazanie im z góry, że im nie ufasz. W rzeczywistości najprawdopodobniej zaczną myśleć o tym, w jaki sposób mogą wyciągnąć kod (chociaż prawie na pewno nie będą postępować zgodnie z nim), a jeśli uda im się wymyślić sposób, będą myśleć, że jesteś nie tylko paranoikiem, ale głupcem. (Istnieją organizacje, w których ten poziom ostrożności jest uzasadniony, a uruchomienie witryny finansowej nie będzie uważane za jedną z nich).

Kilka klauzul w umowie o tym, jak oprogramowanie jest twoją własnością, będzie w porządku. Jeśli ktoś naruszy to, naruszy każdy bardziej surowy język, który znasz, i prawdopodobnie poczujesz się bardziej uzasadniony. Klauzule o zakazie konkurencji, które nie są wąskie i ograniczone czasowo, będą po prostu gonić osoby, które chcesz, i mogą w rzeczywistości być niezgodne z prawem w Twojej jurysdykcji (dowiedz się, czy to zrobił lokalny prawnik).

Jeśli zatrudnisz dobrych ludzi, mogą później przepisać oprogramowanie. Jeśli zatrudnisz początkujących, nie będą oni wiedzieli, jak dalej rozwijać to, z czym odchodzą, a każdy, kto się na tym opiera, będzie narażony na poważne ryzyko prawne, aby przyjść późno z gorszą wersją tego, co masz.

Krótko mówiąc, powinno to być bardzo mało rzeczy, o które się martwisz. Jeśli zatrudniasz złych ludzi, jesteś zatopiony bez względu na wszystko. Skoncentruj się na zatrudnianiu dobrych ludzi i pozwól temu się przesuwać.

— David Thornley
źródło

4

Dlaczego Twoi potencjalni klienci powinni ci ufać dzięki takim finansom?

W końcu możesz uciec z pieniędzmi.

Firmy takie jak Microsoft, Google, IBM zatrudniają tysiące ludzi do pisania ryz oprogramowania zamkniętego i nie martwią się zbytnio o to, że ich pracownicy odejdą z kodem. Wydaje się, że obejmuje to ochrona praw autorskich i wyraźna klauzula „każdy kod należy do twojego pracodawcy” w umowie o pracę, a sprawy sądowe przeciwko byłym pracownikom o kradzież kodu są niezwykle rzadkie.

Co więcej, po opublikowaniu oprogramowania na całym świecie, chyba że rdzeń wymaga naprawdę zaawansowanej matematyki, każdy kompetentny zespół programistów może odtworzyć twoją aplikację bez oglądania kodu źródłowego.

— James Anderson
źródło

3

Jak wspomnieli inni, wydaje się, że dotyczy to przede wszystkim ludzi.

Istnieje jednak wielu głównych dostawców zabezpieczeń, którzy sprzedają oprogramowanie do wycieków danych:

Nie mogę wypowiedzieć się na temat ich skuteczności lub stosowności, ponieważ mam ograniczone doświadczenie z tymi rozwiązaniami, ale pomyślałem, że wskazanie tego może być pomocne.

— Klif
źródło

3

Podobnie jak pomysł, jedynym zmartwieniem jest to, że te produkty są pełne języka korporacyjnego i nie wyjaśniają, co tak naprawdę robią :)

— Mars Robertson,

2

Szczerze mówiąc, jak wszyscy mówili, musisz zaufać swoim programistom.

Dodam jednak do tego stwierdzenie, że naprawdę powinieneś wziąć pod uwagę, że otwarte pozyskiwanie projektów w dzisiejszym środowisku jest bardziej prawdopodobne, że pomoże ci niż skrzywdzi cię, z wyjątkiem kilku konkretnych rynków. Po prostu bycie bardziej otwartym na ten pomysł sprawi, że będziesz mniej martwił się tym, że Twój kod źródłowy rośnie i ucieka, nawet jeśli sam tego nie zrobisz. Zdobądź całą dobrą wolę, a moim zdaniem bardziej prawdopodobne jest, że zarobisz pieniądze. Nawet gdyby Imperium oferowało najlepszą aplikację na świecie, nie sądzę, by Luke Skywalker ją pobrał, ponieważ ideały Imperium były w niewłaściwym miejscu.

— koder543
źródło