3 ms·

Disclosure: I used to work on Google Cloud. I see a lot of similarities between Kafka and Confluent. You're looking to spin out a tool that worked well for you

by boulos 5y ago

Disclosure: I used to work on Google Cloud. I see a lot of similarities between Kafka and Confluent. You're looking to spin out a tool that worked well for you, and offer it commercially. I'd suggest planning more around operating TiloDB as a managed service. You happen to just need lambda, s3, and dynamo today, but the "capturable" value for many customers will be if you also manage it all for them (especially upgrades). You can still offer the open core and let folks run their own, but it sounds like a lot of the goodness comes from the way you run it. Having said that, licensing is currently fraught in this space. Each major "database" vendor (Elastic, Redis Labs, Confluent) is basically trying to find a way to figure out how to avoid AWS (and other clouds) from just taking their code and operating it as a service. People have very strong opinions on this topic, ranging from "open-source isn't a business plan" to "AWS is violating the spirit of the OSS community" and many more. My personal advice would be to assess more clearly why you want to be open source (you mentioned community and applications you couldn't imagine) and whether you think open source better achieves those goals than say a free tier or distributing a core binary / container image for free. What, more specifically, do you want to get out of being open source? Contributions to the core? Contributions to the operational part? More users and feedback?

Major_Grooves 5y ago
you make a very good point. In fact, we just came out of a call with a very knowledgable investor who wants us to go down exactly that route. It could very well be that the managed service route is the way to go. Thanks for the comment. If you'd like to connect directly, I think my email address is in my profile. re OSS strategy - it's more users and feedback that I firstly think of. For instance, people keep telling us that there could be a really great use case in crypto compliance/auditing - tracking related wallet addresses etc. We don't really know enough about blockchain to validate that, but I think an OSS community could.
- smackeyacky 5y ago
  I think what you might want to do is try the closed source / SAAS route first either by locking in that 2nd customer or taking some investment. If it doesn't work, then start down the open source route. It seems to me that all the knowledge / experience of your staff is your real asset here, not necessarily the code. While that, in theory, should mean open-sourcing the code won't matter for your business, in practice it means you will be seeding competitors unnecessarily. Turning your staff into highly chargeable consultants could be a more sustainable business model than trying to herd the cats of the internet into trying to improve your product offering, when most of those guys won't have the experience of your existing team. By offering the code out as open source you are giving a bunch of people a leg up and cutting short your time as the only game in town, which puts extra pressure on sales and might not work out.

by boulos 5y ago

Major_Grooves 5y ago

you make a very good point. In fact, we just came out of a call with a very knowledgable investor who wants us to go down exactly that route. It could very well be that the managed service route is the way to go. Thanks for the comment. If you'd like to connect directly, I think my email address is in my profile. re OSS strategy - it's more users and feedback that I firstly think of. For instance, people keep telling us that there could be a really great use case in crypto compliance/auditing - tracking related wallet addresses etc. We don't really know enough about blockchain to validate that, but I think an OSS community could.

smackeyacky 5y ago
I think what you might want to do is try the closed source / SAAS route first either by locking in that 2nd customer or taking some investment. If it doesn't work, then start down the open source route. It seems to me that all the knowledge / experience of your staff is your real asset here, not necessarily the code. While that, in theory, should mean open-sourcing the code won't matter for your business, in practice it means you will be seeding competitors unnecessarily. Turning your staff into highly chargeable consultants could be a more sustainable business model than trying to herd the cats of the internet into trying to improve your product offering, when most of those guys won't have the experience of your existing team. By offering the code out as open source you are giving a bunch of people a leg up and cutting short your time as the only game in town, which puts extra pressure on sales and might not work out.