Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DeepstreamHub: a faster Firebase with an open core

deepstreamhub.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: DeepstreamHub: a faster Firebase with an open core

#11

Post by yasserf »

marknadal wrote: post #6

Competitor here, please don't become an "open core" company - "Open Core" = "Crippleware". Here is my thoughts/arguments around it, dealing with the RethinkDB and Parse shut down as well: https://hackernoon.com/the-implications-of-rethinkdb-and-par... Plus, was invited to speak about it on the Changelog Podcast: https://changelog.com/podcast/236 Please stay truly open :) that way we can still compete. ;) Or else we'l…

co-founder/techie from deepstreamHub here

deepstreamHub literally runs the deepstream.io servers to provide all of the fundamental functionality. All of the client sdks are also Apache 2 based which means that they can be changed in whatever way suits people most, and written in any language.

We also have some really interesting forks by community members that have diverged a bit from how we do things, and has resulted in collaborative forums and in person meetings as well as even talks at meetups about the pros and cons which resulted in the divergence.

The non open aspects are all around the extra services ontop. These all work by hooking into deepstreams plugin architecture, meaning that as stated in following comments, open source plugins are encouraged and are documented in as much detail to help people get started. Offering all the non-core/multi-tenancy/usage monitoring/gui components aspects as open source is in that sense extremely counter intuitive, since we will instead be providing very specific functionality for the purpose of creating another PaaS system. That won't be stopping us from releasing detailed articles/give talks about how things work and run under the hood on AWS and the challenges we met hosting at large scale and across regions, it just means we won't be providing the actual code.

In terms of auto-failover, replication, etc, it would be great if you look at the current open-source aspects on deepstream.io that we have in place for that. deepstream is built with availability and clustering at its core, and its truly because of the involvement of the open-source community that we have managed to make it run in multiple production environments to date.

Re: DeepstreamHub: a faster Firebase with an open core

#12

Post by devmunchies »

marknadal wrote: post #6

Competitor here, please don't become an "open core" company - "Open Core" = "Crippleware". Here is my thoughts/arguments around it, dealing with the RethinkDB and Parse shut down as well: https://hackernoon.com/the-implications-of-rethinkdb-and-par... Plus, was invited to speak about it on the Changelog Podcast: https://changelog.com/podcast/236 Please stay truly open :) that way we can still compete. ;) Or else we'l…

> Or else we'll be the only company that is fully Open Source (replication, auto failover, etc.)

major humble-bragging. In bad taste to do that in an announcement for a "competitor"?

Re: DeepstreamHub: a faster Firebase with an open core

#14

Post by yasserf »

bdamm wrote: post #3

It's great to see so many choices for IoT infrastructure.

co-founder/techie @ deepstreamHub

I completely agree! One of the reasons we started is because we believe we have an interesting way of getting devices of all types ( IoT / browsers / phones.. etc ) talking together to generate new ways of displaying and moving data.

At the end of the day the selection of choices such as the eclipse iot project https://projects.eclipse.org/projects/iot, https://relayr.io/, aws IoT gateways, (shameless plug) deepstream.io and many others allow developers to stop having to think about how to get devices to communicate, but instead think about what they want it to do. I'm slightly overly passionate about this because my bachelor project a decade ago was around smart homes and I spent the majority of the time trying to get protocols to collaborate happily, where now that's just considered part of boiler plate setup! Really excited to see the potential outcome due to this general movement.

Re: DeepstreamHub: a faster Firebase with an open core

#15

Post by marknadal »

yasserf wrote: post #11
marknadal wrote: post #6

Competitor here, please don't become an "open core" company - "Open Core" = "Crippleware". Here is my thoughts/arguments around it, dealing with the RethinkDB and Parse shut down as well: https://hackernoon.com/the-implications-of-rethinkdb-and-par... Plus, was invited to speak about it on the Changelog Podcast: https://changelog.com/podcast/236 Please stay truly open :) that way we can still compete. ;) Or else we'l…

co-founder/techie from deepstreamHub here deepstreamHub literally runs the deepstream.io servers to provide all of the fundamental functionality. All of the client sdks are also Apache 2 based which means that they can be changed in whatever way suits people most, and written in any language. We also have some really interesting forks by community members that have diverged a bit from how we do things, and has result…

Great reply, thanks! I love the honesty, integrity, and openness.

Would you be willing to call it "open source with premium hosted services" or something rather than "open core"? I feel like that is more accurate and would be better for marketing, and avoid the whole "open core / crippleware" debacle (see the other comments about InfluxDB). Just my 2 cents!

Cheers! (Thanks for the reply)

Re: DeepstreamHub: a faster Firebase with an open core

#16

Post by marknadal »

eloff wrote: post #10
marknadal wrote: post #6

Competitor here, please don't become an "open core" company - "Open Core" = "Crippleware". Here is my thoughts/arguments around it, dealing with the RethinkDB and Parse shut down as well: https://hackernoon.com/the-implications-of-rethinkdb-and-par... Plus, was invited to speak about it on the Changelog Podcast: https://changelog.com/podcast/236 Please stay truly open :) that way we can still compete. ;) Or else we'l…

Leaving aside how odd it is to see a "competitor" give business model advice, open core is a perfectly fine open-source business model. Pure support based models, with very few exceptions, leave too much % of value on the table to make a strong business. Purely closed models take away too many freedoms from the customer (but can be very successful nonetheless.) Open core is a very reasonable compromise. The problem w…

The economics are inevitable, any proprietary or crippleware system will be beaten by fully open alternatives. And over time, those fully open systems will have more collaborators and more contributors and more users.

And @yasserf's reply was fantastic, too. Sounds like they are more providing premium hosted services than anything else, which I think is definitely a good way to go.

Re: DeepstreamHub: a faster Firebase with an open core

#17

Post by wolframhempel »

Sujan wrote: post #2

What exactly can be replaced with DeepstreamHub if your are using Firebase right now?

deepstreamHub's records can be used instead of Firebase's realtime db/data-sync part, deepstream's events are a replacement for their lately added PubSub capabilities. deepstreamHub does request response as well while Firebase offers integration with numerous Google services.

The core differences are in the way deepstreamHub structures its data (small, related documents with independent lifecycles rather than one big data tree), its speed and open core

Re: DeepstreamHub: a faster Firebase with an open core

#19

Post by marknadal »

devmunchies wrote: post #12
marknadal wrote: post #6

Competitor here, please don't become an "open core" company - "Open Core" = "Crippleware". Here is my thoughts/arguments around it, dealing with the RethinkDB and Parse shut down as well: https://hackernoon.com/the-implications-of-rethinkdb-and-par... Plus, was invited to speak about it on the Changelog Podcast: https://changelog.com/podcast/236 Please stay truly open :) that way we can still compete. ;) Or else we'l…

> Or else we'll be the only company that is fully Open Source (replication, auto failover, etc.) major humble-bragging. In bad taste to do that in an announcement for a "competitor"?

That is a sad way to spin it :( but being strongly values-focused is a good thing not a bad thing, and inviting open discussion with competitors improves both systems, not diminishes it. Silencing discussion hinders progress.
Post reply on HN