Dlaczego duże firmy korzystają z Perforce? [Zamknięte]

Słyszałem o niektórych dużych firmach, np. Google, Facebook używają Perforce

Czy jest jakiś powód, dla którego SVN / Git nie może zastąpić Perforce?

Uzasadnienie jest być może mniej istotne niż kiedyś, ale Perforce ma większą wydajność na dużych repozytoriach niż Subversion. Jest to jeden z powodów, dla których Microsoft nabył licencję źródłową dla Perforce na budowę Source Depot; Repozytorium NT jest potworem i niewiele produktów, komercyjnych lub innych, mogłoby sobie z tym poradzić.

Ponadto, przynajmniej kiedyś, wizualne narzędzia Perforce były znacznie lepsze niż to, co jest dostępne po wyjęciu z pudełka (że tak powiem) z Subversion lub Git. Jeśli używasz Melda, być może te rzeczy mają mniejsze znaczenie niż kiedyś, ale wciąż jest kilka rzeczy, które Perforce zrobił bardzo ładnie, w tym wizualizacje rozgałęzień i scalania, o których, chociaż nie mam szczegółowej pamięci, odkąd zostały około 3 lata od ostatniego dotknięcia Perforce wydawały się bardziej wyrafinowane niż, na przykład, podejście Githuba do tego.

Po skorzystaniu z Perforce możesz zrozumieć, jakie są jego zalety w praktyce. Od dawna oferują bezpłatną opcję serwera dla dwóch użytkowników, a w zależności od systemów zarządzania kodem źródłowym, z którymi masz doświadczenie, może być warto kosztować aktualizacji po tym, jak Twój zespół przetestuje go przez jakiś czas. W przypadku mniejszych sklepów to, plus efekty sieciowe programistów, którzy go używali i polubili, są powodem, dla którego Perforce zyskuje płacących użytkowników. W przeciwieństwie do cynicznych uwag Dmitrija, prawdopodobnie nie ma zbyt wielu wygranych i posiłków dla CTO, aby sprzedawać Perforce w firmach z małymi zespołami programistycznymi.

Większość projektów, nad którymi pracowałem poza Microsoftem, może być dość dobrze obsługiwanych przez Git, Mercurial lub Subversion, i powiedziałbym, że większość firm, w których pracowałem, używa jednej z tych opcji. Ale jest pewna słaba strona, zwykle połączenie wielkości repozytorium, modelu rozgałęziania i scalania oraz doświadczenia / historii zespołu, które prowadzą ludzi do korzystania z narzędzi komercyjnych. Na przykład rzadko widywałem duże repozytoria Git. Może to nie wynikać z wewnętrznych ograniczeń Git; Przyznaję, że jestem tego całkowicie nieświadomy. Ale w niektórych projektach (takich jak Windows NT) mogą istnieć pewne praktyczne ograniczenia bezpłatnych rozwiązań.

Jestem dość biegły w svn, git i Perforce, zarówno jako użytkownik, jak i przy konfigurowaniu i utrzymywaniu serwerów.

Dla firmy, a nawet samotnego programisty, takiego jak ja, kontrola źródła jest kosztem poniesionym na wsparcie działalności polegającej na zarabianiu pieniędzy, która polega na opracowywaniu i sprzedaży kodu. Dlatego należy wziąć pod uwagę kilka czynników:

• Jak dobrze pasuje do twojego modelu programistycznego?
• Jak łatwo programiści mogą się uczyć i używać?
• Czy rutynowe operacje dla programistów są szybkie?
• Czy proces używania go odwraca uwagę od ich prawdziwej pracy, jaką jest pisanie kodu?
• Jak łatwo jest skonfigurować i utrzymywać?
• Ile kosztuje zakup i utrzymanie?
• Jeśli potrzebujesz pomocy, jak łatwo ją zdobyć?

Pominę szczegóły tl: dr na temat zalet i wad poszczególnych systemów. Wystarczy powiedzieć, że kiedy wróciłem do konsultacji w pełnym wymiarze godzin w zeszłym roku, przejrzałem wszystkie trzy, aby zdecydować, które pozwolą mi jak najszybciej zarobić jak najwięcej pieniędzy, dostarczając wysokiej jakości oprogramowanie moim klientom i nie wymagając dużo niepłatnych wygłupiać. Kiedy wziąłem pod uwagę polityczną opinię, że „FOSS jest dobry, a nie-FOSS jest zły” z równania, skończyło się na tym, że starałem się o licencję Perforce.

I dlatego duże firmy wybierają również Perforce.

Oto szczegóły tl: dr z komentarzy oraz trochę więcej.

Adresowanie svn jest łatwe: w porównaniu z Perforce jest powolne. Pracowałem w firmie, która osadziła Linuksa na telefony komórkowe, a nasze pełne źródła dysponowały 9 GB; używali Perforce. Po otrzymaniu kodu aktualizacja najnowszych źródeł zwykle zajmuje kilka sekund w sieci LAN lub kilka minut przez połączenie VPN z mojego domu. W przypadku svn byłyby to odpowiednio minuty i godziny.

git vs. Perforce jest bardziej skomplikowany. Wiele firm uważa, że ​​mają dobre powody biznesowe, aby korzystać ze scentralizowanego repozytorium z kontrolą dostępu, aby ułatwić dokonywanie zleceń i utrudnić wykonywanie innych czynności - a Perforce idealnie pasuje do tego modelu. Jednak git pozytywnie zachęca ludzi do pracy w lokalnym oddziale i nie ma sposobu, aby działał inaczej. Deweloper może pracować całkowicie w lokalnym oddziale i nigdy nie angażować się w centralne repozytorium - więc jeśli firma nie chce, aby ludzie tak pracowali, Perforce jest lepszą opcją.

Istnieją inne problemy z git dla niektórych potrzeb biznesowych. Pracowałem w firmie, która korzystała z git i nie wiem, ile razy słyszałem tę dyskusję: „Chciałbym, żebyśmy korzystali z [innych VCS], ponieważ muszę to zrobić i nie mogę z git . ” „Oczywiście możesz to zrobić za pomocą git”. "W jaki sposób?" „Cóż, najpierw musisz napisać skrypt bash ...” „Nieważne.”

A potem jest czas, który zajmuje początkowe wypełnienie drzewa źródłowego, które ma wiele historii. Dzięki Perforce, ponieważ historia jest przechowywana na serwerze, po prostu otrzymujesz najnowsze wersje wszystkich plików, więc jest to naprawdę szybkie - nawet skonfigurowanie całego drzewa 9 GB, o którym wspomniałem, zajęło tylko kilka godzin w sieci VPN. Z git może trwać od długiego czasu do wieczności. Czasami muszę sklonować repozytorium git GTK + lub X serwera, a to długa przerwa na lunch, a może czas na spanie.

Naprawdę jest to kwestia odpowiedniego narzędzia do pracy. svn działa dobrze w przypadku większości działań Apple na open source i byłby okropny dla hakowania jądra. git działa świetnie dla GTK +, ale jest niesamowicie powolny do pracy w WebKit - drzewo źródłowe i historia są po prostu zbyt duże (jak dowiedziałem się, jak ciężko pracować z kodem z portalu svn-to-git WebKita). Perforce działa dobrze, jeśli masz gigantyczne drzewo źródeł i potrzebujesz scentralizowanej kontroli. Każdy z nich działa dobrze we właściwym kontekście.

Zwłaszcza GIT, a SVN do pewnego stopnia nie jest już tak stary - jeśli potrzebowałeś solidnej kontroli wersji w połowie lat 90., prawie musiałeś zacząć działać komercyjnie, ponieważ SVN był w powijakach, a CVS był, cóż, CVS. Kiedy już zainwestujesz dużo w system, przeniesienie go może być niedźwiedziem.

Och, a faceci, którzy podejmują te decyzje, prawdopodobnie nigdy nie wchodzą w interakcje z systemem kontroli wersji, ale wygrywają i jedzą wspomniani wcześniej sprzedawcy.

Od prawie 9 lat jestem programistą w branży gier i każdy projekt, nad którym kiedykolwiek pracowałem, wykorzystywał Perforce. Podejrzewam, że jest kilka rzeczy, które utrzymują Perforce w użyciu w tej konkretnej branży.

• Ludzie używają Perforce od dłuższego czasu i czują się z tym komfortowo, przez co wahają się przed przejściem na inne rozwiązanie. Decydenci mogą również wahać się, czy oddać swój projekt o wartości 30 milionów dolarów w ręce oprogramowania, z którego nigdy wcześniej nie korzystali.
• Wiele firm / zespołów dodało obsługę Perforce do swoich wewnętrznych narzędzi, co może wymagać znacznej pracy, aby zaktualizować obsługę innego VCS.
• Podczas gdy programiści mogą łatwo przestawić się na inną Git / Hg / SVN, jest wielu mniej technicznych członków zespołu tworzącego gry, takich jak artyści, projektanci i producenci. Zapewnienie im komfortu dzięki nowemu systemowi może zająć dużo czasu i byłbym skłonny się założyć, że byliby dość odporni na zmianę.

Może może lubią Perforce, ponieważ Perforce jest lepszy?

• Perforce jest szybki. Znacznie szybszy niż Subversion czy Git.
• Łączenie na siłę jest lepsze niż Subversion lub Git. Git tak naprawdę nie łączy, a śledzenie wersji Subversion nie jest tak dobre, przynajmniej w wersji 1.5.
• Perforce ma doskonałą obsługę klienta.
• Perforce łączy rewizję repozytorium Subversion z indywidualnymi wersjami plików. Perforce umożliwia przeglądanie wersji repozytorium za pomocą list zmian lub indywidualnych wersji plików.
• Perforce wykonuje znacznie lepszą pracę z wieloma listami zmian niż Subversion. Listy zmian Subversion są nieco później przemyślane i znam niewielu, którzy z nich korzystają. Perforce jest wbudowany. Jeśli przeniesiesz zmieniony plik z domyślnej listy zmian, nie zostanie on przypadkowo zatwierdzony.
• Perforce pozwala określić układ katalogu roboczego. Na przykład, jeśli masz standardowe drzewo katalogów kodu źródłowego, ale niektórzy klienci mają niestandardowe źródło, możesz nałożyć niestandardowe źródło na standardowe drzewo. Możesz łatwo robić rzadkie kasy, określając tylko te elementy, które chcesz zrealizować.

Dobra, zanim pomyślisz, że jestem fanem Perforce, ostatni raz poleciłem Perforce firmie ponad siedem lat temu. Perforce kosztuje 800 USD za licencję - co jest tanie w porównaniu z ClearCase, ale znacznie droższe w porównaniu z Subversion. Mam trudności z uzasadnieniem Perforce nad Subversion.

Ponadto większość programistów korzysta z Subversion. Nie chcą się uczyć Perforce, który ma inny sposób działania niż Subversion. W Perforce musisz utworzyć klienta i oznaczyć pliki do edycji, zanim będziesz mógł je zmodyfikować. Nie musisz tego robić z Subversion.

Istnieje również mniej integracji z Perforce nad Subversion. Częściowo wynika to z użytkowania klienta . Po prostu nie działa dobrze z VisualStudio lub nawet Hudsonem. Częściowo wynika to z faktu, że Perforce musi tworzyć integracje klienta.

Koszt licencji praw własności wywołuje koszt administracyjny. Wyobraź sobie, że możesz licencjonować oprogramowanie za 1,00 USD za użytkownika. Cholera, zróbmy dwa bity. Tysiące licencji kosztuje tylko 250 USD.

Teraz potrzebujesz pełnoetatowej osoby zarządzającej licencją. Przeciętny pracownik techniczny pozostaje w firmie przez około 2 lata. Oznacza to, że każdego roku wyjedzie 500 osób, a kolejnych 500 przyjedzie. Każdego tygodnia dziesięć osób musi zmienić licencję. Są chwile, kiedy projekt zaczyna się i potrzebujesz kolejnych 250 licencji. Te muszą być zamówione, wprowadzone i utrzymane. To może potrwać tygodnie.

Dlatego wiele firm komercyjnych przeszło na oprogramowanie typu open source. To nie jest koszt licencji. Płacisz programistom 150 000 USD rocznie, co to jest kolejne 800 USD za licencję Perforce? Zarządza tą licencją. Perforce wygląda świetnie w porównaniu z ClearCase: szybciej, łatwiej, taniej, lepiej. Ale przeciwko Subversion? Siła może być szybsza, a może i lepsza, ale czy jest o 800 USD lepsza? Czy lepiej zarządza licencją? Czy nie używa lepszego pożądanego narzędzia?

Dlatego Perforce może mieć problemy.

Git nie jest ostatecznym narzędziem. Działa świetnie w sytuacjach, gdy nie chcesz scentralizowanej kontroli nad tym, kto ma dostęp do repozytorium. Ale może to być ból w wielu okolicznościach. Mówię tak:

1. Prowadzisz projekt typu open source. Czy byłbyś szczęśliwy lub zdenerwowany, gdyby milion osób posiadało kopię całego Twojego repozytorium?
2. Prowadzisz biuro handlu finansowego, które korzysta z zastrzeżonego oprogramowania, aby uzyskać przewagę nad konkurencją. Czy byłbyś szczęśliwy lub zdenerwowany, gdyby milion osób posiadało kopię całego Twojego repozytorium?

Jeśli wykonujesz scentralizowane kompilacje, wszyscy i tak powinni korzystać z jednego repozytorium. Jakie są zalety systemu rozproszonego w takich okolicznościach? W rzeczywistości może zachęcać ludzi do pracy offline . Programiści mogą po prostu pójść swoją własną wesołą drogą i nie popełnić niczego do ostatniej chwili. Następnie spędzasz dwa szalone dni, próbując sprawić, by wszystko znów działało.

Nie jestem przeciwko Gitowi. W wielu przypadkach polecałem Git. Należą do nich rozproszone zespoły o słabych połączeniach ze sobą lub miejsca, w których nie chcesz śledzić wszystkich, którzy mają dostęp do repozytorium źródłowego.

Na przykład wydział informatyki na uczelni chciał, aby ich uczniowie korzystali z kontroli źródła i umieścili tam swój kod, aby nauczyciele mogli je obejrzeć. Świetny pomysł. Zbyt wiele dzieci kończy naukę bez zrozumienia standardowych procedur budowania i rozwoju. Poleciłem Git.

Korzystając z Git, administrator repozytorium musi jedynie przyjmować zatwierdzenia od innych profesorów. Nie muszą się martwić o poszczególnych uczniów. Profesorowie mogą pozwolić uczniom na zaakceptowanie ich wersji repozytorium. Uczniowie mogą pracować w grupach, a każda grupa może udostępniać swoją wersję repozytorium.

Gdyby uczelnia korzystała z Subversion, ktoś musiałby znać wszystkich studentów i dać im dostęp do centralnego repozytorium. Musieliby zarządzać, kto może sprawdzić, co i gdzie. Jeśli profesor przypisał projekt grupowy, należałoby go skonfigurować i zarządzać. Potrzebowałbyś osoby pełnoetatowej, żeby sobie z tym poradzić.

To nie jest mecz piłkarski, w którym jedna drużyna jest lepsza od drugiej. Narzędzia działają na różne sposoby, a każdy z nich ma swoje zalety i wady. Perforce to świetne narzędzie. Niestety, pojawiły się okoliczności, które sprawiają, że trudno go polecić.

Git jest świetny, ale wciąż wracam do Subversion dla mojego osobistego repozytorium źródeł. W końcu nie udostępniam go, a Subversion jest po prostu łatwiejszy w użyciu. Używam Gita do pracy osobistej, jeśli mam mały zespół, ponieważ nie muszę utrzymywać mojego repozytorium przez cały czas w Internecie. W przypadku większości witryn komercyjnych nadal uważam, że Subversion działa najlepiej. Ale są okoliczności, w których Git świeci.

Nie wiem, czy przekupstwo „wino i obiad” nadal ma zastosowanie, ale dla większości menedżerów, którzy decydują się na znalezienie produktu, przeczytają je w różnych publikacjach (skierowanych do kierownictwa) i przejrzą broszury i broszury wychwalające produkty cnoty.

Zgadnij co, produkty FOSS nie pojawiają się w tych miejscach!

Jest więc prawie pewne, że większość decyzji zakupowych kierownictwa wynika z reklamy i marketingu. Mogą przeprowadzać oceny, ale kilku takich produktów.

Drugi powód wynika z dojrzałości. Niektóre produkty, z których korzystamy dzisiaj, są wystarczająco stabilne do poważnego użytku w biznesie, niektóre nie mają opcji wsparcia, niektóre nie mają udokumentowanych osiągnięć jako rozwiązań biznesowych. Są to ważne rzeczy do rozważenia (chociaż jako technik chętnie ocenię rozwiązania FOSS, jeśli ryzyko ich użycia i ich porażki jest minimalne, aby utrzymać działalność firmy), a niektórzy menedżerowie słusznie obawiają się ich nie mieć. Są odpowiedzialni przed swoimi szefami i czują się znacznie bardziej komfortowo, jeśli za produktem stoi organizacja wsparcia - w końcu masz taką dla swojej firmy.

Wreszcie, podczas gdy wiele produktów FOSS ma za sobą wsparcie (pomyśl Collabnet lub Wandisco dla SVN), nadal zyskuje reputację „zrobione przez maniaków w ich tylnej sypialni”. Wszyscy wiemy, że jest to ogólnie b * * ** t, a najlepszy FOSS niewiarygodnie dobrze konkuruje z ofertami komercyjnymi, ale mój menadżer nadal musi być przekonany. może po prostu nie zdaje sobie sprawy z różnicy między niedojrzałymi i dojrzałymi produktami FOSS; może go to nie obchodzi.

W każdym razie Perforce jest dobrym SCM, nie ma powodu, aby go nie wybierać. Mógłbym powiedzieć to samo w przypadku innych SCM, ale znowu mogę powiedzieć tylko złe rzeczy o niektórych innych i wciąż mam koszmary, jeśli chodzi o kilka produktów.

Ponieważ narzędzia takie jak Perforce mają sprzedawców wina i jedzą ludzi odpowiedzialnych za zakupy, podczas gdy Git tego nie robi. Oczywiście, to tylko cyniczna strona mojego mówienia, ale jest to cynizm wywołany widzeniem procesu z bliska.

Żeby było to całkowicie jasne: nie mam na myśli, że za każdym razem, gdy zobaczysz, jak Twój CIO potknie się pijany korytarzem, spodziewaj się, że w następnym kwartale będziesz używać nowego systemu kontroli wersji. Tyle, że w wielu organizacjach istnieje rozbieżność między użytkowaniem a nabywaniem. Oczywiście istnieją inne powody, dla których firmy korzystają z Perforce: na przykład mogły już dużo zainwestować w jego wdrożenie w swoim przepływie pracy. Ale ogólnie --- i to pytanie jest bardzo ogólne --- nie ma korzyści funkcjonalnej, że nie używa się narzędzi FOSS.

Prawdopodobnie z tego samego powodu, dla którego moja firma odmawia korzystania z wielu programów typu open source (nie zgadzam się):

Kiedy coś pójdzie nie tak, chcą kogoś, do kogo mogą zadzwonić i krzyczeć.

Podczas gdy wszystkie odpowiedzi mówią o dużych firmach korzystających z P4 (i odpowiadają, dlaczego Google używał P4), jednym z głównych powodów, dla których Google nadal korzysta z Perforce, jest to, że Perforce pozwala ci sprawdzić poddrzewo repozytorium, podczas gdy nie możesz tego zrobić za pomocą Git. Dzięki dużym repozytoriom źródeł, takim jak Google, zrobiło to ogromną różnicę.

I o ile słyszałem, Facebook używa SVN i Git-SVN

Ponieważ SVN jest, no cóż, SVN i Perforce (od czasu, gdy 4 lata temu przy porównywaniu narzędzi) robi pewne rzeczy lepiej niż SVN . (Myślę, że rozgałęzienie jest jednym z nich.)

A GIT jest Dvcs, podobnie jak w dystrybucji . Dla zespołów firmowych część rozproszona może być czymś, na co nie zależy ani nie chce.

Kolejny powód, dla którego duże firmy kupują duże, nieporęczne, „korporacyjne” systemy kontroli wersji:

Kierownictwo średniego i wyższego szczebla w działach IT postrzega VCS jako coś, z czego korzysta każdy projekt, lub można go egzekwować. Gdy już narzucisz użycie VCS, dlaczego nie wprowadzić tam również małego „procesu”? Mam na myśli możliwość określenia systemu „dla całego przedsiębiorstwa”, dlaczego nie przejąć go pod centralną kontrolą, i dodać „odzyskiwanie po awarii” i niektóre „funkcje przepływu pracy”, aby można było powiedzieć „Jesteśmy StraightJacket na poziomie CMM” zgodny!". VCS jest po prostu zbyt łatwym celem, aby wprowadzić funkcje wymuszania przepływu pracy, oto co sprowadza.

Jeśli chodzi o wybór jakiegoś dziwacznego, nieprzyzwoitego oprogramowania (Serena Dimensions), mówi się, że kilka rund bikini Golf na Bahamach z kilkoma 20-osobowymi sprzedawczyniami może przekonać dyrektora lub wiceprezesa o wszystkim.

Duże firmy potrzebują pewnego rodzaju scentralizowanego modelu. Gdy programiści skończą programowanie, zostaje przekazany do obsługi klienta. Czy naprawdę chcesz być w butach wspierających, gdy muszą przeczesywać 50-200 rozproszonych repozytoriów programistów? Kompilacje są wykonywane w oparciu o centralne repozytorium, kompilacje muszą zawsze, zawsze, zawsze być identyfikowalne i odtwarzalne. Dowiesz się o tym, kiedy po raz pierwszy zostaniesz postawiony przed sądem z powodu jakiegoś głupiego naruszenia patentu.

Git nie działa tak dobrze w tym modelu. Jeśli masz mniejszą firmę lub taką, która ma słaby dostęp do VPN, to właśnie tam naprawdę świeci.

Jednym z powodów, dla których większość dużych firm korzysta z Perforce, może być więcej specjalistów w dziale IT, którzy mają dużą wiedzę na ten temat i mają wieloletnie doświadczenie w rozwiązywaniu problemów z tym związanych.

Wydaje mi się, że w przyszłości firmy mogą zacząć odchodzić od Perforce i bardziej w kierunku GIT ... większość programistów, których znam, wydaje się preferować !! Sprawdź również http://whygitisbetterthanx.com/#git-is-fast w celu uzyskania dalszych dowodów na to, dlaczego Perforce może nie być tak dominujący w nadchodzących latach !!

Kilka razy temu przeszliśmy z zestawu VCS (wiem na pewno, że RCS, CVS, ClearCase, Perforce były wcześniej używane, mogą być też inne) na Perforce jako unikalny system w użyciu. To nie był mały projekt: migracja zajęła ponad rok. Zespół (którego nie byłem częścią) ocenił kilka VCS, a przynajmniej git i svn zostały wzięte pod uwagę, a także te już używane. Jak pamiętam ich raport, odfiltrowali narzędzia bez potrzebnych funkcji, a następnie rozważyli:

• wydajność w typowym użyciu, szczególnie w przypadku witryn zdalnych

• wymagania dotyczące zasobów

• znaczenie niezbędnych zmian w nawyku pracy

• obsługa dostępności i kosztów

a Perforce był całkiem wyraźnym zwycięzcą. git był nieco lepszy dla pierwszego punktu, ale w niekorzystnej sytuacji dla innych.

Dawno, dawno temu (kiedy IDE nazywało się VI), jedynymi darmowymi (open source) systemami były CVS, RCS i SCCS.

• Żadna z nich nie poradziłaby sobie nawet dobrze ze zmianą nazwy pliku.
• Nie rejestrowali połączeń, więc jeśli aktywne były dwie gałęzie, bardzo trudno było je scalić, dopóki prace nie zakończyły się w jednej gałęzi.
• Nie skalowały się dobrze do bardzo dużych baz kodu
• Nie zapewniały one poziomu kontroli dostępu i informacji o procesie, którego chcieli duże projekty.

Było wiele komercyjnych systemów kontroli kodu źródłowego, większość z nich została dostarczona przez jednego dostawcę maszyn (IBM, DEC, HP itp.) I działała tylko na ich sprzęcie.

Następnie kilka firm oświadczyło, że sprzedaje komercyjny system kontroli kodu źródłowego na wielu platformach, w tym Perforce i ClearCase.

ClearCase został zbudowany na RPC, który nie działał dobrze w sieciach rozległych (ale tylko w Internecie) z powodu dużej liczby małych pakietów sieciowych, które były „okrągłe”, również IBM i racjonalne postrzegały ClearCase jako „krowę gotówkową” i nigdy nie pokazały tego zbyt wiele miłość.

Zatem jedynym „starym” komercyjnym systemem kontroli kodu źródłowego, który jest nadal w powszechnym użyciu, jest Perforce. Gdy perforce jest używane i zintegrowane z systemami kompilacji i systemami śledzenia błędów, firma ma bardzo niewielkie korzyści krótkoterminowe dla firmy, aby przejść na cokolwiek innego.

Podsumowując, perforce dostało „stopę w drzwi”, gdy nie było wielu innych opcji, a oni nie zrobili jeszcze bałaganu, aby ludzie się od niego oddalili .