Ezzel a kérdéssel indít egy IT World cikk, és aztán jönnek a válaszra esélyes megoldások: Facebook, Twitter, Google Wave (a koncepció, mármint), satöbbi, satöbbi.
A kérdésfeltevés helytelen, az email jelenlegi formájában nem tud kimúlni, és azt is megmondom miért: azért, mert a technológiát még egy olyan világban dolgozták ki, ahol a profit másodlagos volt a felhasználhatóság, pontosabban az interoperabilitás mögött. Magyarul: az email egy olyan nyílt szabvány, amit az implementál, aki akar. A cikkben felmerülő lehetséges válaszok pontosan arra világítanak rá, hogy ma nincs ilyen, ma szolgáltatók vannak, üzleti érdekekkel, akik több vagy kevesebb elszántsággal (és sikerrel) walled garden-t építenek. Nekik nem céljuk, hogy legyen egy szabvány, amit mindenki használ, nekik az a céluk, hogy legyen egy általuk gründolt szolgáltatás, amit mindenki használ — ez pedig nem ugyanaz, nagyon nem.
Összehasonlításképpen, az email nagy vonalakban egy pár darab RFC: az SMTP (RFC 821, illetve RFC 2821), az IMAP (RFC 3501), és a POP3 (RFC 1939) összessége. (Most itt nagyvonalúan elsiklok a POP3 before SMTP, meg hasonló extrák fölött, mert nem vágom fejből a számukat.) Ezeket a protokollokat az IETF tartja karban, egy nonprofit, az internetért dolgozó, és nem azon leechelkedő szervezet. És bár az RFC dokumentumok nem esnek “free” licensz alá (ennek is komoly irodalma van), az RFC-k tiszta, átlátható dokumentumok és nem változnak. Csinálnál saját mail szervert? Go ahead, ott a protokolldoksi, valósítsd meg, aztán hajrá. Csinálnál klienst? Detto, ott a doksi, csináld meg. (Csinálják is sokan.)
Ehhez képest egy Facebook Connect, egy Twitter Oauth, egy szolgáltató, vagyis egy profitorientált cég által karbantartott API-k, teljesen zárt licensszel (Terms of Use), amit bármikor kényük-kedvük szerint változtatnak. (Az RFC 821 1982 óta nem változott. Az Oauth ha jól emlékszem, úgy 2 hete.) Ami nem változik, az a hozzáállás: Facebook Connect-tel sose fogsz saját Facebook node-ot megvalósítani, Twitternél detto, a lényeg mindig az, hogy az adatod náluk, a szolgáltatónál maradjon, és lehetőleg ne lehessen egyszerűen átemelni, metásítani másik szolgáltatásban. Klienst megvalósíthatsz, de meglehetősen korlátozott funkcionalitással, gyakorlatilag slave-ként üzemelve az anyaszolgáltatás emlőin.
Ezzel persze semmi baj nincs, ha akként tekintünk ezekre a csökevényekre, amik: kommunikációs technológia helyett szolgáltatások. Ja, és: ha nem említjük egy lapon őket az emaillel.
Összefoglalva: a mai szolgáltatások “connect” API-jainak az a célja, hogy használatukkal még több adat folyjon be a szolgáltató adatbázisába és ezzel növelje az adott cég reklámozási képességeit, értékét. Az emailhez kapcsolódó protokollok célja az (volt), hogy az emberek tudjanak egymással kommunikálni.
Vannak kísérletek ma is interoperábilis technológiák, szabványok létrehozására, némelyiket használja is egy-egy szolgáltató. Az XMPP jó példa, a Google implementációjával még talán el is érem a jabber.org-os buddykat (asszem, de nálam okosabb emberek majd megtrollkodják ezt a mondatot kommentben). Az OpenID meg egy másik, csak azt meg a kutya nem használja. De persze ezek is csak addig jók, amíg nem implementálja a szolgáltató — kis módosításokkal. A Google Talk accountommal biztosan nem fogok tudni kommunikálni a Facebookos haverral, pedig mindkettő XMPP. Az OpenID lényege az lenne, hogy bárhova be tudjak jelentkezni akár egy saját OpenID authority által adott referral-lal — de ha minden igaz, már a Google se engedi ezt, csak néhány “trusted” szolgáltatót. (De megintcsak: javítsatok ki. Vidítsatok fel.)
Mi lesz az email után? Nem tudom. Azt látom, hogy ma semmi sincs még a közelében sem annak, hogy kiválthassa az emailt. Az egyszerű használhatóság (ami ugye a mai startup vonal Szent Grálja) szart sem ér, ha zárt a szolgáltatás. Márpedig manapság általában zárt.