I'm fine with forks but hard to see @jeffail's marketing/persona of Benthos forked too. It was quirky, to say the least. Difficult line to walk, forking code brings repo docs but it feels insincere reading not on the original.
Congrats on the launch! I can definitely understand the pain point; frequent plan/pricing iteration in the early days always leaves a pile of "grandfathered entitlements" that get carried around.
Two questions.
1) Entitlements seem to permeate systems in few ways (pricing pages & billing systems as you've called out) but also into feature flags systems like LaunchDarkly (my plan offers access to beta feature channel) and authorization systems (RBAC, FGA, etc). Do you see replacing those systems with your SDK or Planship is more of an integrator that helps keep them synchronized?
2) I couldn't tell from glancing through your SDK docs (might have missed it) but do you provide any audit/temporal history? If I store user events in a data warehouse (timestamp, customer_id, action_performed), can I determine a customers plan from that historical timestamp or only their current plan?
I started looking into this but DeleteObject doesn't support these conditional headers on general purpose buckets; only directory buckets (Express Zone One).
> Also note that we have never mentioned anything about cardinality. Because it doesn’t matter - any field can be of any cardinality. Scuba works with raw events and doesn’t pre-aggregate anything, and so cardinality is not an issue.
This is how we end up with very large, very expensive data swamps.
Curious if cuelang just ended up being too much of a hurdle for onboarding. I like it and have used it quite a bit but there's something about the syntax that makes it impenetrable for many.
If a selling point is run from "one file", that's quite difficult to do in python. There are things like pyinstaller but you end up shipping the entire interpreter in the bundle.
As the author of a popular ULID implementation in python[1], the spec has no stewardship anymore. The specification repo[2] has plenty of open issues and no real guidance or communication beyond language implementation authors discussing corner cases and the gaps in the spec. The monotonic functionality is ambiguous (at best), doesn't consider distributed id generation, and is implemented differently per-language [3].
Functionally, UUIDv7 might be the _same_ but the hope would be for a more rigid specification for interoperability.
https://andrew.hawker.io