891 karma · joined October 26, 2018
YC Badge: 0xbc8ab4e5946921011969e4c6888202609b5b5a38
You are correct - haven’t actually done this yet since we’ve had no chance to so don’t take too much from this policy until we’ve done it a few times!
We set up hedgehog.vc which is what we’d use to fund ex employees if you’re curious.
There are three established ways to make money from open source if you're thinking about this.. my default recommendation would be the exact model Plausible uses today - (3) below, if you are just getting started and either bootstrapped or VC backed in today's funding environment.
1. paid support
Advantages: (i) no need to build any extra features or set up hosting for your customers up front - low risk of wasting time in case you don't get product market fit with your paid product (ii) probably a good way to get close to users, as long as you don't end up over-fitting to 1 or 2 edge case use cases (who are, likely, those most likely to need paid support) - however, this will happen naturally if you set up a slack/discord community and you help people out for free
Disadvantages: (i) you are no longer a builder, so you're not doing 100% leveraged work, so the margins are slimmer (ii) will take some time to get to revenue because you will need a reasonably popular project to get much demand (iii) this will be hard to fund if you want to do the VC route, there are exceptions though
2. extra, paid self-hosted features
description: you have an open source project, and users can buy premium features on top for a fee of some kind
Advantages: (i if you target enterprises who don't want to send data outside their environment who don't want to buy closed source SAAS products - they can try + buy much your product faster than your competition's
Disadvantages: (i) it's hard to avoid customers expecting support managing the instance (just because they're paying you, even though you "just" sold extra features) (ii) you have to build a lot since you need an open source product and a paid product on top - so it needs a lot of investment to do this without hurting the open source project's value (I'd strongly recommend you get VC if you do this option, as you'll probably find bigger order values but slower sales cycles as well as all the building work) (iii) many people think everyone is moving to cloud, but we've seen there is a ton of underserved market here (more than enough to get to $100M+ revenue in our market at least), and increasing legislation around user privacy is keeping pressure on here
3. paid hosting of the project
description: you have an open source project, and users can pay you to host it for them
If you are bootstrapping or even VC backed in today's funding environment, I'd recommend defaulting to open source project _and_ a cloud hosted version as your paid version, unless there's a good reason not to.
Advantages: (i) this is the fastest way to monetize (ii) for users without self hosting needs, this is likely a better user experience - less work to manage, so you may just grow a lot quicker initially
Disadvantages: (i) you need to manage the hosted version (ii) at a product level, you are potentially competing head on with closed source SAAS
Respectfully disagree - I don't think competitors copying is a significant risk early on, compared to running out of money whilst trying to hit product market fit.
Thanks HN: I'm James - I'm a cofounder of PostHog (popular open source project), which was born on HackerNews in 2020
Along the way, we created a Slack group that quickly grew to a couple of thousand users - mostly needing support with the product. At the same time, we saw signs that docs are critical. For example, people who searched our docs are 8x as likely to succeed with our product.
Then we asked ourselves - why not make it possible to ask questions, right in our docs?
Out of 100s of thousands of visitors, only a small percentage make it into Slack (and it'd be the same if we used Discord), so can we serve questions and answers in the context of what they're trying to do. As a bonus, this would also make everything searchable.
Then we asked ourselves - why not also make this open source for anyone to use?
This means that far more people can benefit, and it'll generate word of mouth growth about who we are - hopefully bringing some extra customers in the long run. Simple as that. We may charge if we get lots of usage and once the product is more mature for the cloud version. If it's not popular, we're going to be using and extending it ourselves anyway :)
You just write a few lines of TypeScript in the platform (avg LOC is something like 80) - see https://posthog.com/docs/plugins/build. There are a bunch prebuilt too.
Disclaimer: I work there
That said, if someone just sends me (I'm cofounder, post series B startup) an email directly which is well thought out connecting your skills with what we're working on, I will 100% read it / consider it. This ticks a box that you're interested in what we're working on - which we need to feel to hire you.
I do not now look at the vast majority of submissions, since the vast majority of those are generic, so we have a full time recruiter looking through.
We're an open source platform for product analytics that took off after a launch HN (https://news.ycombinator.com/item?id=22376732). Our mission is to increase the number of successful products in the world. We've raised nearly $30M since that post under 2 years ago, and have around 15K developers in our community.
There are two key roles open at the moment:
* A developer who likes to speak to customers. We are getting swamped dealing with inbound demand and are growing revenue by 50% month over month. I need our very first customer success manager - to help get customers what they need, and to ensure they're deployed and configured. This isn't a support ticket role, it's about making sure our customers, who are usually very technical, are successful, including (inbound) sales. We could see this fitting an ex-founder really well, but we're open. Our vision for customer success is a strong focus on tooling, documentation and automation, not on building a huge team. Above everything, you need to be proactive, smart, able to help solve technical problems, empathetic and someone that enjoys building relationships.
* A developer who loves writing - especially tutorial type content, and could own this for us. We've got lots of docs that detail what the product does, but we want to focus on explaining how to build a more successful product, and how PostHog can help achieve those. You might be writing about how to use our SDKs one day, or how to improve activation rates another. Bonus points for a data engineering background.
What it's like:
* Fast and direct! * Focus is on written and asynchronous communication. * Autonomous. You choose your quest. Small team structure to enable this. * Transparent - almost all our work is open source, public handbook, public compensation, internally shared board meetings and investment updates before they happen.
Learn more about working here at https://posthog.com/careers
Email me and links to any relevant online profile personally - james@posthog.com, and cc in careers@posthog.com.
That's not super helpful if you've not already done that:
* Real life groups were pretty helpful. You can't go to these aiming to sell, but if you go aiming to learn and genuinely just get advice, they work well. * LinkedIn was pretty good, looking for people that I knew through others and asking them really nicely if I could talk about something we wanted to build. When we had better ideas that solved pain points they had, that were more unique, the response rate was much higher. This doesn't work well for "recruiter-saturated" user profiles like developers, who just ignore a lot of what goes on there.
The MVPs weren't that bad - they'd work smoothly on the things that were new and special BUT they often totally lacked core functionality. We built with django so we could use django admin to do things like add users/change passwords.
We think the future for open source is offering private cloud, where we have some sort of control pane to manage upgrades without needing access to your data. That's a win for privacy reasons but mean we don't have to go at the pace of our users with the least powerful on premise servers.
I think this is a correlation not a causation thing. Specifically, open source is a great place to put hobby or WIP projects - SaaS isn't, you wouldn't want to pay for others to use your stuff for free. Certainly, historically, your point is valid - SaaS has benefitted hugely thus far, but I think it seems rational this starts to change.
Open core feels like it has the advantage of the source-only approach yet also enables a community to use a free product on top, generating faster growth and user trust and feedback, all of which are harder to create with SAAS. The downside? You have to build two products. At least for those willing to do the VC route (not for everyone), it is possible to get funding to do this.
Disclaimer: I am a co-founder of a VC-backed open core company!
We're building an open source product experimentation platform.
YC-backed, and have raised a huge amount of unannounced funding in the last few days due to crazy traction on launching on HN in Feb. Thousands of stars in the repo from 0 back in January this year.
Your daily work would be open source.
Get feedback from developers around the world using your stuff.
Fully remote, asynchronous, we write stuff down, transparent by default and we focus on autonomy.
https://posthog.com/careers to get our email addresses
If you are intelligent, ship fast and have a couple of cool side projects, have experience in a huge tech company OR are an ex founder, you could be a great fit.
A few thoughts:
As you say, the thing that's really different about us is exactly that we are focussed on engineers not PMs with our tool. PMs are of course welcome to use it too, but it's a little more technical feeling.
We felt the people building the thing should have the context of usage data and this shouldn't only sit in another team - which was a behavior we saw happening quite frequently when we did user interviews early on.
We started with the fundamentals of product analytics with some features we wanted ourselves but are now focussed on features that are much engineering specific. For example, we are about to release (an optional) "inspect element" for usage data: https://github.com/PostHog/posthog/issues/870, so you can pop that up whilst working on localhost.
We had no idea if that hypothesis was correct - that engineers would care. We did a launch HN to find out and got quite a lot of good feedback and growth.
Re scaling, you are spot on - this is definitely hard! We have users doing 5 million events/day on Heroku's cheapest standard tier dyno. We offer paid support for people who need something higher volume still if it doesn't work well out of the box. We're working on supporting databases other than Postgres as people need them.