> Hmm why do they need to raise so much cash every 9 months?
Well, they say the best time to take investment is when you don't need it. If you wait until you need it then the terms will be worse. If investors are offering you money when you don't need it, it may be the best time to accept it.
The sequence of raises here look like a fairly normal sequence for a growing startup, except that they happened much closer together than would be typical. The terms aren't shown but assuming they are in line with a typical sequence then this is a great outcome for buf as it gives them lots of room to build their vision without needing to stress over money for a while.
> Also does anyone here use them and have any thoughts about their product?
FWIW, long ago I was the maintainer of Protobuf at Google, including putting together the first open source release. I like what buf is doing -- enough that, full disclosure, I made an angel investment in their seed round.
There's a huge amount of room for better tooling around Protobuf. Binary and strongly-typed protocols require strong tooling to be usable, but with tooling they can be much better than dynamic and text-based approaches. Like, the fact that the protocol is binary shouldn't make it any harder for a human to read it, because your tools should decode it for you on-demand as easily as you could `cat` a text file. Protobuf historically has had sort of the bare minimum tooling and required a lot of ad hoc copying proto files around between projects to get anywhere, which was a pain. A registry seems like the right first step to making things easier, but I'm really excited about what can be done after that... once you have strong type information, you can have tools to dynamically explore APIs, trace communications, etc.
> FWIW, long ago I was the maintainer of Protobuf at Google, including putting together the first open source release. I like what buf is doing -- enough that, full disclosure, I made an angel investment in their seed round.
I know this might not be the best way to ask but have they considered creating proto rules for Bazel? The existing proto + gRPC story is pretty unfortunate.
Huh. As the person who literally implemented the original proto_library rule in Blaze (which was later publicly released as "Bazel"), I'm a bit surprised to learn this doesn't work well today... but admittedly I haven't had the opportunity to try Bazel since the public release. What is the story today?
`proto_library` for building the `.bin` file from protos works great. Generating stubs/messages for "all" languages does not. Each language does not want to implement gRPC rules, the gRPC team does not want to implement rules for each language. Sort of a deadlock situation. For example:
But there's also no real cohesion within the community. The biggest effort to date has been in https://github.com/stackb/rules_proto which integrates with gazelle.
tl;dr: Low alignment results in diverging implementations that are complicated to understand for newcomers. Buff's approach is much more appealing as it's a "this is the one way to do the right thing" and having it just work by detecting `proto_library` and doing all of the linting/registry stuff automagically in CI would be fantastic.
I don't even know why they need so much money for what they do.
Based on their website, they solve the following problems:
- a central schema registery. Even if that's something you actually want, it's not a problem that requires $93M to solve, or a commercial company to operate
- communicating schema changes primarily via human-oriented sources like handwritten documentation on emails. I mean sure, if you are a masochist (or a sufficiently inefficient org), you might do just that. The rest of us here in the 21st century can check the schema into a Git repo instead.
- schema drift on the client end. Tough, this is what happens when you write software. Adding a third party won't help here.
- dependency management. For APIs? I cannot imagine a single case where that would help and your API isn't already a monstrosity.
Hmm well I get that we're in an asset bubble with startups, but if this company is creating jobs, then I think it's somewhat reasonable to assume that they are fixing a problem ppl are willing to pay for.
I do agree with what you're saying from my perspective as an average swe that doesn't do anything highly specialized...
I wonder though, what would the workflows look like for a swe, product, ops person even, where schema changes get passed around and edited so much, (kind of making some assumptions here, comparing central schema registry to crm use cases), that this would be necessary...
Wonder what the shape of the problem looks like...
Well, they say the best time to take investment is when you don't need it. If you wait until you need it then the terms will be worse. If investors are offering you money when you don't need it, it may be the best time to accept it.
The sequence of raises here look like a fairly normal sequence for a growing startup, except that they happened much closer together than would be typical. The terms aren't shown but assuming they are in line with a typical sequence then this is a great outcome for buf as it gives them lots of room to build their vision without needing to stress over money for a while.
> Also does anyone here use them and have any thoughts about their product?
FWIW, long ago I was the maintainer of Protobuf at Google, including putting together the first open source release. I like what buf is doing -- enough that, full disclosure, I made an angel investment in their seed round.
There's a huge amount of room for better tooling around Protobuf. Binary and strongly-typed protocols require strong tooling to be usable, but with tooling they can be much better than dynamic and text-based approaches. Like, the fact that the protocol is binary shouldn't make it any harder for a human to read it, because your tools should decode it for you on-demand as easily as you could `cat` a text file. Protobuf historically has had sort of the bare minimum tooling and required a lot of ad hoc copying proto files around between projects to get anywhere, which was a pain. A registry seems like the right first step to making things easier, but I'm really excited about what can be done after that... once you have strong type information, you can have tools to dynamically explore APIs, trace communications, etc.