What I learned from three years of FLOSS projects development

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.

timeline_github_1113

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!

image rmll

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.

communaute_cozy

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!

Talk @ LSM 2013 (RMLL)

In two days I will take part of the Libre Software Meeting 2013. I will give three talks on monday and tuesday. I hope to meet you there and have fun time discussing about the future of the web! Here are the subjects and schedules:

I had a good time at FOSDEM 2013

Last week-end, I came for the second time to the FOSDEM an event about free and open source softwares. Hundreds of conferences, a lot of interesting people and new technologies to discover are what can define the FOSDEM. The most interesting conference I saw was about Heat a template engine for OpenStack: describe your cloud in a file and Heat will build it for you !

_MG_9820The Freedom box band had a nice concert with rockstars: buddycloud, jitsi, etc… XMPP tools seem to be well considered. Maybe I should switch Newebe protocol to XMPP to make it accepted in their project ;).

_MG_9805There were cute computers: children are welcome!

_MG_9811This the nice place where I slept. I traveled to Brussel with Florent Gallaire, a French advocate specialized in software intellectual property. He is also a txt2tag contributor. He introduced me to his friends who hosted me for one night. I had a pleasant time in this typical belgian house, thank you guys !

Distributed Social Networks digest – january 2013

JDLL 2012 talks

A small post to share the slides of two talks I made @ JDLL about Newebe and Cozy Cloud.

2 years of FOSS Project, retrospective

On ocotber 19th 2010, I launched the Newebe Project, a distributed social network written with Python. Yes, it has already been already two years since I started the libre software aventure. As a recap, like last year, I am posting here a little retrospective of what happened during the past year.

Positive points

It still works. For the past two years I have used Newebe every day. It serves to communicate with my family and close friends and I’m satisfied of what it does. My Newebe loads quicker that Facebook, I see only the essential and I don’t feel limitated on what I say. Of course getting control back on my data is pleasant too.

Newebe got its first big contributions. During the last PyconFR hackaton, two contributors improved the Newebe packaging (thx Majerti!). This really accelerated the project and was the occasion to improve the code too and it reminded me that a good development workflow is a factor to be considered.

It led me to build a startup Last year, the company I worked for closed. I was unemployed and I had to ask myself what to do next. Since computer science field offers good opportunities for entrepreneurship, I oriented my focus towards it. At the same time, by looking at some articles related to the Newebe themes. I found a message of my actual partner. He was looking for people to help him to create a startup about self-hosting. Today, we are building Cozy Cloud an easy-to-manage platform for self-hosted web apps.

This pushed me to be more proactive and meet people. In the past, I was not used to participating in computer science events. Since starting Cozy Cloud I started going to several different ones. It then motivated me to go to events related to libre and open source softwares, like FOSDEM, LSM, PyconFR, etc. I even got the opportunity to do two lighthning talks! It also facilitates me in meeting various high-skilled people that like to share their knowledge.

I kept on learning and I did my first contribution to another project. It taught me new different things and now I can understand better what very technical people say. These past two years I feel that I have progressed a lot more than in my five previous year of professional experience. I also did my first contribution to another libre software called Fabtools.

Improvement Points

Truth be told , I’m afraid of the Dead Project. Sometimes developments takes a long time. I feel that it doesn’t progress fast enough and nothing moves on the software. It’s really an issue because I am thinking that this will cause the few people interested by what I do to move away. It’s a struggle to manage both development and community animation and I feel guilty if I don’t commit every week.

Number of users. I would say that I am not yet at maximum in building a user community. Lean startup principles would say that I didn’t do the right things. That’s why it’s not a surprise that the number of users are not yet as expected. However, I’m working on it : notably by making the installation process easier.
Moreover the good part of making a libre software is that you can do what you want and you are not obliged to seduce a huge mass of people.
A big contributing community has not yet existed. There are contributions- codes or advices- but they are rare. Most of FOSS projects are one-man project. This fact gives me assurance, but I can’t deny that a community à la Diaspora makes me dreamy.

I’m still exploring on the functionality. Previous inputs made me think that Newebe is not yet the most ideal solution to the problem of the centralized social network… At least, it serves me and the rest of it users well.

What’s Next?

I still enjoy working on this project. it allows me to experiment on different areas and it gives more variations in  my daily life. So, for next year, I will try to keep the same rythm, one release every six months and to focus on making it more user friendly (install process, better UI, communication protocol…). Coding a FOSS project is a great entertainment, so I’m going to take a little more.
That’s all for this year! If you had a similar experience or advice feel free to share the in the comment section!

Newebe @ LSM

Hey, I will be at Libre Software Meeting 2012 (aka RMLL) where I will hold two ligthing talks!

  • The first one will explain why Newebe is different from other social network, monday 12:15.
  • The second one will be about my startup project, Cozy Cloud, and will give you some hints on how to make organic web apps, tuesday 12:05.

See you there !

Image