10 Learnings from Open Source
By Jacques Joubert
“It’s the possibility of having a dream come true that makes life interesting.”
(The Alchemist by Paulo Coelho)
As many of you will know by now, Hudson & Thames is pivoting towards an open-core business model and away from our dreams of pure open source and the “unlocking the commons”.
What follows is a very brief history of our learnings with open-source.
Starting Out
MlFinLab started as an ambitious project for Ashutosh and my (Jacques) Masters in Financial Engineering at WorldQuant University. We had earlier in the previous year attended Quantcon2018, where Dr Marcos Lopez de Prado gave the keynote lecture and distributed his minty fresh first edition of Advances in Financial Machine Learning.
We started off on the heroes journey to implement all of the techniques in the book and share our findings on Github. From the first commit, we had a lot of community interest, which led to new friendships and a power team (Alex Proskurin (co-founder), Aditya Vyas, Illya Barziy, and Alex Kwon) to build the new sklearn for finance.
Github provided us with a great platform to attract talent and build out the vision we have.
Unlocking the Commons
Fast forward a few months and we had finished the first textbook and dozens of additional academic papers. The package was booming and we were making top 10 lists and trending on Github.
Famous quants and CEO’s were tweeting us and when I moved to London, several funds had invited us out to private clubs and tea houses to pick our brains on key topics.
Lesson 1: What Motivates Open-Source
Daniel Pink wrote that the things that motivate people are autonomy, mastery, and purpose. These are the 3 golden pillars of open-source and it highlights what we believe to be the strongest motivation for people to contribute. I add the extra theme: It’s all about reputation and building one.
This provides you with purpose, you’re making a difference in the world and people are noticing you. It takes time to plan out the tools that you want to work on (autonomy) and in order to do so – you will need to stretch your skills and learn how to write production-level code (mastery) that thousands of quants will use every day (reputation).
Lesson 2: Reputation and Marginal Utility
However once you have reached a certain level of reputation (and its different for everyone), the marginal utility you derive starts to get very thin. After months of working 100 hour weeks, every Saturday and Sunday, guzzling down fast food, and sacrificing time with your family – it starts to take a heavy toll on you and the utility you derive from reputation is no longer sufficient.
The biggest part of having an open-source project is not the coding, It is the high-quality documentation, tutorial notebooks, blog posts, fixing bugs, and answering all user questions – that takes by far the most time. Answering questions takes the most time as the context switching and revising techniques has a high warm-up cost.
Lesson 3: Revenue is the Lifeblood of an Organisation
To quote a mentor of mine: “Android is built and maintained by Google and de facto by Samsung, at GREAT cost and with GREAT effort. Android did not emerge from the soup.”
The truth is that it cost money to pay for things like journal subscriptions, staff, cloud storage, data to train your models on. Just to give you an idea, I have in my personal capacity, spent more than 20’000 GBP on MlFinLab and have paid for salaries out of my own paycheck, long before we started to generate revenue.
So herein lies the problem, it’s not sustainable.
Now there are many ways to raise capital for open-source projects but we opted for the “Unlocking the Commons” model where if a threshold level of revenue is reached, a close sourced tool is open-sourced. Our problem was that everything was already free and we were hoping that by setting a deadline that users would vote with their money. If the community valued our product, they would help pay for it and provide us with a revenue stream via Patreon.
We set up several tiers including a community slack channel, branding, and insurance for if we should ever pivot to close source.
Lesson 4: Users are Guided by Self Interest
I agree with Bill Gates when he said that open-source and free software is a form of communism. Now before everyone freaks out, understand that I think it is a beautiful philosophy. A place where a community of people come together and contribute, each to their capability and we share equally in the rewards.
Except this is most certainly not what happens. Here are some facts:
- Less than 1% of our codebase was from external contributors and it was usually for a 1 line bug fix. 99% of all the code was written by internal members.
- As soon as a user figures out that improving a piece of code in our library may lead to a marketable product, they won’t contribute. This has happened multiple times in the past where the Sequentially BootStrapped Ensemble algorithm was sped up and then not committed to the library. The only way that piece of code will ever get faster, is if a team like ours, who is paid to do so, does it.
I would like to stress this point and say that there are 2 other packages which were created by users whom we taught how to write production-level code, welcomed them into the organisation, provide them with resource and topics, and when they thought they could do better without us, they opened their own libraries. - If you write a good piece of code, the community will expect you to have great documentation and to answer any and all questions they have about it, for free. Now, this is a great way to build a community but eventually, the Git Issues start to pile up and now you are no longer an engineer but the support desk.
Lesson 5: Users Want Goods and Services Not Sponsorship.
Raising sponsorship was very difficult and we only ever saw traction if I phoned and emailed connections to ask for support. As soon as I stopped reaching out, the sponsorship started dropping.
Now let me pause here to say a massive thank you to our sponsors (Gold and Platinum) and to all the true dreamers out there who buy into supporting open source, you are the salt of the earth!
I interviewed Patreons to ask them what the main drivers for their sponsorship were:
- They wanted a good CPM or CPC rate and associated branding. It was more about marketing and building their brand than supporting a cause.
- They wanted access to our slack channel, lecture videos, and Jupyter Notebooks.
This is important: If your product is already free, it’s super hard to motivate people to sponsor you! Almost all our revenue came from the slack channel and a handful of very generous believers. The problem was that everyone thought that everyone else was going to support us.
The Pivot: Open-Core
After 9 months of trying to raise money and building a better product, we reached a peak of $1970 this dropped to $1890 when I stopped phoning people and pushing to get sponsorship so I decided, fuck it – this is not working!
We can’t support a team of 6, journal subscriptions, data, 3rd party services, a full-time employee (whose salary came out of my own), 2 senior corporate attornies on retainer, and bills that totalled over £20’000 on less than $2000 a month!
And so on Monday the 3rd of August I decided to move our entire product to private repositories, the documentation to RTD business, set up the new CI system, and created a new organisation to facilitate clients access.
We will now be moving to an Open-Core business model. I realise that this may look like a spur of the moment thing but the truth is that we have been thinking of a solution to the lack of revenue for months and have devised several plans on how to execute it. Monday was just the straw that broke the camels back.
Lesson 7: Build a Community
At this point, I would like to thank a special user and believer (we met on Twitter) who helped us plan the new business model. You provided us with an important paradigm shift and gave us lots of great ideas and inspiration – at a point where we wanted to throw in the towel.
Starting a Slack group where people with a common interest could gather, share papers, and collaborate was one of the better ideas we had. It provided us with an instant feedback loop and led to several product ideas such us our great documentation and tutorial notebooks.
We have received support which included offers to help with fundraising, sponsorship, mentoring, bug fixes, and top academics which helped us implement their techniques.
The open-source platform also allowed us to form a team of individuals, based all over the world, many of us which have never met in person.
Lesson 8: Charge for Additional Products and Services
Adopting the open-core model seems to be one of the best things we ever did, we are on a record-breaking month and it’s only been 4 days since the pivot.
Not charging for a product or service, makes it very hard to measure if you have product/market fit. Without a product that people are willing to pay for, you can’t measure several performance metrics which are important to raise VC funding.
Here is the lesson: If you cant convince 100 people to buy your product after 18 months of hard work, with a team of 6, then you probably have a shit product and should work on something else.
Lesson 9: Don’t Be Afraid of Change
To tell you the honest truth I was terrified of charging users for add ons. I was scared of losing the community, of bad PR, that it was too early to charge.
As a start-up, you are in the business of finding product/market fit and that means you need to test, measure, learn and iterate – a lot. I would say that 95% of users are very supportive of the change with a few that think its cheeky of us to charge money for our work.
That’s ok, you can’t make everyone happy but it is still a good idea to interview those users and find out if there is a new market segment that you had not explored. For us it was the group of users from emerging markets, for them, our new fees were too expensive.
Lesson 10: Believe in your Vision
There are going to be many times when you are going to doubt yourself and if your anything like me, you will reach out to many people for advice, perform a literature review on the topic and then form an opinion before acting.
The problem is that often you will find conflicting points of view or even team members that don’t agree with the direction that you want to take. It’s hard to figure out if an idea is crazy or genius.
The best advice I have here is that you should use the Harvard Business Review as a starting point to guide your decisions, there are some outstanding masterpieces there, and then have the confidence to go in the direction of your dreams.
“And, when you want something, all the universe conspires in helping you to achieve it.”
(The Alchemist by Paulo Coelho)
The Following book by Nadia Eghbal titled: Working in Public: The Making and Maintenance of Open Source Software, is a brilliant book and surprisingly got released a day after we switched to the new model.
It is an insightful read, that closely matches our experience, and should be required reading for anyone starting an open-source project!