How We're Building a Business to Last | Hacker News Reader

How We're Building a Business to Last

cockroachlabs.com

86 pointstosh57 comments

I wonder if we will eventually see open source projects getting a fair cut from cloud vendors. For example, with AWS both their cache offerings are built on open source (redis and memcached), many of their DB offerings (Aurora and RDS versions of MySQL and Postgres) etc.

It seems like giving a meager cut back to these companies could go a long way, rather than forcing them to compete with added features on their own SaaS offerings.

I wonder if this could be done via licensing, i.e a commercial license that only kicks in when you offer the project as a service.

Does anyone know of anything being done like this?

License Zero [https://licensezero.com] is working on a means of doing this. I believe they are starting with NPM modules first.

> starting with NPM modules first.

Creators of left-pad about to become millionaires off the backs of lazy devs everywhere.

> I wonder if this could be done via licensing, i.e a commercial license that only kicks in when you offer the project as a service.

The AGPL can be used this way. The project is free and open source, but people wanting to sell it as a service will pay for a commercial license instead of using the AGPL.

Only if they want to modify it and not give back. If people want to use the code as is AGPL doesn't really help.

And from the outside, it's nigh impossible to know if the source code for a hosted open-source product has been modified or not, unless they make it blatantly obvious, which makes the AGPL extremely difficult to enforce. In addition, a lot of great hosted open-source products are designed to be extensible through plugin architectures so that its functionality can be extended through code that lives outside of the core codebase, and AGPL can introduce a perverse incentive to close off the product for extension to the detriment of the quality of the code base and the experience of end-users, in the name of not circumventing the protections provided by AGPL.

That said, AGPL is still my go-to license to reach for when I build open-source products that can be self-hosted, but it's by no means a silver bullet, even for its intended purpose.

People understand what the AGPL requires. And for projects where there are alternatives with other license terms, like MIT or Apache2, the alternatives will be used. Adoption is stymied

> features necessary for a startup to succeed will be APL, and part of the open core; a feature which is primarily useful only to an already successful company will be CCL, and part of the enterprise product.

This sounds like an excellent guiding principle to strive for in an open-core development model. There's definitely still a fine line to walk to determine how to apply that principle to each new feature, but it's encouraging to see that they've at least put enough thought to arrive at a reasonable-sounding compromise to hold themselves to.

I personally still vastly prefer to use and build products that are entirely open, funded through hosted SaaS services and support contracts, but that model definitely doesn't fit very well for infrastructure products like databases where a very significant portion of the user base would prefer to self host.

And speaking as a pragmatist, if a open-core product's paid features genuinely only become useful once a product reaches a scale where licensing costs become insignificant relative to the revenue generated by the product, and the source code for those paid features are readily available to be inspected and extended, then as far as I'm concerned it's as good as any fully open-source alternative from a licensing perspective.

I'd much rather see companies use a open-core model like this that makes reasonable compromises in order to sustain their business rather than close off their product entirely. This is especially important for core infrastructure products like databases, where the difference between open-core and fully proprietary often means the difference between a product worthy of a cautious evaluation and one that's simply a non-option for many developers, myself included. And that's always a shame because there are some very promising proprietary products like this that I simply refuse to consider using in a early stage product due to feature/scaling/deployment/licensing restrictions (Datomic being the one that's always lingering in the back of my mind).

Seeing the fall of RethinkDB followed by the death of Basho is not an encouraging sign for the industry, however my personal gut feeling is that if they deliver what they promise, there is definitely room in the game for them.

Is Basho dead?

Sadly, it is. HN discussion from 11 days ago: https://news.ycombinator.com/item?id=15182566

> In 2017, Basho was put into receivership.

https://en.wikipedia.org/wiki/Basho_Technologies

Cockroach in context of resiliency towards Nuclear impact is a great name for this DB. But it doesn't sound serious.

Do you think it sounds less serious than MongoDB?

I'm under the impression that this name based aversion is only existing among English native speaking people. Here on the other side of the fence, even if some do know what a cockroach is, I see no gut reactions (but I'm only a single data point).

I can say for sure it's not just for English speaking people.

Rather, I'm actually curious why you think some cultures may even think that cockroaches are OK.

Cockroaches are universally considered as pests all over the world because they ARE pests, that's how they survive. Look up wikipedia to learn more about cockroaches. They have an entire section describing the relationship between humans and cockroaches, mostly about them being a pest.

I read bpizzi's post as saying that, for non-native English speakers, the name doesn't trigger the same aversion because the mental connection between the English name and memories of the bugs is weaker, since we grew up calling them something else. At least that's the case for me, as a non-native English speaker myself.

I thought the same thing. I like it, but my company's IT director will never allow it. Maybe they want to target the startups and couldn't care less about the old school companies...no idea.

A company basing the choice of its tools on their name deserves to go out of business.

But a company that ignores marketing actually will go out of business.

This seems to imply CockroachDB's name would be ignoring/bad marketing? I think it's fine. I see a lot of people saying something along the lines of "if it had a different name I would have looked at it earlier" but honestly I think if it was really named differently with a less remarkable name they would not have noticed it in the first place.

You can see lots of people in this thread alone saying they have an instinctive, visceral negative reaction to the name. If you think that's good marketing, I don't really know what to say...

More so, no large company with Oracle & Postgres & mission critical applications serving the nation will go, let's switch to this cockroach thing...it would have to reach critical mass first

Previous discussion from January https://news.ycombinator.com/item?id=13438476

Congrats and definitely it's for the long game. Changing infrastructure is a hard thing to convince revenue generating companies to do, as they aren't as price sensitive. It'll take years to grow the product to the point where it reaches enough word of mouth recommendations to be considered the first choice. That or you have some killer feature that everyone has got to have.

Suggestion : smaller cockroaches belong to the family Ectobiidae.

How about EctoDB ?

(I actually love the name CockroachDB but it seems to be an intractable problem for some!)

I like the name but there's potential for confusion with Ecto[1]

[1] https://github.com/elixir-ecto/ecto

Dagnabit, we're running out of words!

Well, all Cockroaches belong to the order Blattodea... but BlattoDB conjures the wrong feelings.

I'm sure these have been offered before, inspiration from nature:

TardigraDB (Water bears)

EchinoDB (starfish)

Morphallaxis

BorgDB (OK, that one is Star Trek!)

By making the association with cockroaches so explicit, they're placing a bet:

  *People will change their perceptions and "cockroach" will assume a new meaning. Instead of "something disgusting and negative", people will associate the word with "something resilient and positive".*

It's a tough bet to place. We've been around cockroaches for millions of years, and the roots of the disgust are deeply biological (HW, not just SW).

Will the masses shift their mental model, for this company?

I was hoping they'd choose DBaaS. But I get it. How do you really compete when you'd ultimately probably have to run your operation on cloud providers' infrastructure.

The "open core" model in open source has always felt like a "poor man's acquihire" to me.

I just wish it had a better name like ResilientDB.

Agree. I actually have a phobia about cockroaches that manifests itself in a physical reaction when I encounter them. That has been a huge factor in me avoiding checking them out, as even seeing their icon graphic in the header gives me a visceral reaction. I'm sure it is a great DB, but the branding doesn't make me want to visit any time soon.

One of thr best racecar mechanics Ive known also shares the same phobia. His shop was squeaky clean and no food was allowed under any circumstance. It kept the pest problem under control. I never understood it until I saw his reaction to seeing one of the little buggers. Just awful.

Agreed. I actually didn't give it much attention for the longest time simply because of the name (I'm talking years - just checked it out a few months ago although I heard of it probably a couple years ago). Now that I've taken the time to check out the project, I'm sold and will definitely use it in place of Postgres, etc. But, the name does turn off some newbies. Eventually it may not matter as all good brands eventually just become familiar.

One of the reasons I'm put off by their name is because I know that they know a lot of people don't like the name. Them knowing this AND keeping at it means they don't care about losing out on tons of users because of this trivial matter, which means they are not being professional. When it comes to something like a database system, I want to use something that's built by a professional team.

When I say they don't feel professional I don't mean their tech is unprofessional. In fact I'm sure their tech is excellent and that's why they're so confident enough to keep at this name. But what I'm saying is I don't believe that the executives or whoever is in charge of the business is reliable enough to keep the business stable.

I don't know about you, but I don't feel comfortable buying a piece of enterprise software or service from a company whose CEO thinks it's OK to have a brand name that turns off tons of users and don't care.

turns off idiots, sure, I honestly can't believe the stupidity of these bikeshed comments.

That's not how bikeshedding works

Instead of discussing the merits of the business model, or technology, they are discussing what it is called, because it is easier.

It is not bikeshedding in the traditional sense, but the spirit is the same.

With that reasoning, every single discussion thread that contains criticism is bikeshedding.

Bikeshedding is for people who care about a project in one way or another. In their mind they're contributing because they're providing feedback, but overall they're just wasting time because their "work" is far from significant, which means they are not really achieving what they think they're achieving.

In this case most people who complain about their name are not their users. Some actually do want to be excited about their tech and want to be their users but they are not. Which means none of these have any intention of trying to make this project better. I am not their employee nor their shareholder. Why should I care about them?

"Bikeshedding" only applies to people who have stakes in a project or care about the success of the project because they are foolishly wasting time on something that doesn't matter when they actually think they are contributing.

This is not the case in this case. I do not care about cockroachdb and I am not trying to contribute to their success. I just bitch about it because i think it's a stupid decision. This is not bikeshedding.

It's like criticizing the hairstyle of your doctor. Do you complain when users report 'bugs' to you too?

My first reaction when I heard that name was to think - 'must be designed to be hard to kill'.

If I went to a dentist and he had a mohawk with pink hair, I would be concerned. And that's how most people react too. I'm not a fan of dressing up which is why I can't imagine myself working at a wall street firm, but at the same time it's arrogant to think that you can beat everyone else even when you are clearly exhibiting a behavior some people find repulsive.

If there was another dentist with exactly the same skills both technically and socially, there is no reason for patients to go to the guy with pink mohawk.

The name is a crucial part of the brand, which itself is the core of the business. That's what Im discussing. I understand if you disagree, but the discussion has merit based on facts.

Some names generate negative brand equity, which I feel is the case here. It would be simple to verify with an a/b test.

I know it sounds like I'm being an ass, but this comes from my desire to see them succeed.

On one hand the name had put me off from wanting to look at it when I first heard about it. But at the same time, it's also the reason I looked, since DB technologies are a dime-a-dozen these days with generic sounding names.

I would still prefer another name though.

I expect it will conjure an unpleasant instinctive response for a long time.

I think it’s fine. It kind of says “we are geeks that don’t give a shit about marketing”. It makes me trust them.

But on the other hand I am one of the guys who find the Postgres name ugly and boring, so don’t trust me :)

You have to give a shit about marketing to build a business to last, though.

Are you in a position to purchase their product? If so, at what scale?

Cockroaches are vermin, it absolutely has a negative connotation, geek or not.

> I think it’s fine. It kind of says “we are geeks that don’t give a shit about marketing”. It makes me trust them.

It kinds of says "we are geeks that don't give a fuck about looking professional". It doesn't make me trust them nor want to try their product.

This has been my gripe with MongoDB for years now. It's a negative word in various languages[1] and has a racist history in German[2].

[1] https://en.wiktionary.org/wiki/mongo and https://en.wiktionary.org/wiki/Mongo

[2] https://en.wiktionary.org/wiki/Mongo#Etymology

I'm actually quite happy with the name. For me - cockroaches are bugs that are distributed and survive in harsh conditions - something you want out of a database.

Presumably the name won't last beyond their first encounter with a marketing company. It's not just a nasty insect--it's one the nastiest of them all, and universally recognized as such. Sure, it sort-of makes sense, in that cockroaches are supposed to survive nuclear war, or whatever, but still...

Also, the ironic/flip attitude towards having a deliberately bad name has been done before.

https://simpsonswiki.com/wiki/Stinking_Fish_Realty

Stubbornly and childishly keeping a name that is revolting is not what I'd call 'building a business to last'.

The name is instinctively disgusting. I will never recommend this product to any of my clients for that reason alone.

And I am sure that they are very happy to not have you or your clients as customers. Anyone who would base a technical decision on a name should never be in a position to influence technical decision-making, and anyone who hires such unqualified people deserves the bad advice they will receive.

Sorry, but technical decisions also need to be based on trust, and a company that chooses a name like this is not a shining example of trust. But we're not going to see eye to eye on this, so let's end it here without anymore personal insults.

That's all well and nice, but we're currently not living in a world that will last. We're on the brink of some huge changes: oil getting replaced as main resource, AI becoming more and more able to really help making business & political decisions, space flight becoming affordable, the big players on the planet increasing their military and trying to buy each others valuable corps and resources.

Even the biggest companies are more and more moving to flexible business models, not really being anything like what the label says outside on the door. Just think about banks. Once the most stable institutions in the world, now not sure what they are. But everybody knows they need to adapt in some way if they want to stay relevant.

Trump, Putin, Xi, all people you better don't mess with. All people who are totally willing to mess with others. What happens when they start to mess with each other? And maybe that just has symbolic value, but next week the German government is re-elected, and the Nazis will get 10% of the parliament seats.

Nobody knows what the world will look like in 10 or 20 years. How can you build something to last that is not a few hundred meters underneath a huge mountain and self sufficient?

Yes, the world is changing and there's a lot that's uncertain. However, this is really over the top and has little to do with the submission per se. Do you have anything specific and constructive regarding the post? Strategies they should be using to build their business? Say what you want about their business strategy. At least it's an ethos.

I don't know if this fallacy has a name, but many people have it. In many situations the goal itself must be adapted according to the environment, in this case attempting to build a business to last is the mistake. The smarter way is to not have a company and let others worry about it, or to build a company to grow quickly, so that it can take a newly formed space quickly.

Reply on news.ycombinator.com