When I introduced Taiga on Opensource.com, the article was well received. It seemed like people were looking for a new project management system and Taiga satisfied some of the requirements in mind. As evidenced, in the first month of its existence, Taiga gained approximately 12,000 registered members, 10,000 projects, and 1000 GitHub clones. They are also seeing considerable traffic from Fortune 500 companies starting projects!
I am a software developer and keen follower of Taiga, so when I learned about these stats I couldn’t resist and reached out to the CEO of Taiga, Pablo Ruiz Múzquiz. I wanted to find out how it all happened and more about the parent company, Kaleidos. Read on for how they scaled Taiga without spending a penny on marketing! And find out how the open source way has had a huge influence on their culture in the workplace.
Tell us about your professional and educational background.
This could be a long story, but to make it really short I will just say that I always wanted to be a scientist. I grew up strongly believing that studying the observable universe was the most amazing adventure anyone could have while still being alive. Unfortunately, when I was in my fourth year of my physics degree, I was so frustrated about my sudden lack of motivation to continue studying the degree (not physics per se) that I decided to quit and get a Computer Science degree. With a strong bias towards free and open source software and its ethos, I then convinced myself that I could still have a direct or indirect impact on the society by creating an ecosystem of engineers, scientists, coders, and hackers that would solve challenging problems.
After leading a free and open source software business unit for a big IT corporation for 7 years, I co-founded Kaleidos with 13 other people so that we could all put to test our ideas and dreams for a great IT shop that would eventually create something of its own. Nearly 3.5 years after that moment, we released Taiga to the public. It took some time, true, but we are on the right track.
PIWEEK is a week of time, held twice every year, for all of the developers at Kaleidos to work on their own projects. This is a part of the company culture. What's it like?
New developers that join Kaleidos respond enthusiastically, of course. The possibility to enjoy an entire week, every six months, to build and create either alone or with others whatever they see fit is something they consider almost a privilege. Releasing their code to the community is part of their ethos so unless they judge it poorly or not very useful, they will do that as part of their development cycle, and it's not just code, it might be visual design, wireframes, etc.
Our clients love this week too. It's a great opportunity for them to see what other stuff their (now mixed) teams can create, learn a lot during the process, and be reassured that whatever new ideas or technologies arise from the PIWEEK, they will be the first ones to benefit from them.
On the other hand, companies similar to ours, other IT shops, have a hard time committing to PIWEEK and most of the time they will tell us they have to turn down our invitation due to work overload, risk of upsetting their clients or, worst of all, because they don't believe their employees would have any great ideas or skills. This is sad and frustrating but after 6 PIWEEKs, I've grown used to such responses. I don't know, maybe we keep telling ourselves it is very easy to "implement a PIWEEK" since it was our foundational document and not some alien idea brought by others.
Kaleidos is a service-oriented company, so how do you justify your developers working on PIWEEK to your clients?
Well, first of all, let me share with you that "service-oriented" is a term we mock at Kaleidos. We re-coined that term to make fun of the corporate world, the buzzword density in many texts and any sort of ill-based allegiance between contractor and client. But, yep, I get the point! :)
As I said, clients do like the PIWEEK. The proved to be smarter than many people thought (which is hinted at in our Manifesto). They can perfectly understand having to stop 1-2 weeks in their 6-12 month project to let Kaleidos employees have total freedom on what they want to learn or create. It is not only a source of motivation for us but a unique opportunity to learn new things, especially out of our confort zone. Our clients are happy to attend the Friday demo and cheer all the time because they get it. So the question might then be, how can Kaleidos afford to "lose" 2 weeks of income? We can do it because we are very good at making time estimates for our projects. Our clients are mainly startups and they need fixed dates. We commit to those dates provided that they will in turn commit to the Agile Manifesto and provide us with quality information. When you have that, you have profits, and when you have profits, you can spare two weeks for two PIWEEKs a year.
Taiga has been well-received by developers all around the world. Whom would you attribute this success to and why? What according to you, worked in favor of Taiga?
Hmmm, we are still trying to understand what is going on, really. We just celebrated our first (monthly) anniversary with more users and projects than predicted for the first nine months, especially having spent $0 in marketing. But if I had to make a guess on what happened, I would choose these three things that worked in our favor.
Open source: Taiga could have been yet-another-agile-project-management-tool with SaaS as its business model, but we didn't want to go that way at all. The repository (if anyone wants to check) has been public for more than 12 months. People loved the idea of having a truly open source tool for project management, even if they would prefer to use our SaaS platform. It's a tool so close to development (like source control) that many people really need it to be open source. The fact that it had an impressive API helped a lot too.
Beautiful design: Of course, your mileage may vary, but Taiga is clean, neat, and fast. Your project simply looks better if you use Taiga. We designed the interface in a way that we could stare at it all day without getting depressed, basically. Xavi, one of the Taiga members is known for repeating: "No way, we have enough buttons already!" to his colleagues.
Built with Agile in mind: This was key. It is very easy to develop a generic project management tool and then, as an afterthought, add Agile "stuff." This might be OK if your platform wants to be generic with steroids, but we wanted to build an agile tool, period. So people that have been working with things like Scrum or Kanban immediately find themselves at home and others that are considering adopting the Agile culture for their teams and projects, tend to think "this might be the right tool!"
What are the open source tools and technologies in use at Kaleidos? Any personal favorites?
When we started Kaleidos, we decided that we should choose the right amount of "diversity" when it comes to technology stacks. The two winners were two MVC (sort of) frameworks, Groovy/Grails, and Python/Django. To date, we have been able to give a proper solution to every challenge thrown to us from any startup. Surrounding these two frameworks we have GNU/Linux (Debian, Ubuntu, Arch), PostgreSQL, Redis, RabbitMQ, Nginx, backbone, and AngularJS—among others. You might also find traces of MongoDB, Apache, or C++.
In terms of desktops, Kaleidos employees have total freedom as long as they use free and open source software (you can see the subtle irony). Pablo Alba, our CTO, did a quick survey some months ago to identify our individual preferences in terms of Linux distro, window managers, and code editors—the results speak for themselves. The prototypical "Kaleider" would use Arch Linux, change window managers every couple of months, and use either Vim or Emacs.
For the record, I use Arch, Gnome/i3, Emacs, and favour Python/Django over other languages or frameworks.
Any advice to budding entrepreneurs on why they should take the open source way?
I remember nearly 20 years ago when I was trying to convince people to switch to open source. I explained to them that like all things that correlated positively with the growth of the Internet, free and open source software would continue to grow exponentially thanks to the vibrant community. I would still use that same argument, but I can now relate to great startups completely relying on open source for their development and operations. If you ask me about open sourcing your very core, it becomes trickier for many businesses, but I'll go ahead and make a couple of predictions:
Software and source code will gradually become a commodity. The ability to harness a greater and healthier community around your project will make a difference. It is amazing how many companies are obsessed in creating a community of users and not worried at all about the (developer) community that could bring them sustainable development. Besides, transparency and trustworthiness will become key differentiators for online businesses. You can always try and open source a non-core portion of your project and see what happens. Some great de-facto standards were born this way. I believe that more and more companies will open source peripheral components of their architecture to follow a developer-friendly policy and bring more talent to their teams.
These are pragmatic reasons, one could argue, but I would like to add a more ethical one. Developing the open source way does little harm, really. It might be foolish to do so, or it could be your best option, but if you are going to follow this path, I would ask that at least you understand the core principles of sharing knowledge and community behind open source so that you honor the work of many, many talented and generous people before you. Maybe this is my personal way of linking science and human knowledge over centuries with open source, and that is why I don't feel alienated at all despite quitting my science career.
Comments are closed.