User: Hellekin/A Coder Perspective Of GNU Social
A Coder's Perspective Of GNU Social
Following A User's Perspective..., this (shorter) text explores the other side of the application.
I Should Be Free...
... To Use My Favorite Language
I should be free to use whatever language I want.
More and more, languages are a question of preference, as a language's specificity tends to disappear over time with new libraries, more powerful hardware, and cross-language bindings.
Of course, Erlang and PHP are not comparable, one being conceived from the start for maximum uptime, as well as distributed parallel computing, while the latter started as a way to bring dynamism to static web pages.
But in general, many languages are inter-changeable according to the coder's preference, and the target application: for speed, you'll prefer C or C++, but for speed of development, you'll go for Python or Ruby, etc.
In any case, forcing a language on coders will close more opportunities than not.
... To Code For the Future
Although Ian Hickson announced that the HTML5 specs won't be ready before 10 years, WebKit integrates it, and it's de facto standard on mobile devices, making it a very good candidate for future applications. And we all crave that WebSocket thingy.
Coding for devices supporting HTML5 offers many more possibilities that won't be available to proprietary platforms, but it shouldn't stop me from doing it anyway: disruptive technologies start small, don't they? If it's good, proprietary software companies will follow, or die, or keep their blinders on and I don't give a shit.
... To Ignore Market Constraints
When cars started to appear, the majority of people were using horses or their feet. In our precise case, the majority of people use Facebook. Should we follow Facebook and Microsoft, or make free software? I'm for the latter.
That doesn't prevent the project from offering a compatibility layer, that should actually be implemented by the different players on their own dimes. Microsoft has long been a huge time waster for web developers, it's time they spend a little of their own on catching up.
Not starting from market constraints imposed by alien orders provides a lot more space for thinking out of the box and coming with real alternatives.
It's important to realize that, if we go for a system fostering privacy, intimacy and confidentiality, we're going for market disruption: who's going to pay for the service, if they can't profile you?
... To Use [insert project here] as a Base
Of course, the objective should be to make it as easy as possible for the user to benefit from the best of both worlds: I'm not using GNU Social for the sake of it, but for the added benefit it offers me, in addition to being able to interact with my contacts on proprietary social networks.
Some will prefer starting from scratch, others from an existing project. Both solutions should be doable. Many times on the mailing-list, people pushed their projects forward, commenting on a previous contribution on what could be done, saying that "my project does it already" and that kind of things. Very good, then start from your end of the line, and come up with the missing link to the "core": what's in-between, across and beyond Elgg, Crabgrass, PSYC, XMPP, FOAF+SSL and others, as well as between Facebook, Wave, Twitter...
OAuth appeared as a mean for different services to provide inter-operability, while keeping each and everyone's way running smooth. Is GNU Social the OAuth of Social Networking?
... To Embrace the Market
If I prefer to cover a lot of ground and steal the user-base of Facebook, why not? It might be the shorter path to making people switch, to provide a Facebook-like web-based application.
But that can only work if the application is merely a GUI to the GNU Social core engine, so that both can evolve independently. Otherwise, duplication of effort will finally break the dream apart. On the long term, that is useless.
GNU Social Architecture
The application, or rather set of applications, come with a lot of constraints. On the paper, it looks like the Grail. It's supposed to embrace all visions, all devices, AND make the coffee.
The vision of "running it on any commodity server" doesn't match two of my expectations at all:
- Offline mode: how can you run GNU Social on a server, and use it offline?
- Confidentiality: how can you trust the third party server?
Addressing Connectivity
Not all people are online all the time. The GNU Social applications should therefore be available for offline use. Obviously, some cannot be used offline (e.g. checking a friend's availability), but all the contact management and edition should be thought of for disconnected use.
Addressing Confidentiality
In the case of third party hosting, the GNU Social applications should make sure the server won't compromise the confidentiality of exchanges between different parties. That can be done by using encryption on the client side.
