New blog URL

I moved my blog again. You can now read my next publications here:

https://blog.addictedtointer.net

Come back

For a short period, I will publish on this blog again. To follow my writings, please read this blog until my next notification of change.

New blog

I migrated my blog to a new URL (my blog is now hosted on my Cozy). If you want to keep on following my stories, here is my new blog: https://frank.cozycloud.cc/public/blog/

It’s based on the Ghost bloggin platform. If I’m not satisfied with this new setup, I will come back to this wordpress account.

Building a startup: Hiring (May – December 2014)

13903385550_39f7316982_z

Fund raising creates a big momentum for your startup. All the people following your project congratulates you. For the other, your credibility increases and they are more likely to listen to you. Most of all, you feel relieved: Money in the bank will make your company safe for the next 18 months. But, the break doesn’t last long. You have to spend your investor money. The best way to do it, in a tech company, is to spend it in building bigger team. In the following, I will tell you what we did with the million of dollars we raised.

First employees

At Cozy we were already six. Having a lot of money was the opportunity to raise salary to the market level and offer stock options to them (our investors agreed to open an option pool). First employees deserve to have a decent amount of stock as a reward for their patience and their risky choice. Moreover, it’s good for the company because it makes their commitment stronger (if an exit occurs, they share the revenue with you and investors, which makes a good incentive).

Expert hiring

Once our core team built, we started to look for other engineers. We had a lot of work to do on the product, to make it really interesting. Plus we had to build an infrastructure to host the Cozy we will distribute. So we were looking for two developers, a devop and especially a senior system administrator.
To be efficient in our job search, we decided to rely on our network and targeted communities. It’s good to hire on recommendation. People won’t recommend someone they are not sure in. Moreover your friends that works in the same field, can help you in crafting your job offer (by the way thank you Haikel and Michael!). The system administrator was the hardest profile to find. We wanted someone really good at it. So, we sent the job offer only to close friends and to some targeted communities (like Saltstack France community). The offer was almost secret. Our strategy worked perfectly: we got a lot of good applications.

Our hiring process was based on three interviews: introduction (online), technical (online) and one big discussion about the project (face to face). It was long and we discussed with many interesting people. After many interviews we finally chosed Nicolas Ledez among a short list of three. Needless to say that the choice was not easy!

Build the team

For the software developers and devops it took more time. We made a public job offer we published on our blog. We had several very good applications. But, finally, we hired only people we met in meetups and who were interested in personal data issues.
Once our new member hired it was pretty easy to integrate them. We were used to collaborate with external contributors. Hiring someone is a little bit like having a new core contributor. There is already a lot of documentation,, efficient process to communicate and ship easily new delivery. That way newcomers are quickly at ease in our team. They can commit on day 1. The core team has an important role in this part. They ensure that every new employee has access to information. Plus they will trained them to the Cozy technology

NB: We published our offers before closing our fund raising. We took the risk to say that we were sure to close. So we  interviewed candidates during the fundraising process.

Make the company cleaner

Aside of the hiring, the fund raising was the opportunity to clean the legal stuff. We audit every aspects of the company and fixed what was required. Fortunately, there were only minor problems. The most important change was that we have monthly boards to define the strategy of the company. It’s great to share thoughts with experimented people. Our board is composed of a VC and two business angels with an entrepreneur background (in the Tech field). Providing reporting every month is a good habit. It’s the opportunity too to grab advice.

What’s new with Cozy Cloud

By that time, the product made a lot of progress. The platform and its application work better. Plus, we got a first version of our webmail client. We published a Mobile app that allows you to access files from your Cozy on your Phone and automatically backups your picture. About our hosting infrastructure, it became a lot more robust and we now  have a more efficient development process.

We are satisfied with the 8 months that followed the fund rasing. We built the team, made our business partnership stronger, built a better product and got more engagement from the community. Next six months (from January to June) will be dedicated to build a commercial offer with our partner. See you in July for a full report of this period!

Building a Startup: Fund Raising (October – April 2014)

5579064125_7968fa34c4_b

When you build a startup you have to chose between two directions: bootstrapping (make your business profitable as fast as possible without external money) or being venture backed (building product and gain traction as fast as possible and focus less on profitability). I could write a lot about advantages and drawbacks of these two paths but I’m going to make it short. At Cozy, we think that we need a fast growth to propose a decent alternative to Google/Dropbox services. That’s why we decided to look for VC funds. In this blog post I’m going to share the process we followed to reach that goal.

Investor structures

Before going further, let’s see the three major structures from where you can get funding.

Business Angels

They are rich guys who get together to invest money. Investing is not their main occupation. Most of them were or are entrepreneurs. If your application is accepted by them, one or two among them will follow your project and make you pass several interviews. At some point, they will consider you are ready to pitch in front of the whole club. Then, every member will tell how much money they want to invest in your company. They invest as individuals.

Micro Venture Capitalists

They are very rich entrepreneurs who invest their money alone or with one or two partners. Investing is their main occupation but they can still be considered as big business angels. They are are quicker to decide than VC and can provide you help even if they don’t chose to invest in your project.

Venture Capitalists (VCs)

A Venture Capitalist firm is a company that manages the money from big companies, government or  from very rich people. They are the one who can propose the biggest amount of money. Among VCs you have different kind: the ones that do only seed funding (500k-1M$) or only serie A (1-5M$), serie B (10-50M$)… There are the ones that invest only in e-commerce companies, the ones that invest only in medical company… It’s important to understand in which field a fund works. It’s almost useless to meet VCs that don’t fit in your money range or that don’t invest in companies like yours (it’s only good for networking).

NB: Geolocation matters too. Depending on their origin, funds won’t act the same way and words could have a different meaning (ex: in US a seed round can reach 10M$, in France the limit is 1.5 million).

Meeting VCs

Meetings VCs is hard. Cold emailing/calling is not efficient to meet them (unless you have very big figures to show, but in that case VCs come to you). So, the best way to see them is to get introduced by someone they consider valuable (most of the time several introductions are required).

That leads to another problem : where to find people connected to VCs? How to convince them that your project is awesome? Good news, the startup ecosystem is not so big! Bad news, you will have to network hard (and not work on your product by that time…).

To build your network, the simplest way is to be part of the ecosystem. For that apply to startup accelerators and startup events. Accelerators requirements are close to the one asked by the VCs, so it makes a good training to prepare your application for them. With Cozy we tried to get selected in Le Camping, Mozilla Web FWD and The Family. Le Camping rejected us (we applied too early, our project was not ready). Then we get selected for both WebFWD and The Family. They are both good but WebFWD was closer to the mantra of our project and offered us the opportunity to get introduced to the US startup ecosystem. So we chosed WebFWD. We learned a lot from that experience about every aspects of a startup. Moreover, we had the opportunity to improve our pitch in front of US coaches and VCs. Most of all, we met Pascal Finett, a startup mentor, who advised us to focus our business model on the B2B2C strategy (sell Cozy to distributors who will handle the marketing and distribution while we focus on the product). It helped a lot and made things really clearer for VCs and how big the things could become.

Once you pitch in meetups and once you get trained and introduced via startup accelerators your network grows. If you project is good and progress well, you will be introduced to several funds.
NB: Be patient, it takes a lot of time and requires a lot of efforts. And of course don’t forget to improve your pitch all along the process (be agile!).

Meeting Business Angels

Business angels work more in a traditional manner and are more accessible. The process is very scholar (fill a big form, make your interviews, accept their conditions and make the final pitch). BA clubs are very interesting to meet, since they are/were entrepreneurs too. They have a lot of good advice to share and their network will probably be wider than a VC one. The only problem with them is that they cannot put as much money as a VC firm. It’s ok for a seed round, for the the next ones you will have to focus on VCs.

Pitching

The first step of fund raising looks a little bit like a recruitment: you make several interviews until you know if you are accepted or not.

At your first interview, you do a 10-20 minutes pitch. Then you answer to questions. If you’re pitch is not too bad, you have a good discussion and the guy will look very interested. Then… Nothing! It will be your job to ask for the second meeting. No need to say that you must have good news to give them before doing your follow-up. It could be anything related to growth, team, press… If it’s directly related to your business model it’s from far better. What will surprise you is that if you don’t have huge figures, VCs will almost ask you to bootstrap your company before considering investing into it.

NB: A good sign that you make progress is when they want to see the whole funding team.

A note about the second meeting. Most of the time  you will have tougher questions. Usually there is a “bad guy” who wants to upset you and see how you react when someone says bad things about your project. At that point you simply have to be bullet proof to questions. That’s why you will have to meet a lot of investors: the more interview you will do, the more bullet-proof you will be! See the interview process as an iterative one and make you pitch progress each time you discover new things that investors like!

At Cozy, we focused on building partnerships with established companies. We won several contracts and partnership promises. That was plenty of good news to share with VCs!

What matters

Two things will interest investors:

– What makes you business valuable and what will make your valuation grows.
– How the funding team is consistent over time.

You will find tons of advice on the web, but the one mentioned above are from far the most important things to communicate to VCs. BA will focus more on the second point, since they can see themselves in you. The first point is obvious, at the end they are here for numbers and they want to be sure to have a good return on investment. The second point is important too, specially for seed funding. There is a not so low probability that your business will pivot at some point. So they can’t invest too much on your idea and its first executions steps. That’s why they like to invest in the founding team. They want  to appreciate you and feel good by thinking they will work with you for the next 5 years.

Let’s resume: to convince then you have to:

  • Tell them why your valuation will grow at the next round.
  • Prove them that you are already accomplishing what you say.
  • Show them that your motivation is still high six months later.
  • Have a good long term vision. They want to be able to imagine that your are reaching the IPO.

Termsheet

If you succeed in being selected by a fund you will receive a term sheet in which they write how much money they offer for how many shares. You will discover the valuation of your company and the terms of the investment. Be aware of terms like full ratchet, double dip, bad leavers, time to look for an acquire, etc. They can be very harmful for your share ownership or for your exit money. So, you have to understand them fully before negotiating them. You will have to find a good equilibrium between your valuation, the amount of money you raise and these terms. The investor will let you only one week to agree on these terms. Contact all the investors that looked very interested. They will probably make an offer too. The more funding proposal, the better it is for your negotiation.

Once the term sheet accepted, you cannot look for other funds anymore. So you have to wait for the due diligence. If you didn’t lie about you company state, you should obtain your money one or two months later.

Common Patterns

  • VCs look always very interested in your project. If they don’t that’s a really bad sign.
  • A no is always temporary, if you have really big news, they are always ready to change their mind.
  • In their team, there is a guy who loves your project and one who tries to find flaws everywhere.
  • They are slow to decide.
  • Really interested funds decide faster.
  • They all know each other and they share information about you.

To Conclude

Looking for funds is a tough path. It will require a huge amount of work and energy. Try to be smart and take the opportunity of the many pitches to get as much feedback as you can. Another good tip: when a fund refuses to invest, it doesn’t mean that all of the team don’t like your project. If you have some advocate their, they will still be glad to help you. Don’t hesitate to ask them for tips and info about negotiation and pitching. That’s all, I don’t have much more to say, so, good luck to you!

NB: I’m the CTO guy. So, don’t hesitate to ask questions in the comments or by email. If you need more accurate information about the process. I will ask to my business partner who led the fund raising and update the present article.

What’s new with Cozy Cloud

Partnerships

That’s all for VC stuff! So what’s new with Cozy? We started small contracts with one French ISP, one with a domotic company and we are still building a partnership with one of the biggest hosting provider in the world (this is why we need funding). And by the way, we are still running experiments with La Poste to build a backup box that people could plug at home.

Product improvements

Aside of the fund raising we worked hard on the product. We released the first version of our platform (the Snowden Release is already famous all over the world), we improved basic apps like the contacts and the calendar managers and built a synchronization module for contacts and calendars (this what our user were asking for!). We published a first version of our file manager application and we made some noise with the release of the first web and open source bank manager (build with our partner La FING).

Today we are thinking on how to build the first web mail application that could be a decent alternative to gmail. Should we work with the Mailpile team? Should we build our own one? That’s a tough question!

Community

The community keeps growing, we reached 500 stars on Github, earned 130 points on the Webdev Reddit channel and our IRC channel is always crowded. We got several contributions and now people from the community perform support.

Marketing

We focused more on the retention part of the product (the fact that’s it useful enough to people so they keep using it). People engaged more with us, so we can consider that it is a success. By the way, thx to Khuram Malik for his advice about that!

Final Thoughts

Six last months were quite crazy, the product made big progress and the company is now hot among the French investor eco-system. Today, everything is ok: we are closing our first fund raising round and we have an active community of users and contributors!

My Quantified Self Setup for 2014: JawboneUp + Withings SBA + RescueTime + Cozy + KYou

qs_setup_2014f

You’ve probably heard about  Quantified Self – the activity of measuring a lot of metrics about your daylife to obtain a better understanding of your body and mind. The purpose of this activity could be related to health, fitness, life logging, etc. For more details you can check my previous blog post about it.

How did I get interested into it? Since I started working on the Cozy Cloud project, I’m closely related to this movement. Cozy is a personal cloud that allows, among other things, to store all your personal data in a single data store. Plus, with Cozy you can build web apps that reuse this data. So, QS is an obvious use case for this platform that helps to put all your data together and allows you to get insights from them. Last year I wanted to quantify me, but because I’m not a hardcore QS and too lazy to maintain a daily recording, I needed tools that require little efforts to track my personal habits. For that, I found only proprietary platform with poor customization capabilities. So I decided to put this idea aside until Cozy becomes good enough to do it. That day finally arrives: the quantifying can start!

In 2014, I will use 5 tools:

JawboneUp
It’s a bracelet you wear constantly to count the number of steps you do everyday. It also tracks the number of hours of sleep that you had. I’m quite satisfied with it because I can easily fetch my data from their servers. I won’t go in a in-depth review since you can find tons on the web.

Withings Smart Body Analyzer
It’s a scale that records your weight and your heartbeat rate. It looks harder to download my data from my online account on their website. Besides that, everything works pretty well. The product is very easy to use and looks robust.

RescueTime
It’s an app that you install on your laptop and/or your desktop machine. It records the time you spent on each window or website. It categorizes each “activity” by labelling them with productivity flags. It works quite well, but since I find it to be super intrusive, I use it only to track my productivity when working.

Cozy
I use every apps of Cozy. They produce personal data directly to my datastore. No need to import them from an external service. I will build metrics from the Calendar, the Todos Manager and the Personal Finance Manager application.

Kyou and Konnector

In my spare time, I built two QS applications for the Cozy platform. The first one is “KYou” an app that allows you to build and show metrics from data stored in your Cozy. Once it was done, I was a little bit frustrated because it didn’t allow me to monitor other datas. So I built “Konnector” an application that  will allow you to import data from external services to your Cozy. Konnector will download my data from above devices and softwares (Jawbone Up, Withings SBA and RescueTime) as well as Twitter. With KYou, you can easily use custom trackers too. It enables me to track clarinet playing, hour worked, push ups and the number of times I eat outside of lunch. These devices and softwares enables me to track a significant amount of information. There are probably better analytics to build, but I’m still in an exploration phase.

Here are the metrics I will follow:

  • Mood (good, neutral or bad)
  • Number of events in my agenda
  • Number of done tasks
  • Money expense
  • Productive Time on computer
  • Hours of sleep
  • Number of steps
  • Weight
  • Heartbeat rate
  • Number of Tweets I published
  • clarinet playing or no
  • Push-ups
  • Hour spent working
  • How much time I eat something outside of lunch time

That’s all for this 2014 setup.

To conclude I will give you my my goals for that QS experiments:
1. Share what I learned from practising Quantified Self.
2. Match variations between different metrics.
3. Improve my understanding of the QS practice.
4. Get a lot of data about me to try finding what machine learning technics could be applied to.

I can already give you my first impression about it. It feels strange to monitor myself like I would for a server. On the other hand, having control on my data and having a global vision of what is happening made me think that it could quickly become very powerful too. I expect to write a full report in three months. See you then !

PS: If you have any suggestions about this setup, feel free to discuss them in the comments!

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!