Jak skutecznie konkurować z projektem open source?

36

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

Richard
źródło
2
Komentatorzy: komentarze mają na celu poszukiwanie wyjaśnień, a nie dłuższą dyskusję. Jeśli masz rozwiązanie, zostaw odpowiedź. Jeśli Twoje rozwiązanie jest już opublikowane, głosuj za nim. Jeśli chcesz omówić to pytanie z innymi, skorzystaj z czatu . Aby uzyskać więcej informacji, zobacz często zadawane pytania .
8
W takiej subiektywnej odpowiedzi niektóre z najlepszych informacji znajdują się w komentarzach.
richard
pozwać użytkowników produktu open source en.wikipedia.org/wiki/SCO/Linux_controversies
Ewan

Odpowiedzi:

42

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

Steven Evers
źródło
2
+1 za „Zmień grę”, jeśli nie możesz pokonać przeciwnika na jego warunkach, musisz po prostu znaleźć warunki, które bardziej Ci odpowiadają.
Matthieu M.
1
Gdy zaczniesz mieć konkurenta typu open source, na który naprawdę warto zwrócić uwagę, dobrym sposobem na wymyślenie strategii biznesowej jest udawanie, że masz zamiar otworzyć również swój projekt. Zmień swój biznes, aby był opłacalny w tych warunkach, a będziesz miał pewność, czy faktycznie go otworzyłeś, czy nie
blueberryfields
Dodałbym: zapytaj „kto prowadzi azyl”? Nie pozwól współwięźniom prowadzić azylu. Jeśli to programiści, więźniowie są.
mattnz
Myślę, że zmiana gry zrobiła to dla mnie. Myślę, że to wszystko, co masz na końcu.
richard
1
Oczywiście musisz nadać priorytet swoim wysiłkom i myślę, że są one zacofane na tej liście. Oprogramowanie typu open source może prawdopodobnie konkurować pod względem funkcji, jakości i skuteczności, a czasem także o integrację z innym oprogramowaniem, ale obsługa, wsparcie i sprzedaż to słabe punkty w otwartym oprogramowaniu i ważne punkty na rynkach Big Co.
Kevin Vermeer
34

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

użytkownik16764
źródło
2
Czyli to zwykła dominacja zasobów?
richard
11
Nie - zasoby niekoniecznie stanowią lepszy produkt.
Stephen C
5
@TheLQ: Aplikacje takie jak Notepad ++, EditPad Pro, a nawet Emacs / Vim pokazują, jak daleko można się posunąć, aby wyróżnić swój „edytor tekstu” na rynku.
Dean Harding
9
Photoshop jest dobrym przykładem trzymania klonów w ryzach po prostu będąc bardzo dobrym produktem.
4
Nie ma czegoś takiego jak wyczerpanie wszystkich możliwych rzeczy, które możesz zrobić.
Kyralessa
33

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.

Denis de Bernardy
źródło
3
„OSS zwykle ma za krótki cykl programowania”, ale jeśli używasz OSS, nie musisz dotrzymywać kroku najnowszemu rozwojowi, masz możliwość korzystania ze starej wersji na czas nieokreślony i aktualizacji tylko wtedy, gdy ma to sens dla Twojej firmy . W przypadku oprogramowania o zamkniętym źródle, w zależności od okresu licencyjnego, jest to czasem trudniejsze. Ponadto, jeśli oprogramowanie typu open source przestanie obsługiwać starą wersję, masz wybór, aby rozwidlić starą wersję i samodzielnie naprawić błędy / problemy z bezpieczeństwem. Przy zamkniętym źródle nie masz takiego wyboru, więc albo uaktualnisz, albo utkniesz z błędem na zawsze.
Lie Ryan,
5
„Nikt nigdy nie został zwolniony za wybór IBM”. A co, jeśli najlepsze w branży oprogramowanie w branży to oprogramowanie typu open source, powiedzmy Apache? a może za kilka lat, jeśli Android ma pokonać Nokię?
Lie Ryan
2
Nie masz dużego wyboru, aby wybierać stare wersje na czas nieokreślony, gdy mają luki w zabezpieczeniach. Spróbuj zainstalować WP 2.3 na serwerze WWW i zobacz, jak to jest, zanim bot go znajdzie i zhakuje. I nie, taśma klejąca (tj. Poprawki bezpieczeństwa dotyczące cofania) nie jest rozsądną opcją dla Joe Average. Dzięki OSS jesteś zmuszony do aktualizacji lub utknąć na zawsze na błędach.
Denis de Bernardy
2
@Denis: Joe Average mógłby teoretycznie zatrudnić programistę Jacka, aby potrzebował poprawek bezpieczeństwa, których potrzebuje; to może nie być najlepsza decyzja biznesowa, ale może (i to jest ważne). Przy zamkniętym źródle, gdy wsparcie przestaje działać, program jest zawieszony na zawsze (można argumentować, że czasem jest to lepsze, ponieważ masz po prostu prosty wybór aktualizacji, więc nie musisz dać szansy atakującemu na wykorzystanie twojego programu podczas gdy ty „zastanawiam się, czy przeprowadzić aktualizację)
Lie Ryan
6
„OSS ma skłonność do pełzania”: Absolutnie nie. Większość programów OSS to małe programy typu „rób wszystko, co trzeba”, chociaż ich widoczność publiczna jest niższa niż w przypadku dużych projektów próbujących naśladować monolitycznego konkurenta komercyjnego.
tdammers
19

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.

Dean Harding
źródło
Dzięki za trochę pęknięcie bańki dla mnie. To ma sens. :-)
richard
8

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.

DXM
źródło
1
Większość edytorów tekstu i VS jest na osobnych rynkach.
alternatywnie
@alternative Większość IDE i VS znajduje się na osobnych rynkach.
Andy,
6

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

elekwent
źródło
różne anegdoty, zwykle mam mniej problemów z nauką oprogramowania open source, ponieważ często mają więcej instrukcji / dokumentacji i więcej forów dyskusyjnych, które można uzyskać z Google. Chociaż nie każde oprogramowanie open source ma doskonałą dokumentację lub fora dyskusyjne na rynku wtórnym, te, które to robią, są zazwyczaj łatwiejsze w obsłudze niż alternatywa dla zamkniętego źródła. Na przykład odkryłem, że Python jest znacznie łatwiejszy do nauczenia się niż Visual Basic .NET. Znalazłem więcej porad i wskazówek na temat poprawiania / naprawiania systemu Linux, niż kiedy korzystałem z systemu Windows.
Lie Ryan,
4

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

Chad Thompson
źródło
Aby odpowiedzieć na twoje pytanie - mnóstwo mac-fanboyowego szumu! Nigdy nie widziałem czegoś, co naprawdę wywarło na mnie wrażenie w tym edytorze.
alternatywnie
3

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)

YetAnotherUser
źródło
1

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.

Fanatyk 23
źródło
1

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?
rwong
źródło
1

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ą”.

dhasenan
źródło
Zgadzam się z Tobą. Naprawdę uważam, że na dłuższą metę nie można zatrzymać otwartego oprogramowania. To tak jak przemysł muzyczny i filmowy ... możesz zatrzymać masy, a to, czego domagają się masy, dostaje masy. W przypadku open source vs zamkniętego źródła, open source (myślę, że na dłuższą metę) zapewni funkcje o lepszej cenie i wsparciu.
richard
1

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

Przywróć Monikę
źródło
1

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

DeadMG
źródło
0

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.

Rachunek
źródło
-2

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.

Angelin Nadar
źródło