Il blog di Rackspace ha pubblicato un’intervista al creatore di Redis Salvatore Sanfilippo, con lo scopo di carpire tutti gli aspetti e le best practice della community Redis e migliorare così la collaborazione fra gli sviluppatori di app, gli amministratori di database e gli utilizzatori di Redis to Go.
La scelta di intervistare Sanfilippo nel corso dell’ultima Redis Conference ospitata da Rackspace a San Francisco non è casuale, in quanto Sanfilippo è uno sviluppatore di software open source staffato da Pivotal sul progetto Redis, nonché il creatore del progetto, e si occupa di gestire la community, lo sviluppo, la mailing list e tanto altro, insieme a Matt Stancliff.
La prima domanda rivolta dall’intervistatrice, Ashley McNamara, a Sanfilippo riguarda l’importanza del concetto di open source. Sanfilippo sottolinea la validità e la forza dei progetti open source nell’opportunità che si ha di ottenere contributi operativi da diversi settori, da persone con diversi gradi di conoscenza e capacità. In nome dell’open source si mettono insieme diverse skill e diverse capacità analitiche e i progetti, di norma, sono subito disponibili alle persone che decidono di investirvi e di utilizzarli.
Da queste caratteristiche, la volontà di mantenere Redis un database open source che possa, quanto prima, trovare una sua collocazione precisa accanto ad altri nomi altisonanti di database come MySQL, PostgreSQL e via discorrendo.
Ognuno dei database oggi presenti sul mercato non si focalizza solo su una determinata funzione o area di funzionamento, semplicemente perché bisogna accontentare diversi casi d’uso anche in nome della concorrenza con altre tecnologie di basi dati.
Così Redis, secondo Sanfilippo, troverà il suo posto fra le tecnologie NoSQL oppure morirà per far sorgere nuove tecnologie in merito.
L’evoluzione di Redis dalle parole di Sanfilippo
Infatti, l’evoluzione di Redis nel corso degli ultimi sei anni è stata importante, tanto che oggi Sanfilippo parla di un sistema di database più sicuro, con migliori meccanismi di failover, con un sistema di distribuzione dei carichi di tipo master-slave e una comunità che per Sanfilippo rappresenta la nota più gratificante dell’intero lavoro con Redis.
In questo senso, anche la community legata a Redis è cresciuta, assumendo anche un aspetto più democratico con l’ingresso di componenti non altamente specializzati ma che sono utenti della piattaforma e sono quindi in grado di suggerire idee e feedback sul funzionamento della stessa.
A supporto di tutto, c’è una grande documentazione che spiega davvero nel dettaglio molti aspetti di Redis. Sviluppata per la maggior parte da Damian e Michael, due utenti veterani della community, la documentazione è comunque opera di Sanfilippo che cerca in tutti i modi di scrivere da sé tutte le note e quant’altro, essendo anche il principale sviluppatore del progetto e, quindi, il più informato sul funzionamento esatto della piattaforma.
Per il futuro, Sanfilippo guarda a una piattaforma Redis sviluppata con un linguaggio di programmazione di più medio livello, che sia capace di prendere il posto del linguaggio C e C++, senza però andare a scomodare linguaggi di alto livello come Lisp, Ruby, Python e via discorrendo.
Per chi volesse maggiori informazioni, di seguito viene riportata l’intervista intera in lingua originale.
Ashley McNamara: Tell us a little about you and your current role.
Salvatore Sanfilippo: Yes, my name is Salvatore Sanfilippo and I work at Pivotal as an open-source software developer, specifically working on Redis. Meaning, I manage the community, the development, the mailing list, the parties, everything. Matt Stancliff is also on my team and we are core on the project.
AM: Can you explain to a non-technical audience why open source matters?
SS: It’s very interesting because you get to know many different kinds of people, because you get contributions from all around the world and you see that people are really different minded.
Some people read all the source code and analytically, just in their head they find bugs. There are people that are much more pragmatic and only ask you to make changes because they need them.
You see many different people with many different skills, but the interesting thing is that this process happens publicly, many people join the discussion and the result is, compared to working in a similar project within a company, is that you get much more exposure. Maybe you are doing great things within your company but nobody knows, instead with open-source everything is immediately available for people to see, not only your failures, but also, your successes.
Also, one of the things that is rewarding about open-source is that arguments matter. There’s no marketing, nothing that your boss tells you to say, it’s just what are the better arguments, people fight with their thoughts and what comes from that is software, the output of all of that process is software.
AM: Why in your view, will Redis become the preferred database technology?
SS: This doesn’t really happen. My idea of the software development world is to have a lot of diversity and I hope that there is a place for Redis, a place for another type of database, a place for relational databases like Postgres, MySQL, Memecache, and Redis.
Every database should try to focus on solving a given problem for a given set of users. My feeling is that databases are starting to look more and more alike because, of course, you serve a given use case and you want to do it in order to compete with other databases.
We think of open-source as a way to improve the world, why should there be this harsh competition? It’s good to compete on ideas, if I can do what you better, then the community is going to benefit, but not if I am going to stretch my database system just to compete with you.
My hope is that Redis will serve it’s place as well as we can, but I hope Redis dies because it means that another superior technology will emerge. So if it dies, I can work on new things.
AM: What technologies are you playing with right now? What’s exciting?
SS: Currently I am interested in programming languages that could replace C and system software.
There are a few strong candidates, but they’re not ready for primetime. It’s pretty impressive what’s happening in the programming language community because it was like there was the low level like C and C++ and stuff like that and then there was the high level like lisp, ruby, Python, but finally people are starting to realize that we actually need that mid-level the strong types, compiled, but more abstractions then what C provides you with.
So that’s currently what’s interesting to me, but also, the important thing that’s happening that I find interesting is that people are often dealing with distributed systems, but now most developers are realizing that they’re dealing with distributed systems have certain behaviors. This isn’t really a software change, but it’s more of a cultural change that will be reflected over the course of a few years in software itself.
AM: Are you talking about Rust when you’re talking about a mid-level language?
SS: Yes, it’s one of the things I’ve been looking closely at, but also I hope to see a better C++ an evolution of C directly, because swift, for example, is still high level. Swift can solve a lot of problems, but you can not write Redis in Swift with the same behaviors.
AM: Can you describe how Redis has changed over the last six years?
SS: Redis has changed in the level of maturity of the system, of course, because it was a very conservative development path, what we had in the first version is still 50 percent of what we have today, but it works much better than it did in the past there are also new additions that were added along the history of the project, but the most interesting things are the fact that persistence works better, the system is more safe and now the system can be executed as a distributed system with automatic master-slave failover and automatic sharding, so a lot of what was there when we started is still there and the gist of the evolution was defined in making it the same idea, but better executed instead of making it a bigger idea.
AM: You guys have such a successful community so can you talk a bit about your community management role? How do you foster good development among people? How do you get them to care about the Redis community when there is so much open source noise? Because people care deeply.
SS: Yes, the Redis community is one of the most rewarding aspects. In the last 6 years because I am friends with a few long time users and I believe that the community is growing more and more. What you see is that the initial community was, of course, high quality, not from the point of view of the quality of the person, of course, but people were much more informed about the product because it was a smaller community, it is not a natural evolution so now the challenge is that we have to understand how to handle people arriving and maybe asking more obvious questions, so we need to improve the documentation and stuff like that and also one of the other challenges is that the larger community means more ideas and it’s easy to get overwhelmed from all the new feedback and ideas, the people who want to send you private emails, because from their point of view they’re just sending an email but many people are sending emails and then your inbox is full and you can’t reply to all of them and then you feel bad because you can’t reply, but you really have no option, in general it’s a really great community where there is a high degree of respect of one another and I am very supported by the community.
AM: Speaking of documentation, your documentation is very nice; did you have any inspiration for the documentation? Were there any other sites that inspired you?
SS: Basically the docs, in my opinion are part of the code.
I write most of the documentation myself, but the website is the great work of Damian and Michel who are two long time Redis users that contributed an impressive amount of things, for example the Redis logo was contributed by them and so the layout is completely up to them, I just try to write the documentation myself to make sure because the documentation for open source projects is believed to be the biggest complaint by users and if it’s not the software developer who’s writing it how are you sure that’s what’s written down is exactly the behavior of the code? One funny thing is that when I write the documentation, many times I find bugs just writing the docs, not even checking the code, because if I can’t write it well enough, there is likely some undefined behavior in the software itself that I find when I am writing the documentation.