jonathannorris

Yeah, hard disagree on that one, based on recent surveys, 80-90% of developers globally use IDEs over CLIs for their day-to-day work.

I was pretty worried about Cursor's business until they launched their Composer 1 model, which is fine-tuned to work amazingly well in their IDE. It's significantly faster than using any other model, and it's clearly fine-tuned for the type of work people use Cursor for. They are also clearly charging a premium for it and making a healthy margin on it, but for how fast + good it's totally worth it.

Composer 1 + now eventually creating an AI native version of GitHub with Graphite, that's a serious business, with a much clearer picture to me how Cursor gets to serious profitability vs the AI labs.

Also, once you are on Enterprise, they will not bug/charge you for contracted overages very often (like once a year) and will forgive significant overages if you resolve them quickly, in my experience.

Pete is a great guy, also on the OpenFeature governance board :)

Happy to provide more details on this. In most cases, our server SDKs use a common WASM library to make all user bucketing and segmentation decisions locally. We have been impressed with the performance we've achieved with WASM. It allows us to share our most critical non-trivial amount of decision-making code, and it lets us share it between our Edge APIs and Server SDKs. So the same WASM code making decisions locally in our server SDKs is also making decisions at the edge for our APIs powering our client-side SDKs and public APIs.

We have stuck to the Bytecode alliance-supported Wasmtime runtimes that we highly recommend for anyone going down a similar path.

There have been cases with highly parallel environments where we needed to support micro-second level optimizations for our GO SDK, where we ended up building a native version of our bucketing logic. We hope that WASMs' upcoming threading and memory management improvements will make this use case supportable without needing native code. But for our higher-level language SDKs like NodeJS / Python / Ruby / PHP we've generally seen as good or better execution performance from WASM.

What desktop environment are you looking to support? We have customers using our iOS SDK in MacOS (we need to find a better name for our Apple platforms SDK that supports iOS / iPadOS / MacOS / WatchOS / tvOS). Our React SDK works with electron apps, and we have on our roadmap to investigate client SDK support for our .NET SDK.

We certainly see workflows where defining everything as code can be powerful. As we've been chatting about this internally today, we have ideas of how you could define all your features / audiences / variables as code and only deploy changes using a Terraform interface.

I feel like, ultimately, this overly limits the reach of feature flags within an organization; it makes it more difficult for most engineers who are not comfortable with Terraform to deploy their features; it limits the ability of product / marketing / project managers / QA from; scheduling releases, configuring experiments, testing features, modifying audiences, etc.

Modifying configurations certainly can cause production issues, which is why we have built tools like our variable schemas and strong typings for our variables to limit the value changes to only known values. With our CI / CLI / IDE integrations, we make it known what values variables can be set to, when variables are added and removed, and when variables enabled in production are modified by PRs. This is all in addition to existing permissions / change logs / rollback functionality we are improving on. One of our core responsibilities is to make changing Feature Flag values as safe as possible. We know that flags can quickly become tech debt, so we also preach that feature flags should be as easy to remove from your code as they are to add to your code.

A fully featured feature management platform should be with you from your IDE / CLI, Code Review / CI, Deployment Pipelines / Alerting and Monitoring, and integrated with your Project Management and Product Analytics. It should be visible to your team throughout their workflows what features are enabled across all your environments.

You can use a git-based workflow for feature flags, that's likely how most teams will start using flags in their code with environment variables and infrastructure state. However, most deployment pipelines in the wild are very slow and owned by engineering, limiting the value of doing git-based state for your Feature Flags.

I've seen that disconnecting the deployment of code from releasing of features can be transformative in various ways that fit better with an API-based model for Feature Flags:

- Many flags / remote config changes in production environments are made by non-developer members of a team.

- Coordinating releases across multiple platforms that have different deployment cycles. For example, deploying a new feature to Mobile + Web + APIs simultaneously.

- Enabling / disabling flags in real-time across your stack to respond to incidents.

- Support / Sales teams using Flags to gate features for customers.

- Remote config to populate data for UIs, to act as a CDN for content.

- Rolling out infrastructure changes, being able to roll back changes instantly without another deployment.

(And for context: our Feature Flag decisioning is done locally for our local bucketing server SDKs)

Really interesting take on your experience with experimentation / feature flags and wanting it to be more stateful in code. I assume that follows the more Terraform-like infrastructure as code approach, which certainly makes sense to rollout infrastructure changes. We have a V1 of a Terraform provider where we hope to enable more control through terraform to manage infrastructure changes directly, but you are correct that has yet to be our core focus. Another way we hope to expose that state outside of our UI is building out a great CLI, which we are actively working on.

Our primary usecase has been working with product development teams who have adopted Feature Flags as part of their workflows, using DevCycle to help them deploy features faster / safer to their end users, even deploying continuously as we do. Generally, customers integrate DevCycle into their Websites / Mobile Apps + API servers to control those feature deployments. We have had a couple of customers use us at the infrastructure layer. One of the best use cases I've seen is in a proxy service controlling the rollout of a new infrastructure stack. I'd love to dig into this use-case deeper and see how we can better support it in the future, "Ops" flags are one of the flag types we are looking to support.

I would say that for customers looking to disconnect the deployment of code from the release of features, our approach where you can "release" features at any time has many advantages over "git-ops" style configurations. But certainly, for Ops use-cases where you are controlling infrastructure changes, we are believers in "git-ops" and use it ourselves. The challenge comes with how to connect those two deployment styles effectively.

(DevCycle Co-Founder & CTO here) The truth of the Feature Flagging market is the vast majority of engineering teams aren't using a third-party tool for Feature Flagging. Most teams are using an internal system (Environment Variables, Database flags, S3 files ect.) or not doing any feature flagging. The potential for the Feature Flagging market is as large as any other developer tools market, and the challenge is to build a product with a better developer experience that encourages the adoption of feature flags and integrates with team's workflows.

We've been in the A/B + Feature flagging space for about ten years with our visual A/B testing-focused product Taplytics (W14), so I'd say we have lots of experience running Feature Flags + A/B tests at scale. We've learned a lot from our customers over the years and were excited to build DevCycle as a green-field project from those lessons. If you are interested, try it out and we are always open to direct feedback.

But Stocks and Currencies aren't technically a digital good, they are partial ownership of a company or a hard currency. A NFT is exactly the definition of a digital only good, seeing as how a large number of NFT use-cases are to replace / make portable in-app goods sold in online games / mobile apps, which all currently require IAP fees to purchase on mobile. So this is just Apple applying the same rules to NFTs that apply to purchasing items in mobile games.

Apple was never going to allow the blockchain to remove their 30% cut on these purely digital items, as much as crypto folks preached that the blockchain would remove us from the shackles of App Store IAP payments.