Dlaczego nie ma kultury płacenia za ramy? [Zamknięte]

Jednym z efektów ubocznych ostatniego trendu startupów „Lean” i ery App Store jest to, że konsumenci są bardziej przyzwyczajeni do płacenia niskich cen za małe gry / produkty.

Na przykład.:

• SAAS online, który pobiera opłatę w wysokości ~ 5 USD / miesiąc (styl produktu Basecamp)
• Gry, które są krótkie, zabawne i tanie (0,99 USD w App Store)

Rynek ten został zdefiniowany przez „robienie jednej rzeczy dobrze i naliczanie za to ludzi”. Sława DHH of Rails / 37 Signals dowodzi, że jeśli twoja strona nie zamierza zarabiać pieniędzy, nie zawracaj sobie tym głowy.

Dlaczego ta sama zasada nie dotyczy ram?

Istnieje wiele projektów oprogramowania ramowego - wiele z nich jest dojrzałych i bogatych w funkcje, które oferują programistom znaczną wartość, ale wydaje się, że nie ma rynku ani kultury płacenia za nie.

Wygląda na to, że projekty, które pobierają pieniądze, często są zestawami narzędzi interfejsu użytkownika i często są marginalizowane na rzecz darmowych alternatyw.

Dlaczego to?

Z pewnością programiści / firmy widzą wartość, jaką wnoszą w projekty takie jak Ruby, Rails, Hibernacja, Spring, Ant, Groovy, Gradle (lista jest długa).

Nie sugeruję, że te frameworki powinny zacząć pobierać opłaty za każdego, kto chce z nich korzystać, ale musi istnieć sensowny model biznesowy, który pozwoliłby deweloperom zarabiać pieniądze od momentu zainwestowania w opracowanie frameworka.

Czy są jakieś przemyślenia, dlaczego ten model nie pojawił się / nie odniósł sukcesu?

Edycja Aby być jasnym: nie jest to post na temat lekceważenia znaczenia wolnego oprogramowania typu open source. To jest post o pytaniu, dlaczego nie istnieje kultura płacenia za frameworki.

Istnieje absolutna etyka handlu wartością w wartości w oprogramowaniu wolnym / otwartym.

W większości gospodarek handlujemy pieniędzmi za produkt lub pieniędzmi za usługę. Jest to bardzo wygodne. Rzeczywiście, robimy to w części ekonomicznej oprogramowania komercyjnego.

Ale generalnie nie handlujemy pieniędzmi za przyjaźń lub pieniądze na romans. Wymieniamy przyjaźń za przyjaźń i romans za romans.

Podobnie w wolnym / otwartym oprogramowaniu etyka polega na spłacaniu DHH i współpracowników Railsów poprzez: zgłaszanie błędów, dodawanie poprawek, pisanie / aktualizowanie / naprawianie dokumentacji oraz ewangelizację Ruby, Rails, Linux i wszystkich innych ogólnie projektów wolnego / otwartego oprogramowania. W ten sposób handlujemy wartością za wartością.

Pytanie, dlaczego „ten model [pobieranie opłat za frameworki] nie pojawił się / nie odniósł sukcesu” jest podobne do pytania, dlaczego ten sam model nie pojawił się / nie odniósł sukcesu, jeśli chodzi o przyjaźnie lub romans. Ktoś, kto oferuje przyjaźń, nie chce pieniędzy - chce przyjaźni w zamian. Podobnie romans. Podobnie w wielu przypadkach oprogramowanie.

Myślę, że na to pytanie można odpowiedzieć w odpowiedzi na to pytanie. Dlaczego programiści piszą aplikacje o zamkniętym źródle, a następnie je uwalniają? .

Dodałbym do tego:

Uważam, że poprzez uwolnienie frameworka, pozwalamy początkującym i programistom hobbystycznym na zainteresowanie poważnym programowaniem. Ułatwia im to drogę. Widzieliśmy już, że platformy, które nie są darmowe, są często mniej przystosowane niż te, które są. Co więcej, darmowe frameworki są zwykle opracowywane przez grupę ludzi, którzy chcieli przyczynić się do społeczności.

Zawsze wydaje się, że sprowadza się do jednej z dwóch różnych kultur. Istnieje grupa „Płacę za oprogramowanie za pieniądze” i grupa „Płacę za oprogramowanie z czasem”.

Rozważ IT w organizacji. Powiedzmy, że firma chce monitorować sieć. To albo A) Misja krytyczna i warta wpompowania ton pieniędzy w (Openview, Netcool). Lub B) Ciasny budżet, rób, co możesz, mniej (Nagios, MRTG).

Podobnie są ludzie, którzy „dorastali” dzięki podejściu do oprogramowania w Microsoft / Apple. Płacisz pieniądze i rzeczy powinny działać. Chcesz nowej funkcjonalności, za nią płacisz. Z drugiej strony są ludzie, którzy przyzwyczaili się płacić swoim czasem. Unix, Open source, java itp. Jeśli chcesz mieć więcej funkcji, napisz ją samodzielnie lub umożliwisz komuś naprawienie.

Rozważ sklep z aplikacjami Apple w Android Market. Kupujesz Angry Birds na iPhone'a, ale dostajesz go za darmo (z reklamami) na Androida. Różne kultury w pracy. Angry Birds odniosło ogromny sukces w sklepie z aplikacjami, który pobiera marne 0,99 centa, ale wiedzieli, że miałby bardzo mały udział w rynku, gdyby pobierał nawet 0,25 cala w Android Market.

Myślę, że ramy zaczęły się w tym drugim obozie, i tak już jest. Nie możesz sprzedawać frameworka jako produktu gotowego dla babci, ktoś musi zainwestować czas w uczynienie go materiałem eksploatacyjnym. Ludzie przyzwyczajeni do poświęcania czasu nie są przyzwyczajeni do płacenia zarówno czasem, jak i pieniędzmi.

Z pewnością programiści / firmy widzą wartość, jaką wnoszą w projekty takie jak Ruby, Rails, Hibernacja, Spring, Ant, Groovy, Gradle (lista jest długa).

Z mojego doświadczenia z klientami i pracodawcami zauważyłem kilka powodów, dla których firmy, które intensywnie korzystają z oprogramowania Open Source (i zarabiają lub oszczędzają dużo pieniędzy, korzystając z niego), nie zwracają tyle, ile mogą:

• Brak zrozumienia, w jaki sposób działa model Open Source, a tym samym brak świadomości potrzeby darowizn, aby projekty były silne

• Często brak jasności co do tego, co stanie się z datkiem

• Kwestie podatkowe, niepewność co do odliczeń

• Trudności dla osób technicznych uzasadniających darowizny (lub inne środki zwrotu, takie jak organizowanie wydarzeń itp.) Przed nieoświeconym zarządzaniem / kontrolowaniem („Jeśli nie musimy za to płacić, dlaczego powinniśmy im dawać pieniądze? „Nie mamy na to budżetu. Może w przyszłym roku”)

Wydaje mi się, że każdą z tych kwestii można w pewnym stopniu rozwiązać w dowolnym projekcie Open Source, ale w większości przypadków nie jest to robione z powodu braku wiedzy specjalistycznej w zakresie wyraźniejszej komunikacji oraz pewnej niechęci do proszenia firm o darowizny w bardziej zaawansowany sposób. droga.

Uwielbiam ducha społeczności Open Source: „bez pieniędzy, bez biurokracji, bez zobowiązań”, ale czasami myślę - co jeśli każda firma, która używa, powiedzmy, OpenOffice zamiast 200 USD licencji na biuro MS Office przekazałaby tylko 2 USD na rzecz OOo lub jakiś inny projekt Open Source?

Głównym ryzykiem związanym z korzystaniem z oprogramowania typu open source jest brak oficjalnego wsparcia. Zasadniczo jesteś właścicielem kodu. Chociaż na początku wydaje się bardziej opłacalne korzystanie z „darmowego” oprogramowania, należy wziąć pod uwagę możliwość, że koszty utrzymania w domu mogą ostatecznie przewyższyć koszt własnego rozwiązania. Niektóre organizacje nie chcą podejmować tego ryzyka.

Część pytania wydaje się porównywać ramy z płaceniem za aplikacje (np. Fajne gry, 37 produktów sygnałowych, SAAS online), ale są to jabłka i pomarańcze. Konsumenci kupują aplikacje, podczas gdy programiści używają platform do tworzenia aplikacji dla konsumentów. I oczywiście programista może być konsumentem, jeśli jest użytkownikiem i kupuje aplikacje, gdy nie rozwijają się w ramach.

Frameworki nic nie robią po wyjęciu z pudełka, dopóki nie zostaną przekształcone w aplikacje, które można sprzedać.

Jeśli jednak po prostu porównujemy narzędzia programistyczne, takie jak frameworki vs zestawy komponentów vs pakiety RAD itp., Myślę, że należy przeprowadzić dobrą dyskusję na temat tego, za jakie rodzaje rzeczy są płacone, a nie.

Wyobraźmy sobie, że tworzę framework o nazwie „AwesomeWork” (oryginalny huh?). Teraz ludzie nigdy go nie używali i nie są pewni, czy to im pomoże, i nie chcieliby płacić pieniędzy za coś, co może im nie przynieść korzyści (nawet jeśli im się to podoba!), Więc wypuszczam to za darmo. Czy jestem głupcem z powodu utraty potencjalnych zysków, ponieważ być może udało mi się sprzedać za 5 USD za licencję? Nie, ponieważ kiedy wypowiadam słowo i ludzie zaczynają korzystać z mojego frameworka, otworzył się drugi rynek: książki. Mogę teraz napisać książkę o AwesomeWork (nazwijmy ją „Do [Awesome] Work Son!”, Przepraszam, że musiałem to zrobić). Więc sprzedaż książki jest stabilna, teraz postanawiam wprowadzić kilka aktualizacji AwesomeWork i wydać ją pod AwesomeWork 2.0 i oto mogę sprzedać „Do [Awesome] Work Son!

Nie twierdzę, że powyższy scenariusz jest głównym powodem, dla którego ktoś wydałby swój framework za darmo, ale pokazuje, że wciąż może zarobić na tym.

Uwaga dodatkowa: Istnieje kilka frameworków, które pobierają opłaty (chociaż mogą oferować wydanie społeczności za darmo, ale z ograniczonymi funkcjami). Przychodzi mi na myśl WebSharper , który pozwala w pełni pisać strony internetowe w języku F #.