piątek, 19 sierpnia 2011

Czy frameworki Java mają długi ogon (long tail)? Okazuje się, że tak.

+++++++
Do Java Frameworks have a Long Tail? 

Yes, java frameworks also behave according to the long tail model introduced by Chris Anderson in 2004. Query at google.com for "java frameworks" gives about 10.6 billion results. Most of the entries on the first page of search results is trying to answer the questions which one is the "hottest" or how to compare them. Indeed, in recent years the amount of platforms built in order to support developers in creating applications based on Java increased rapidly (interesting that a large proportion of them are web frameworks), and developers are investing more time in the analysis of frameworks, than building their own.
 
This post describes main drivers behind the long tail model and their implications for promoting new frameworks. Please contact the author for full English version, if required.

+++++++


Zapytanie w google.com o "java frameworks" daje 10,6 miliona rezultatów, z czego na pierwszej stronie wyników wyszukiwania większość wpisów próbuje odpowiedzieć na pytania, który z nich jest "hottest" ("which is the hottest java web framework") lub w jaki sposób je porównać ("comparing java frameworks"). Istotnie w ciągu ostatnich lat ilość platform wspierających programistów w tworzeniu aplikacji opartych o język Java gwałtownie wzrosła (interesujące, że duża część z nich to frameworki webowe), a programiści inwestują więcej czasu w analizę gotowych klocków, niż w budowanie własnych. 

Co się zmieniło?

W październiku 2004 Chris Anderson w magazynie "Wired" użył określenia "długi ogon" (long tail) nazywając w ten sposób model sprzedaży, w którym duża część obrotu pochodzi od szerokiej gamy produktów, których jednostkowa sprzedaż jest bardzo niska (Anderson rozwinął tą koncepcję w swojej książce "The Long Tail"* oraz na blogu http://www.longtail.com/). Przykładowo, obok popularnych pozycji (hitów, które sprzedają się w milionach egzemplarzy) amazon.com sprzedaje wiele książek, które kupowane są zaledwie parę razy w miesiącu, ale ponieważ książek tych posiada w asortymencie bardzo wiele, to sumarycznie generują one znaczny obrót.


Rys. Dystrybucja sprzedaży w modelu long tail. 
Oś Y to sprzedaż produktów (sztuki), a X to produkty posortowane wg. sprzedaży. 
Długim ogonem nazywana jest część źółta wykresu.
Źródło: Wikipedia

Podobny trend obecny jest właśnie wśród frameworków Javy (choć w wielu przypadkach nie mówimy o tu sprzedaży). Na rynku mamy dobrze znanych graczy takich jak JSF, Struts, Grails, GWT, czy Spring (hity o bardzo dużej popularności), oraz bardzo wiele mniej znanych platform mniej znanych twórców lub grup projektowych, które są dostępne w Internecie i dzięki elastycznym licencjom mogą być szeroko stosowane. Często takie platformy powstają na potrzeby konkretnych, komercyjnych projektów w ramach jednej firmy, a z czasem udostępniane są szerzej np. jako open-source**).

Jak działa "long tail"?

Anderson identyfikuje trzy główne elementy budujące "długi ogon":
  • upowszechnienie środków produkcji („democratization the tools of production”) - powszechnie dostępne i często darmowe narzędzia umożliwiają łatwe realizowanie własnych pomysłów i tworzenie produktów (frameworków) w domach, a nie tylko w ramach kosztownych projektów w korporacjach,
  • upowszechnienie środków dystrybucji („democratization the tools of distribution”) - Internet stał sie idealnym (i bardzo tanim) miejscem, w którym można udostepnić efekt swojej pracy, poprosić o komentarz, czy sprzedać produkt bez kosztów związanych z nagraniem nośnika, wydrukiem instrukcji, opłaceniem miejsca na półce sklepowej, obsługą klienta jakie musiałby ponieść sklep "w realu";
  • środki łączenia podaży z popytem („connecting supply and demand”) - skoro wszyscy mogą napisać kod i go udostępnić, to niestety wiele z tych produkcji nie będzie dobrej jakości, dlatego potrzebny jest mechanizm "promowania" rozwiązań dobrych. Wiemy o tym, dlatego, jako konsumenci szukamy dobrych produktów oglądając opinie i oceny innych. Takie mechanizmy "promowania" istnieją pod postacią portali, na których można wyrazić swoją opinię (rekomendację) na temat konkretnego produktu. Na amazon.com możemy również zobaczyć co kupili inni na listach bestsellerów oraz otrzymując informacje o tym jakie inne książki kupili dodatkowo klienci, którzy zakupili produkt, który aktualnie oglądamy. Wszystkie te mechanizmy rekomendują nam zakup bazując na zachowaniach innych klientów. 

Co z tego wynika dla twórców frameworków chcący je spopularyzować?

Jeżeli ktoś napisał już solidny framework, to zasadniczo skorzystał już z "upowszechnionych środków produkcji". Pozostaje zatem go udostępnić i zadbać o to by został dostrzeżony (połączyć podaż z popytem). 

Aby nasz produkt został dostrzeżony i dobrze zaopiniowany, musi być jednak solidny. Pamiętajmy, że będzie oceniał nas bezlitosny rynek. Solidność frameworku oznacza nie tylko jego stabilność ale również oraz to, czy dobrze rozwiązuje on konkretne problemy, z którymi borykali się programiści, czy wspiera aktualnie uznane trendy w projektowaniu i technologii (np. REST, czy AJAX w przypadku aplikacji webowych), czy współpracuje (jest kompatybilny) z innymi rozwiązaniami na rynku. Tylko takie frameworki "obronią się" przy weryfikacji przez innych użytkowników i będą rekomendowane. Czy jednak wystarczy udostępnienie solidnego produktu? Niestety, nie.

Frameworki oceniane są również na podstawie ilości ich pobrań (downloads) lub indeksu Google Trends (zobacz przykład), aktywności na listach mailingowych im poświęconych, ilości release'ów w roku, wsparcia narzędziowego, ale również ilości ofert pracy wymagających ich znajomości, czy ilości dostępnych książek na ich temat na amazon.com***). Osiągnięcie dobych wyników w tych obsarach sprowadza się do otwarcia naszego produktu na innych deweloperów ("crowdsourcing"). Oddając nasz framework w ręce innych do użytkowania oraz współtworzenia zwiększamy jego popularność. Właśnie tutaj pomocnymi mogą okazać się rozproszone repozytoria takie jak github.com (darmowe dla projektów open-source), czy sourceforge.com.

Rynek IT jest bardzo dynamiczny i nawet jeżeli nasz framework osiągnie zwrotna popularność, nasza misja się nie kończy. Trendy się zmieniają, a rozwiązania starzeją bardzo szybko i w naszych rękach leży to, czy za parę lat nasz produkt dalej będzie adresował potrzeby innych deweloperów i czy na szczycie nie zastapi go inny.

+++++++

*) Anderson, Chris (2008), “The Long Tail” rev. and updated, Hyperion, New York, USA, 2008

**) mechanizm udostepniania projektów komercyjnych jako open-source i budowania wokół nich społeczności szeroko omówił w swoim wykładzie na konferencji GeeCon 2011 Martijn Verburg (http://www.slideshare.net/martijnverburg/how-to-open-source-a-project-mega-corp).

***) warto zwrócić uwagę na to, jakie atrybuty frameworków porównuje Matt Raible w swojej prezentacji (http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks-ApacheConUS2007.pdf lub z konferencji Devvox 2010 http://www.javablog.eu/java/idealny-framework-webowy/) pomijając fakt, że sugeruje on, że najlepszym frameworkiem jest ten, który jest dobrze znany przez zespół programistów, którzy mają go uzyć ;-)

3 komentarze:

  1. Piszesz, tak: "Oddając nasz framework w ręce innych do użytkowania oraz współtworzenia zwiększamy jego popularność."
    Według mnie jest to tylko szansa na zyskanie popularności. Może się przecież okazać, że upublicznienie wpłynie na produkt negatywnie.
    Warto przyjrzeć się tematowi biorąc pod uwagę branże, dla których frameworki (lub szerzej: rozwiązania) są używane. Branże takie jak sektor publiczy czy telekomunikacja o wiele częściej korzystają z kategorii hottest chcąc być dobrze odbierane przez masy. Inaczej sprawa wygląda w branżach stricte produkcyjnych gdzie oprogramowanie przede wszystkim wspiera procesy związane bezpośrednio z przemysłem. Tu hottest traktowane jest z większym dystansem.

    OdpowiedzUsuń
  2. Nie mam wątpliwości, że framework musi pierwotnie być dobry (solidny), by zyskać akceptacje szerszego grona.

    Jednak frameworki to "platformy" (piszę o tym więcej pod http://pograniczeit.blogspot.com/2011/10/jesli-nie-jestes-tak-pomysowy-jak-steve.html), więc czuja się najlepiej w grupie (community), gdzie korzystają z kreatywności innych uzytkowników. Dzięki temu zyskują popularność (również wtedy gdy coś nie działa, bo ktoś to zgłosi, opublikuje workaround, a może nawet poprawi).

    Co do analizy branżowej, to mam pytanie. Piszesz: "Branże takie jak sektor publiczy czy telekomunikacja o wiele częściej korzystają z kategorii hottest chcąc być dobrze odbierane przez masy.". Czy "masy" to twórcy oprogramowania, czy klienci końcowi tych branż? Pytam, bo nie sądzę, by klienci np. T-Mobile doceniali zastosowania konkretnego frameworku. Prędzej już deweloperzy, ale oni patrzą w kontekście atrakcyjnego miejsca pracy, a tu wszystkie firmy (nawet banki ;-)) chcą być atrakcyjni.

    OdpowiedzUsuń
  3. Pisząc "masy" mam na myśli użytkowników końcowych. Przyjąłe, że frameworki "hottest" poza ułatwianiem pracy programistom pozwalają na budowanie aplikacji atrakcyjnych z punktu widzenia użytkownika.

    OdpowiedzUsuń