It’s almost a tradition, like the two previous years (1, 2), I share my feedback about a year of FLOSS project contributions! Everything began on October, 19th 2010 (I know I’m a little bit late) while I started the Newebe project – a distributed social network. It led me, eighteen months later to Cozy, a startup that distributes FLOSS personal clouds. This year, my feedback will be mainly related to the code we produced at Cozy and focused on three subjects: development, tech talks and community.

Development

I changed the way I code. I no longer look for the best way to code something but for the most comprehensible one (I don’t try to refactor everything, I make variable and function names explicit…). Fortunately, concise code fits well with that, so my code stays clean.

Automatising is boring but it will make you happy. I wrote more bash aliases for local development and fabric scripts (thx fabtools!) for server management. And you know what? It really makes my life easier! I spent a lot less time on repetitive tasks (this link will give you a framework to find good alias to add) and I can focus more on exciting ones.

I forced myself to use vim as it should be. First, I blocked my arrow keys to navigate only with h, j, k and l. Then I looked for more shortcuts and changed the bindings I didn’t like. At the beginning it was painful, but today I code mucr faster and I do less useless gestures. At last, with vim, it is very fun to always look for efficient key combinations.

I discovered that git workflows based on a lot of branching are not well suited for every projects. Maybe they perform well for big projects or projects with a lot of versions, but Github fork workflows look good enough for most of the others. I fully embraced that idea when I read the chapter 6 of the ZMQ guide: they suggest to keep only a master branch on the main repo while the “work in progress” stays in the contributor forks. This way you keep your main repo branches clean (there is only one!) and it makes easier for new comers to start contributing.

Making the code modular really helps the collaborative works. You can write on a part of the code without annoying the others. And don’t be scared about module communications, most of the times module interactions are not so complex as expected.

About my first project, Newebe, I bit off more than I can chew: I decided to rewrite fully the User interface. Because I didn’t have much time anymore to spend on this project, my progress was slow, I felt discouraged and the work is still not finished. Keeping a small steps planning for a project on which you can’t work a lot is better suited.

Working on Libre and Open Source projects makes me really think more about collaboration. I discovered too that simple open tools can be really more optimized and that time management cannot be neglected even when I code for fun.

Tech Talks

WIth Cozy, I have had several opportunities to give talks about the project or about related technologies. Moreover, we were part of the Mozilla WebFWD accelerator program. Among many other things, they taught us the art of pitching. So today, I share with you good techniques I learned regarding tech talks.

You should not put too many new concepts in your talk: it will make it harder to follow. It’s easy to fall in this trap, specially with stuff on which you work on. They look very common to you but this is probably not the case for your audience.
ex: when you read a lot of articles about SASS, that doesn’t mean everyone knows what a CSS pre-processor is.

At Mozilla, they made us do an interesting exercise : write the content of your talk depending on the audience expectations (write down the questions your audience will probably ask by listening to you). During a talk you are there to bring something new but you also have to answer to the related questions. The Q&A time is not enough for that.

During most of my talks, I felt that people wanted to ask me question early on. So, if you have the opportunity to put a Q&A session in the middle of the talk, do it! Talks are often too unilateral, letting the audience to speak will make your presentation more dynamic and will bring additional details to your subject.

Speaking louder help to modulate your voice. Modulation help you to emphasize the most important parts of your talk. This is true for the flow too, when you manage well your rythm it will make your speach easier to understand. Beware of microphones that won’t allow you to speak as loud as you would like.

Talking to an audience is a little bit like playing music in front of an audience. When you miss something (you forget words or details, have an embarrassing hesitation), go quickly to the next idea like nothing happened. On the opposite, always be very well prepared for the introduction and the conclusion.

Before doing talks, I read a lot of articles about how you should move on stage and fill the space. It’s a good point but most of the time you won’t be able to move a lot. Sometimes you cannot even move from your desk stand. So don’t expect to be able to move a lot.

Recording your talk will help you to understand what to improve. Thank to the LSM videos, I noticed that I make a lot of nervous gestures, which needs to be improved!

I had limited time to practice my talk and practising is very time consuming. So I apply a principle learned by playing music: practice most the parts that are your weak points.

Learned at Mozilla: always put a call to action at the end of your talk. It will give a way to your audience to follow the discussion after.

Last but not least: never forget your bottle of water!

Community

With Cozy, we are in an entreprise mindset. So we have to make our community grow quickly. It’s a tough task because we have to please to a lot of people while keeping our vision. What I just described there is part of the role of the community manager. I don’t like the term management when applied to community, I prefer to say community facilitator. What I meant by it, is to make a community grow, you have to provide it all the required keys to take the ownership of the project.

In this optic, the most important thing I learned is that a project is often too hard to understand at first glance. It’s true for contributors and users: to allow newcomers, you have to make it simple on every aspects of your projects.

Two events helped me to fully understand that. This summer, I read the chapter 6 of the ZMQ guide that explains how every action required to start with your project should be frictionless. At the same time, I noticed that request-json, one of our smallest project had a lot of external contributions, even more than the other projects which are much more exciting. How come? you ask, because the concept lying behind request-json is simple (HTTP client to deal with JSON APIs), source code is short, easy to read and is kept inside a single file. Finally the documentation is quick to read and is accessible directly from the README. To make it short, everyone can learn everything about the project in ten minutes.

To illustrate, here is what we did at Cozy:

• Our documentation is more accesible and visible. Even a Github wiki requires too much effort to be found. Most people don’t think to look for it. So we put our documentation directly on the project website.
• Code samples were written in Coffeescript. We changed that for Javascript. There are more people who understand Javascript than people who understand Coffeescript.
• The website is clearer and it shares our objectives for Cozy (advice from Swarmwise by Richard Falkvinge). It gives a good platform to start for people who are interested in the project.
• We simplified our forum, from a multi-section forum we move to a single section google group.
• About the code we changed the base framework of our applications to a lighter one framework plus léger with a clearer file structure.
• Finally, we allowed people to try Cozy via virtual images before running the installation process.

The results were good, more people posted on our forum, the number of Cozy application downloads doubled to 3000/month and we obtained a really big contribution on one of our main module. This approach works.

I will conclude this part with this advice; a modular project makes contributions easier: to work on your project, newcomers don’t need to understand all the code. Here are two good exemples of projects that already does that and works well. Weboob a tool that allow you to browse web content from the command line from different sources (social networks, youtube, banks…). Any contributor can build his own connector without knowing the core code while getting advantage of the core api. Result: hundreds of modules are available. The other project is ZMQ. They build their community around the language bindings. Main commiters are few and work on the core code while the community maintains the bindings, they just need to know the core features. Result: there is a ZMQ binding for every popular language.

Conclusion

I’m glad I discovered all this new things, but I have to admit that it would probably have been more efficient to start my FLOSS developer carreer by contributing to an existing project. I would have probably learn things quicker in a better context. When I started Newebe, I was urged by my problem to solve (to have an alternative to Facebook) and it gave me a lot of energy.

Voilà, that’s all for this year. I have a lot more to share but I think there is already enough in this post. So I will stop there. Thank you for reading and see you next year!