Jak skutecznie konkurować z projektem open source?

Firma z solidnym projektem open source konkurującym z tradycyjnym produktem zamkniętym wydaje się niemożliwa do pokonania.

Czytam ten artykuł, w którym autor przedstawia następujący scenariusz:

Załóżmy, że można podzielić rynek oprogramowania - powiedzmy zarządzanie siecią - na dwa produkty. Jeden zrobił wszystko, co możliwe i kosztował 1 milion USD, a drugi tylko 10% tyle, ale był darmowy i otwarty.

Metka ceny komercyjnego rozwiązania automatycznie odfiltrowałaby dużą liczbę użytkowników, a ci ludzie musieliby zwrócić się do otwartego oprogramowania. Ale niektórzy użytkownicy byliby zadowoleni z 10% funkcjonalności i wybrali ją wprost.

Na przykład mam na swoim komputerze oryginalny komputer Macintosh. Działa z edytorem tekstu o nazwie MacWrite. Robi wszystko, z wyjątkiem sprawdzania pisowni, do wykonania których potrzebuję edytora tekstu. Mogę formatować akapity, wybierać czcionki, pogrubić tekst lub kursywę, a nawet wkleić zdjęcia i wykresy. Wszystko w interfejsie użytkownika „to, co widzisz”.

Zajmuje 76 KB miejsca na dysku. To jest „K” jak w „kilobajcie”.

Porównaj to z Microsoft Word. Myślę, że kiedy ostatni raz instalowałem program Word, był on około 30 MB, wiele razy większy niż MacWrite, ale nie używam go o wiele dłużej niż MacWrite. Podobnie jak ja, wielu użytkowników jest zadowolonych z podstawowej funkcjonalności. Nie potrzebują wszystkich dzwonków i gwizdków.

Ale wracając do mojej analogii. Na początku firma komercyjna prawdopodobnie zignoruje projekt open source. Nie stanowi to żadnego zagrożenia dla ich strumienia dochodów, więc dlaczego mieliby zwracać uwagę na wzrost?

Jeśli ten projekt jest zdrowy i trwały, to jednak w ciągu około roku może stanowić 15–20% tego, co robi produkt komercyjny. To powinno odciąć kilku innych użytkowników od ich firmy i być może teraz zaczną zwracać uwagę.

Najprawdopodobniej ta uwaga przybrałaby formę marketingu przeciwko projektowi. Twierdziliby, że jest za mały lub zbyt słabo przygotowany, aby brać go na poważnie. I w krótkim okresie prawdopodobnie to zadziała. Ale sam fakt, że uznali projekt, wzbudzi zainteresowanie. Niektórzy ludzie sami stwierdziliby, że nie jest ani za mały, ani zbyt słabo rozwinięty i zaczęli go używać.

Minął kolejny rok lub dwa, a teraz projekt stanowi do 50% funkcjonalności produktu komercyjnego. Ludzie zaczynają dołączać do projektu w tłumach. Firma handlowa musi teraz coś zrobić. Co oni robią? Dodają więcej funkcji.

Pamiętaj, że produkt komercyjny zrobił już 100% tego, czego ludzie potrzebowali. Jakie funkcje mogliby dodać? Niepotrzebne. Mogą zmienić wygląd interfejsu użytkownika lub dodać funkcje poza zarządzaniem siecią. W każdym razie ten rozwój będzie kosztował pieniądze, a to zacznie pochłaniać marże firmy.

Wreszcie, przy zdrowej społeczności i napływie nowych użytkowników, projekt open source ostatecznie zbliży się do 80% -90% tego, co robi produkt komercyjny. Po wyczerpaniu wszystkich możliwości generowania przychodów firma handlowa ma jeszcze jedną ostateczną opcję: przykręcić śruby pozostałym klientom. Znajdź sposoby na obciążanie ich większą kwotą, aby wydobyć, co mogą z ich inwestycji, co ostatecznie odstraszy ich klientów.

Dalekosiężnie? Nie wydaje mi się Są tylko dwa główne wymagania:

Po pierwsze, znajdź rynek, na którym open source stanowi atrakcyjną alternatywę, taką jak zarządzanie siecią.

Po drugie, zbuduj zrównoważoną społeczność wokół projektu open source.

Wydaje się to bardzo prawdopodobne. Gdybyś był firmą zamkniętą, jak konkurowałbyś?

Ponieważ nie możesz konkurować ceną, konkuruj we wszystkich innych punktach sprzedaży oprogramowania:

• cechy
• jakość
• skuteczność
• integracja z innym oprogramowaniem
• usługa
• wsparcie
• sprzedaż bezpośrednia

Zasadniczo robisz to, co robi każda inna firma, gdy konkurują cenowo: nadążaj lub zmieniaj grę.

Dzięki ulepszeniu produktu w stosunku do oferty typu open source. W ten sposób Photoshop może konkurować z GIMP.

Myślę, że wspomniany kawałek jest bardzo mylący, ponieważ całkowicie pomija jakość oferty typu open source. Zadaj sobie nieco inne, ale powiązane pytanie:

Jak firma może przetrwać, sprzedając oprogramowanie open source?

Ponieważ sam często uczestniczę w kilku projektach typu open source, mam uzasadnione prawo do zrzucania kilku rund błota tam, gdzie na to zasługuje.

Żadne z poniższych stwierdzeń nie dotyczy projektów Star OSS, takich jak Linux, Firefox, MySQL lub PostgreSQL. Są to nietypowe, ponieważ są wspierane przez firmy i / lub doświadczonych programistów.

W każdym razie, z powodów, dla których klient zapłaci za oprogramowanie:

OSS ma skłonność do pełzania funkcji / Klienci płacą za prostsze oprogramowanie

Wszyscy współautorzy OSS mają swoją funkcję zwierzaka. W końcu znajdą drogę do bazy kodu. Aby uniknąć tego problemu, konieczne jest bardzo doświadczone, stanowcze i charyzmatyczne przywództwo, a jak każdy inny facet, wielu deweloperów OSS nie ma co najmniej jednej z tych cech.

Dodając obrazę do obrażeń, dla każdej nieistotnej funkcji, która się wkrada, inna nie będzie tego chciała, a to spowoduje dodanie opcji. Koderzy lubią opcje, ale z punktu widzenia interfejsu są pewną drogą do powolnej i bolesnej śmierci o tysiąc cięć.

Użytkownicy końcowi chcą prostych narzędzi. Muszą wykonać swoją pracę bez krzywej uczenia się i zamieszania. Chcą, aby ich narzędzia podejmowały właściwe dla nich decyzje; nie opcje. Jeśli możesz dostarczyć coś prostszego niż samodzielna implementacja OSS, dostaniesz płacących klientów.

OSS ma niską jakość / Klienci płacą za wyższą jakość

Pamiętaj, że nie ma nic złego w nauce kodowania poprzez wkład w OSS.

Trzeba jednak powiedzieć, że dla każdej wysokiej jakości OSS lub biblioteki, która jest wspierana z różnych powodów przez korporacje i doświadczonych programistów, istnieje ocean podatnego na błędy kodu spaghetti napisanego przez niedoświadczonych programistów, którzy wnoszą wkład w OSS aby uczyć się programowania, a którzy mają niewiele jeśli w ogóle pomysł na to, co robią.

Na przykład WordPress został rozwinięty z B2 (sam projekt przez studenta) przez studenta. Wiele wersji i niezliczona ilość taśmy klejącej później wykonuje zadanie. Ale pod maską jest to zalew błędów z niewielką, jeśli w ogóle, kontrolą jakości. (Ostatnio próbowałem, nie udało się pomyślnie przejść własnego zestawu testów).

Klienci zapłacą za dobrze utrzymane i przetestowane oprogramowanie. Pamiętaj, że prawie wszyscy wypróbują darmowe rzeczy, a wielu z nich nawet do pewnego stopnia toleruje błędy. Ale jeśli od tego zależy ich przychód, w końcu będą szukać oprogramowania wyższej jakości i za to zapłacą.

OSS zwykle ma za krótki cykl programowania / Klienci płacą, aby uniknąć kłopotów

Jest to nieodłączne od procesu rozwoju. Funkcje zwierząt domowych, które są wpychane do bazy kodu, muszą zostać wydane w rozsądnym czasie. Jeśli nie, istnieje ryzyko, że projekt OSS straci część swoich współpracowników.

Jednak w dłuższej perspektywie firmy preferują długie cykle wydawnicze; im dłużej, tym lepiej. To mniej planowania i mniej pracy dla działu IT. Nic dziwnego, jeśli użytkownicy końcowi aktualizują przeglądarkę co trzy miesiące. To zupełnie inna historia, jeśli aktualizujesz aplikacje o kluczowym znaczeniu.

Niedawno odbyła się dyskusja na temat przyspieszenia cyklu wydania na liście hakerów PostgreSQL. Ostatnim argumentem przeciwko nie była kwestia kontroli jakości i potrzeby przedłużenia okresów testów beta. Było tak, że niektóre firmy już pomijały każdą inną wersję, ponieważ bieżący (roczny) cykl wydawania był dla nich zbyt szybki.

Porównaj się z WordPress, który co jakiś czas debatuje nad trzymiesięcznym cyklem wydawniczym, pomimo już zbyt krótkiego cyklu. (Ich wersje beta, pod każdym względem, są wersją xy0 każdego wydania.)

Mając kilku klientów korzystających z WordPress, zapewniam cię, że są bardziej niż szczęśliwi, że się nimi opiekuję, aby ich witryny nie wybuchły im w twarz podczas aktualizacji. Klienci zapłacą za to, że nie będą musieli się martwić tego rodzaju kłopotami.

OSS zwykle bezmyślnie przyjmuje otwarte standardy / Klienci potrzebują tylko rzeczy do pracy

Przykładem jest tu tag wideo HTML5.

Argumentem Mozilli za odrzuceniem h.264 jest to, że chcą kodeka open source. I mają w tym sensie absolutną rację: ostatnią rzeczą, jakiej chcą, jest być na liście hitów patentowych trolli; więc naciskają na Ogga.

Z drugiej strony sprawa Apple do przyjęcia h.264 jest praktyczna: jest już szeroko obsługiwana i ma przyspieszenie sprzętowe (co pozwala wydłużyć żywotność baterii iPhone'ów); dla Ogga nie ma czegoś takiego.

Miliony urządzeń z iOS sprzedanych później, witryny martwiące się dostarczaniem wideo do tych użytkowników iOS obsługują HTML5 / h.264. Innymi słowy, klienci mówili: nie dbają o otwarte formaty.

Jedyną firmą, która jest zadowolona z wyniku tej jadowitej walki o kodeki, jest Adobe: użytkownicy Firefoksa będą de facto nadal potrzebowali Flasha, jeśli chcą odtwarzać filmy. Jeśli główna witryna przełączy się na filmy wyłącznie w formacie html5 / h.264, koder szybko zaproponuje rozszerzenie lub wtyczkę do konwersji potrzebnych tagów wideo na odtwarzacze flash. (Może nawet już istnieć.) W imię wspierania otwartych standardów (które, nawiasem mówiąc, nie są).

Nikt nigdy nie został zwolniony za wybranie IBM

To stary żart z branży, ale jest w tym prawda: gdy dysponujesz budżetem IT, nie zostaniesz zwolniony za wybranie tego, co rówieśnicy uważają za najlepsze w swojej klasie.

Duzi nabywcy korporacyjni, którzy nie chcą ryzykować, będą nadal kupować komputery stacjonarne Microsoft, Office, SAP i tak dalej; nawet jeśli istnieją alternatywy typu open source. Podobnie dzieje się z gównem .

Kiedy OSS wkracza do dużych środowisk korporacyjnych, zwykle nie dzieje się tak dlatego, że CTO zobaczył światło i zdecydował się skorzystać z bezpłatnych narzędzi; raczej jest kierowany przez stronę trzecią, która oferuje (drogie) usługi na górze.

Myślę, że sedno argumentu, że „produkt komercyjny zrobił już 100% tego, czego ludzie potrzebowali”, polega na tym, że argument się rozpada. Żaden produkt nie może twierdzić, że robi 100% tego, czego ludzie potrzebują, a na pewno nie w absolutnie najbardziej wydajny (pod względem wydajności operatora), łatwy w użyciu i powszechnie akceptowany „najlepszy” sposób.

Gdyby coś takiego było możliwe, oczywiście jedyną pozostałą rzeczą do konkurowania jest cena. Ale ponieważ obiektywne „najlepsze” i uniwersalnie „najbardziej wydajne” zastosowanie jest niemożliwe, zawsze będzie więcej rzeczy niż tylko cena do konkurowania.

W tym artykule jest kilka dobrych argumentów, ale z drugiej strony rzeczywisty świat wydaje się mieć wiele przykładów, w których firmy bliskiego źródła radzą sobie dobrze. Oto tylko kilka

1. Linux vs. Windows
2. PHP vs. ASP.NET
3. [coś takiego] vs. Visual Studio
4. GIMP vs. Photoshop (odpowiedź była przede mną, ale naprawdę potrzebowałem innego przykładu niż MS :))
5. vBulletin vs. ponad 30 innych pakietów tablic ogłoszeń

Problem z open source polega na tym, że jest otwarty. Jeśli masz ten kod, produkuje produkt A. Cała Twoja konkurencja ma ten sam kod. Więc spędzasz cały ten czas na pisaniu oprogramowania, pod warunkiem, że część tego może zrobić inni współtwórcy, ale jeśli prowadzisz firmę, zużywasz zasoby, a jednak każdy może przyjść i zacząć sprzedawać dokładnie to samo, co spędziłeś lata rozwijanie się. Tak więc największym zagrożeniem dla firmy typu open source może nie być firma typu open source, ale pozostałe 5 firm typu open source.

Z drugiej strony, jeśli opracuję oprogramowanie z zamkniętym kodem źródłowym, tak, możesz skopiować moje pomysły, ale wciąż mogę być o wiele lat przed tobą w tworzeniu oprogramowania, a zanim wejdziesz na rynek, będę mógł już posiadać 90% tego oprogramowania.

Wreszcie, ogólnie rzecz biorąc, firmy, które nie współużytkują kodu, ale pobierają opłaty za swoje oprogramowanie, generują większe przychody niż projekty typu open source. Jak tylko ten przychód zostanie wygenerowany, jego część zostanie ponownie zainwestowana nie w inżynierię (co można argumentować za darmo, jeśli masz wielu współpracowników typu open source), ale w marketing i promocję produktu, a teraz mówisz o milionach dolarów za który nie ma czegoś takiego jak bezpłatna siła robocza.

Pod koniec dnia jest to wzór na Twój sukces: [innowacja inżynierska] x [marketing] = zysk. Możesz mieć najlepszy produkt, ale jeśli nikt o nim nie wie, nikt go nie używa. I oczywiście, jeśli zbudujesz coś kiepskiego, żadna ilość reklam go nie uratuje. Uważam, że wiele projektów typu open source zawsze miało problemy z [marketingiem], jeśli chodzi o penetrację ogólnych rynków konsumenckich.

Jednym z obszarów, w którym większość oprogramowania typu open source nie może konkurować z oprogramowaniem zastrzeżonym, jest krzywa uczenia się.

Historycznie miałem trudności z włączeniem do mojego zestawu narzędzi wszystkich oprócz kilku najpopularniejszych programów typu open source. Zazwyczaj są świetne, kiedy je rozgryzam, ale zazwyczaj nie odczuwam początkowej frustracji związanej z zastrzeżonym oprogramowaniem.

Nie jestem pewien, dlaczego tak jest. Mogę jednak powiedzieć, że jestem więcej niż skłonny zapłacić za oprogramowanie, które wykonuje zadanie przy minimalnym wysiłku z mojej strony. W końcu taki jest cel oprogramowania .

Ułatw implementację niż konkurencja typu open source, a ludzie zapłacą.

Użyteczność i funkcje - jedyną rzeczą, którą ma komercyjny projekt o zamkniętym źródle, czego nie ma w większości projektów open source, jest umiejętność kontrolowania silnej wizji tego, co produkt powinien i powinien robić.

Wszystko zależy od wielkości / złożoności, ale mniejszy produkt z jednym zespołem będzie mógł skoncentrować się na rynku, do którego starają się dotrzeć. (Ten drugi przykład - w jaki sposób BBEdit i TextMate są w stanie odwołać się do grupy osób gotowych zapłacić za edytor tekstu, biorąc pod uwagę dostępność jEdit, gEdit itp. Co oferuje TextMate na tyle atrakcyjnie, aby zachęcić ludzi do zarobienia ponad 20 USD - 30 USD?)

Koncentrując się na konkretnych problemach klienta. Wiele razy widziałem, jak organizacje wydają tysiące dolarów na „tę jedną funkcję”.

Jako produkt o otwartym kodzie źródłowym muszą skupiać się na masach (niestety mas nie kupują oprogramowania 10K +), jako zamkniętego źródła dla organizacji zysków, jeśli możesz zaspokoić potrzeby swoich kluczowych / kluczowych klientów, pójdzie więcej biznesu.

Jak już wspomniano w @SnOrfus, obsługa i wsparcie mają kluczowe znaczenie. Widziałem zilliony razy, organizacje preferujące zamknięty kod źródłowy zamiast otwartego kodu źródłowego (a nawet płacące dodatkowo), aby zyskać komfort bycia w stanie zdobyć tylko jedną skrzynkę!

(może to być nieco ukierunkowane na klienta korporacyjnego)

Rozwiązanie komercyjne może słusznie twierdzić, że jego fortuna jest zgodna z sukcesem klienta. Na tym polega pozycjonowanie produktu. Z pewnymi wyjątkami, ogólnie rzecz biorąc, narzędzia open source są ogólnie postrzegane jako raj dla hakerów, a nie rozwiązanie ukierunkowane na klienta.

Jeśli Twój klient potrzebuje jakiejś funkcji, masz siłę finansową, aby dostarczyć ją na czas. Masz możliwość zapewnienia wsparcia 24x7 (i opłaty za to), gwarantowanego rozwiązania problemów krytycznych na poziomie 0, dostępu do technologii nowej generacji znacznie wcześniej niż społeczność open source, jeśli współpracujesz z producentami OEM.

Wykorzystaj je na swoją korzyść. Niech darmowy produkt też będzie na rynku, nie bądź wrogi. Jeśli to w ogóle, rozszerza to rynek - w pewnym momencie użytkownicy darmowego produktu mogą spróbować dzwonków i gwizdków twojego komercyjnego rozwiązania.

Dla uproszczenia ograniczmy czynniki sukcesu oprogramowania do trzech „inwestycji”:

(W tym przypadku „inwestycja” jest zbiorowym terminem określającym działania, za które należy teraz zapłacić, aby uzyskać później przychody).

• sprzedaż i marketing
• opracowanie (obejmuje kod źródłowy, projekt produktu / interfejsu użytkownika, dokumentację i materiały szkoleniowe. Ilość pomnożona przez jakość. Każdy wyprodukowany tutaj produkt roboczy może być replikowany przy niskich kosztach do nieograniczonej liczby użytkowników)
• usługi (wiedza specjalistyczna w zakresie oprogramowania i domeny oraz możliwość dostarczania ulepszeń o wartości dodanej dla poszczególnych klientów)

KPI dla rozwoju jest prosty: czy możesz opracować to samo lepiej i taniej niż inne. Część z nich to zwykła inwestycja w zasoby, a druga to mądrość architekta i projektantów.

W przypadku usług dostęp do kodu źródłowego produktu jest dużą zaletą. Firma, która nie ma dostępu do kodu źródłowego, często nie może zapewnić takiego samego poziomu usług, jak inna firma, która ma dostęp.

Wróćmy teraz do pytania PO: czy firma z zamkniętym źródłem ma strategię przetrwania?

Artykuł cytowany przez OP wydaje się samoograniczający, ponieważ rozważa tylko dwie skrajności:

• Firma z zamkniętym kodem źródłowym opracowuje cały kod źródłowy z własnej kieszeni i ma zero linii kodu otwartego.
• Firma typu open source w pełni przestrzega tej zasady i otwiera każdą linię kodu, jaką kiedykolwiek opracowano.

Co powiesz na środkowy teren?

• Kilka firm programowych podpisuje umowy licencyjne dotyczące udostępniania części kodu źródłowego i / lub interfejsu API? (W której jedna ze stron jest zorientowana na usługi).
• Firmy, które dobrze wykorzystują licencjonowane komponenty lub biblioteki typu open source BSD (i wnoszą wkłady rzeczowe), bez otwierania kodu źródłowego głównego produktu?
• Firmy, które dostarczają kod źródłowy oprogramowania w toku poprzez ograniczony czasowo „podgląd społeczności”?
• „Dostępne źródło”: firmy, które dostarczają kod źródłowy płacącym klientom?

Moim zdaniem firmy mogą przetrwać, jeśli przyjmą częściowo otwartą, częściowo zamkniętą strategię kodu źródłowego i jeśli dobrze sobie radzą na wszystkich trzech frontach (marketing, rozwój i usługi). Firmy, które przyjmą zasadę otwartej filozofii, również mogą przetrwać i będą musiały dobrze sobie radzić na tych samych trzech frontach.

Jest jednak jedno zastrzeżenie: jeśli oprogramowanie jest bezpłatne, czy klienci wybiorą go zamiast alternatywnych, nawet jeśli oprogramowanie źle radziło sobie z niektórymi parametrami?

• sprzedaż i marketing: czy możesz promować produkt niemal bez żadnych kosztów poprzez marketing wirusowy?
• rozwój: czy projekt open source może uzyskać większość swojego projektu / opracowania / dokumentacji od nieopłaconych wolontariuszy? Czy firma może czerpać korzyści z takiego projektu?
• usługi: czy projekt oprogramowania może zrewolucjonizować domenę oprogramowania, aby uczynić go bardzo prostym, aby każdy mógł zostać natychmiastowym ekspertem, obniżając barierę wejścia do zera?

Projekt open source goni projekt komercyjny pod względem funkcji. Pozostawia to rodzaj czasowego arbitrażu dla firmy komercyjnej, aby konkurować pod względem funkcji. Muszą ścigać się, aby stale wdrażać funkcje, aby zachować przewagę nad firmą open source. Jest drogi, ale może działać.

Jak wspomnieli inni, funkcje mogą obejmować dokumentację i łatwość użytkowania.

Korporacja może próbować zaszczepić blokadę dostawcy, ale to tylko spowalnia straty; nie zyskuje żadnych klientów.

Pozostawia to dwa główne sposoby utrzymania udziału w rynku: wsparcie i wykorzystanie nieufności menedżerów do oprogramowania typu open source. Niestety, ta ostatnia zaprowadzi cię dość daleko. Wsparcie sprzedaży będzie jednak działać, a nawet gdy projekt open source dostatecznie się zainteresuje, aby uzyskać wsparcie firmy w zakresie sprzedaży, rozwiązanie komercyjne będzie miało tę przewagę, że jest obecne i ma większe doświadczenie, a także wrażenie, że są bardziej zaznajomieni z ich produktem.

W dłuższej perspektywie prawdopodobnie będziesz wkręcony, ale może to sprawić, że „krótkoterminowo” stanie się „przewidywalną przyszłością”.

Jedna rzecz, o której nikt inny nie wspomniał, to dokumentacja. Wiele programów tak naprawdę nie potrzebuje wiele do użycia (Firefox, Openoffice), ale jeśli napiszesz bibliotekę, jakiś serwer, język programowania lub po prostu bardzo skomplikowany program, dokumentacja może Cię wyróżnić.

Udoskonalenie dokumentacji może zmniejszyć frustrację użytkowników (zwiększając prawdopodobieństwo, że będą nadal korzystać z produktu i sugerują korzystanie z niego w przyszłości), a także możesz reklamować, że pieniądze są dobrze wydawane, ponieważ Twoi klienci nie poświęcają tyle czasu na kodowanie (i czas == pieniądze).

Niekoniecznie jest to jednak open source vs. zamknięte źródło - prawie wszystko jest źle udokumentowane. Możliwe, że twój konkurent bierze udział w 1% projektów, które dobrze dokumentują rzeczy, ale jest mało prawdopodobne;)

Po prostu sztuczka polega na ponownym definiowaniu 100%. FOSS po prostu nie ma takiej samej skali i siły roboczej jak projekt komercyjny, a istnieją ograniczenia dotyczące tego, jak blisko możesz konkurować z istniejącym produktem. Firma o zamkniętym źródle używa haków interfejsu użytkownika, dzięki czemu korzystanie z konkurencyjnego produktu jest niemożliwe z powodu różnych, na przykład, skrótów klawiaturowych. Ponadto dodają główne funkcje, których konkurent FOSS po prostu nigdy nie wziąłby pod uwagę. Rozważmy na przykład Visual Studio. To było tylko C ++ IDE, ale potem zaczęli pakować zupełnie nowe języki i frameworki, takie jak .NET. Lub Visual Studio 2010, który zawiera komercyjną bibliotekę wątków (jak w Intel sprzedaje równoważną autonomiczną) bibliotekę wątków dla C ++. FOSS po prostu nie nadąża za tego rodzaju rozwojem, a często i niezawodnością.

Kieruj reklamy na tradycyjne rynki przedsiębiorstw i zdobywaj popularność.

W przypadku wielu dużych tradycyjnych firm sprowadza się to do trzech rzeczy:

• dostawca, z którym mogą zawrzeć wiążącą umowę (możliwości i niezawodność)
• dostawca, z którym mogą oni umownie wyegzekwować określoną umowę o gwarantowanym poziomie usług (szybka jakość wsparcia)
• recenzje Gartnera (jest to współczesny odpowiednik „nikt nie zostaje zwolniony za wybranie IBM)

Wszystkie trzy są bezmyślnie przestrzegane i nie są szczególnie ważne. Kwestie zdolności są zawsze wyprzedane, umowy SLA zawsze mają wymówkę, a gartner bada tylko tych ludzi, którzy słuchają gartnera, ale kiedy jesteś średnim kierownictwem w korporacji, która ma całą wyższą i wyższą kadrę kierowniczą, która ma problemy z wyższym kierownictwem kiedy kierownictwo wyższego szczebla w końcu dowiaduje się, że zapadła decyzja, która kosztowała wielki stos pieniędzy, potrzebujesz dokumentacji od strony trzeciej, która popiera twoje stanowisko, jeśli chcesz uratować pracę. Nawet jeśli dobrze wiesz, że z technicznego punktu widzenia spuszczasz duże stosy pieniędzy do toalety, nie warto ryzykować, aby postąpić właściwie.

Ile złych zastosowań SAP lub SharePoint widziałeś w branży? Ilu z nich byłoby lepiej, gdyby wykonano coś innego, co byłoby lepiej dopasowane, ale nie o dużej nazwie branżowej?

Korzystam z wielu narzędzi Microsoft i mam konto MSDN, ale szczerze mówiąc, otrzymuję lepszą pomoc od ludzi MS na Twitterze niż za pośrednictwem centrum telefonicznego MSDN. Nie mogę sobie wyobrazić, że dostanę gorszą pomoc od ludzi stojących za projektem Open Source niż od osób, które nie wspierają tweetowania w wolnym czasie, ale to nie wchodzi w równanie Odpowiedzialność / Gartner.

Jak powiedział SnOrfus, sprzedaj funkcje, które robimy.

Np .: Opracowujemy wtyczki z niektórymi typowymi funkcjami i udostępniamy za darmo do pobrania na stronie Wordpress. Jednocześnie mamy naszą płatną wersję wtyczki, która ma funkcje pro.

Pomaga ci to przedstawić swój produkt masowym ludziom, tj. Siłę otwartego oprogramowania i ludzi.