November tizedikén írtam egy bevezetést egy gondolatfolyamhoz, ami azt hivatott bemutatni, hogy hogyan is látom a közösségi web speciális szeletét: a közösségi adatbázisok működését, lélektanát; a tagok viselkedésében megmutatkozó és a teljes oldal erővonalait.

Sokat agyaltam és érleltem magamban a témákat, és arra jutottam, hogy az egész gondolatfolyamot problémákra kihegyezve fogom levezetni. A kérdéskörökben megpróbálok állást foglalni, ami talán többeket gondolkodásra késztet, segíthet abban, hogy hogyan működtessék saját közösségeiket. Na de, kezdjünk bele az első témába.

Hogyan érhetjük el, hogy tagjaink folyamatos aktivitást mutassanak fel. Mit kell tennie az üzemeltetőnek, hogy ez hosszú távon fenntartható legyen?

A legfontosabb az, hogy nem kell erőltetni semmit. Fontos, hogy mindenki jól érezze magát a közösségben, de egy-egy személy akarata alapján nem módosítható a szájt koncepció-rendszere. Mindenkit meg kell hallgatni, biztosítani kell a fórumot a beszélgetésre és véleményezésre - de végső soron az üzemeltető dönti el, hogy mi történik a lapon.

Ez nem azt jelenti, hogy az eredeti felállás bármikor megváltoztatható. A tagok rühellik a nagy váltásokat. A folyamatos, apró módosításokban megnyilvánuló, akár dizájn-beli, akár funkcionális átalakulás sokkal elfogadottabb, és mindeközben a tagok tesztelőként viselkedve segítenek abban, hogy sikeres legyen az alakulás.

Az üzemeltető emellett csapdába eshet, ha az eredeti koncepció kidolgozatlansága, vagy a hiányzó üzleti modell miatt egy felfuttatott, hangulatos és népszerű pillanatában kezdi olyan formán alakítani a rendszert, hogy abból bevétele származzon.
Sok példát láthatunk balul elsült átalakításokra, amelyek mögött anyagi haszonszerzés állt. Holott ez a motiváció egyáltalán nem elítélendő, hiszen az üzemeltető valamiből fenn kell, hogy tartsa a vasat - de mégis sokan esnek át a ló túloldalára. A közösség pedig rettentő érzékeny, és bosszúálló. Egy-két véleményvezér is könnyen felnyitja a szemét, ami után gyakorlatilag menthetetlenül elfajulhatnak a dolgok és tömeges elpártolás zajlik le. Ez persze lehet megfelelő időpont a nagyszerű megújulásra, de ez talán még nehezebb feladat. Így születnek a század szellem-szájtjai: 5-10 éven belül szerintem már tucatjával botlunk majd ilyen lapokba.

Persze a közösséggel való együttműködést sem lehet minden határon túl, ész nélkül művelni. Soha nem lesz tökéletesen közös álláspont, így egy-egy kisebb csoport véleményére adva meglépni gyökeres átalakításokat a fentiekhez hasonló elpártolást eredményezhet. Erős, lehetőleg előre végiggondolt, hosszútávú koncepcióval érdemes nekilátni egy közösségi szájtnak. Persze minden változik, és alakul eközben, de szükség van a határozott alapok lefektetésére. Fontos eldönteni az elején, hogy pénzt akarunk keresni, vagy társadalmi jóság a cél. Előbbinél kidolgozott üzleti modellel vágjunk bele, utóbbinál pedig fogadjuk el a jóság minden nehézsgét, szenvedését és értsük meg, hogy a felhalmozott tapasztalat hozhat hasznot számunkra, az adott nonprofit szájt közvetlenül nem. Ez utóbbi elfogadás garantálja a nonprofit közösségi adatbázisok hosszútávú, sikeres és minőségi anyagot eredményező működését.

Óriási megkönnyebbüléssel és enyhe kudarcérzéssel jelentem be kitartó olvasóimnak, hogy a Statuemap.com újraírását Ruby on Rails keretendszer helyett PHP alatt folytatom (kezdem újra). Ennek egyszerű és prózai oka az, hogy jelen életembe egyszerűen sehogy sem fér bele az, hogy megismerkedjek eme nagyszerű környezettel. Este nyolctól egyig egyszerűen nem lehet világot váltani úgy, hogy közben nem ismered 100 százalékosan az adott környezetet.

A tökéletes csaj

Kicsit úgy éreztem magam, mintha meg próbálnám szerezni a nagyon tökéletes csajt, mert azzal végigmenni az utcán igazi büszkeség. Mert, valljuk be, ma RoR programozónak lenni menő, sőt mi több igazán hekker dolog. Nekem most ez mégsem fér bele, egyszerűen azért, mert az alábbi rendszert nem merem elindítani ingoványos talajra építkezve:

• ~12 ezer szobor ~70 ezer fotója induláskor (szoborlap.hu migráció)
• user kezelés, követés, kommentelés
• amazon s3 cloud használata a képek tárolására
• számtalan időzített feladat
  
• mail küldés (hírlevelek, user események, stb.)
• google maps erős bedrótozása
• ajax, jquery aktív használata
• fb, twitter, flickr apizás
  

Ha most lennék 16

Mindezekben persze elvileg nagyon király a Rails keret, mert ami PHP alatt 100 sor, az itt 3. Rengeteg függvény előre meg van írva, gyönyörűen. És itt is van a legnagyobb probléma számomra. Az előre megírt (GEM-eknek nevezett) összetevők zárt dobozok, én csak installálom őket. Megpróbálom betuszkolni mindet a logikámba, és egymáshoz is kell passzolniuk. Mindeközben Linux-guruvá is válsz egy picit, mert egy kész szerveren normálisan elképzelhetetlen a dolog (megfizethető áron). A külföldi szolgáltatóknál pedig azonnal jelentkezik az olcsóság ára, ezt persze a cloud-terjedés számlájára kell írnom. Egy pici plussz fícsör, +20USD, nem elég az email kvóta, +50; kicsi a forgalom-keret? +30, esetleg kevés a memória? +50; beszakadt minden és valós segítség kell? +25/óra... stb. Azt még nem is mondtam, hogy a hazai virtuális hosztomon 1mp alatt 2 emailt enged át az SMTP, míg slicehost.com-os szeletemen egy emailnek kell 27mp - vagyis rá vagy kényszerítve valamilyen email plugin igénybevételére. Ami ettől még nem biztos, hogy whitelist-es.

Opensource business modell

Sajnos ez az egész szellemiség nem passzol össze sehogysem az én kis szerelem-startupommal. Ebből kifolyólag tegnap este egy hirtelen döntés által vezérelve letöltöttem a legfrissebb CakePHP verziót, újraindítottam a projektet és 3 óra után kb. ugyanott tartottam, mint amennyit az első 3 hétben csináltam meg Rails alatt. A CakePHP keretrendszer sokak szerint a RoR koppintása. Az tény, hogy első ránézésre is látszik egy-két komoly hasonlóság a szerkezetben, logikában és elnevezésekben, de amellett, hogy mindig minden sok más dologból tud csak születni, nem a semmiből, azért valljuk be azt is, hogy az objektumorientáltság nem a Railsben született; az MVC logika már korábban is adott volt. A RoR ennek egyszerű kommunikálásában és "eladásában" jó, opensource/közösségi keretek között. De miért van mégis egy olyan érzésem, hogy a RoR mégiscsak a dollárok felé lejt, míg PHP alatt valóban szabadnak, platform- és szerverfüggetlennek érzem magam?

Természetesen nem adom fel végérvényesen. van egy olyan mondás, hogy amíg gyökeresen nem változik a helyzetem munka/szabadidő/tanulmányok relációban, addig nem kezdek komolyabb RoR projektbe. Ha pedig igen, akkor viszont tudom is, hogy mi a következő terület, amit ezzel a csúcsfegyverrel fogok meghódítani! ;]