This is the first part and I focus here on my approach to initiating the OSS development. The next parts will be more technical and product oriented.
Don’t pretend, be 100% Open Source
People always know when you’re truly honest with them. The same is with Open Source. When you start a Github project as a company, you must be 100% transparent. I think that one of the success factors of Vue Storefront was our very initial decision that we’re making REAL Open-Source software; there is no direct business model backing Vue Storefront. You’d say: it’s PR or just marketing? Of course, it is — but I feel it’s more like our contribution to the community. We don’t like to have a second enterprise license. Just the MIT license — the most liberal Open-Source license you can find. And the contributors really appreciated it. Vue Storefront is the property of each of our 80+ contributors — we literally can’t change the license without their permission.
It’s tempting to monetize this effort — Vue Storefront development, as a monthly cost, is pretty significant — even for Divante (we’re a 170-strong company). But it’s also a cost for the contributors and our partners — they’re spending a really significant number of hours working on the project. If you want to have their engagement, they MUST feel that they’re part of your project, that this project is THEIRS. I think it’s extremely difficult to have this feeling when you’re starting your project behind the closed doors, keeping just the core team in charge or using the enterprise model.
Nobody likes to feel abused, or feel like you’re earning money from their efforts without giving back.
Be inclusive to your community
At the very beginning, we didn’t have any strict rules for Pull Requests (now we have few quality-oriented rules — to help the contributors pass the Code Review process). We were just … open. Moreover, we spent a lot of time on Slack — answering questions (we still do). I’m spending about 1–2h daily chatting on Slack and providing help on Github Issues and pull requests.
As simple as that — spend time with people, appreciate their contributions, do Code Reviews, provide feedback, help them fix their code if necessary. Invest in the Vue Storefront community.
By doing so we gathered around 80+ contributors — about 10 in the core team. I see that helping is building — the people that got some answers from the core team are now providing support to newcomers on Slack and this is just growing :)
Release early, release often
We have a monthly release cycle in Vue Storefront. It’s very strict: this is our promise to the community — the next version will be in a month. But we do not necessarily promise any particular features to be included (as we only include the features that are ready and which pass Quality Checks). Each release is a marketing tube — you can create a blog post, people have a reason to share and spread the news about your project.
When you feel you’re ready — it’s too late!
Richard Branson once famously said that “If you feel you’re ready — it’s too late”. I was always a fan of the lean approach. We started the Github repository from day zero and were pushing hard to have an MVP (in our case: home page, product page, checkout) ready to use. Limiting all other features, not spending too much time on dev-ops, automated tests (now I know that was a mistake in some sense ;) ). By doing so, we’ve outpaced other similar projects and we were ready for the implementation one full year before the others. You can read more on this be-first-on-the-market strategy in the classical book: “Inside the Tornado”. By being first, you can also very quickly validate your idea and pivot. It makes little sense to invest a lot into a project which .. nobody needs.
Sometimes I hear that Vue Storefront became popular due to the PWA standard which is very hot now (to be honest, it wasn’t when we started :) ). Some say: “but it was all about fancy Vue.js! And all the hard job on the backend!?? It’s unfair!”.
Well, that’s true. To be successful you should build something that people want, are interested in, which is hot, fancy and has a vibrant community. We’re not Microsoft or Google who have the power to build a new database, operating system or even eCommerce admin panel…. To be successful it’s good to choose the right category you want to be in. The category in which you can win. There is a great book on that: “Escape Velocity”. This “category power” lets your project grow — even if you do a lot of things really, really wrong :)
No Marketing .. or All Marketing?
I have this luck that I like to attend conferences and write blog posts… and I’m technical. But Filip and Kacper from our team are doing the same. Bartek from Snow.dog, who’s also part of our core team, is doing the same too. What’s the rule of thumb here?
Your team is the marketing team. We’re spreading the news very naturally because we love the project. After each event, we receive an extra 20, 50, 100 or even more stars on Github, and new implementations going live. This is how it works. When you’re doing real open source, everybody wants you on the meeting because you’re not selling anything. Of course, we do have a great marketing team at Divante which is doing a great job — organizing events, building partnerships, creating content, etc. I don’t mean that you don’t need a marketing team. But rather, you need your developers’ full engagement in marketing activities. Otherwise, it won’t be vibrant, active and merit-based.
The power of deep work
You might think: “I don’t have time for Open Source”. I was thinking this way too. Day job, family, other duties and literally no time for Open Source. Do you know what? I started Vue Storefront when my second child was on its way (already looking after a 5yr old who is Vue Storefront’s biggest fan). Divante also requested a lot of my attention back then. And I got back to coding. Literally committing.
First I was thinking: maybe as a CTO, I can spend my time in a better way, I can be more productive. But I couldn’t. I think that starting something new, and doing the initial commits and features is really hard. As it was for me as well :) But somebody must just start.
I was able to start this project by just committing 1–2 hours each day, after work (I usually started at 8 pm). By coding in the evenings I had the luxury of deep work (Tom’s using it too). Nobody wanted anything from me and my productivity was skyrocketing. If you read “Getting Real” or “ReWork” by 37 signals, it’s something they’ve written about — to start a new venture in parallel to a current day job; it is low risk, low pressure.
Although each project is different, I am sure that these seven things will help you to start and grow an open-source project. The described approach helped us to stay focused, fast-paced and what’s most important, reliable in the first days of Vue Storefront’s development. Without it, we couldn’t have created Vue Storefront and gathered an impressive community of over 30 official partners, 80 contributors and 800 developers on our slack channel.
Feel free to share your ideas and approach to open-source projects in the comments or @piotrkarwatka.