100% there are some great options on the market right now and I can't imagine anyone trying all of them.
The reality is that most of the products on that list are tackling the problem in a different way, targeting their own specific niche.
I would only recommend looking at the products that resonate with your needs.
With us for example, if our focus on Developer Experience and fitting into your coding workflow resonates, that's great, you should try us out in comparison to the others that position that way.
But if that doesn't resonate and say Growthbook's focus on analytics and data warehouse connections is more important to you, you should look at them and others like them instead.
We're definitely not trying to be all things for all potential users of feature flags, but we're hoping that what we're offering matters to small teams of developers that care about embedding feature flagging into their development process
This is an interesting question, given our unique situation, as DevCycle is effectively a startup within a startup.
As I mentioned in the post, we created DevCycle because of a need we saw among our customers at Taplytics. So in terms of finding first customers, our primary goal was to make DevCycle better than Taplytics for this specific use case as quickly as possible. Once we got to a minimum viable product that was sufficiently good, the conversation with relevant customers at Taplytics was easy, because we were able to point to a product that better fit critical use cases for them.
Beyond those customers, because our focus is on Developer Experience we are taking a Developer-Led approach to customer acquisition. So this means trying as best as we can to write and create quality content, sponsoring developer-focused podcasts/twitch streams, etc. It also means meeting developers where they already are, and supporting others that are building amazing communities. So we are trying to be very active participants in communities like OpenFeature.
We for sure have a long way to go, but from a product and engineering perspective, it's nice for the team to be able to feel like they can participate in the customer acquisition journey by just talking about the interesting challenges they are facing day-to-day.
Hey, awesome that you use Growthbook. They seem to be doing an amazing job on the data and analytics space tied to A/B testing and feature flagging.
Our perspective differs from Growthbook's in that we don't want to replace your analytics source of truth in any way. Product analytics has come a long way in the last few years with a lot of truly amazing players like Mixpanel, Amplitude, Looker or almost countless others.
Our core focus is developers and the developer experience.
What that means is that we're trying to avoid adding features and functionalities that would be directly competitive to analytics providers, and instead be better at integrating with those tools, so you can manage your flags in DevCycle and do your flag and experiment analysis directly in your team's source of truth.
At the moment what this means for our product roadmap is that we're working on things like a feature rich CLI, Typescript enhancements, automatic code cleanup, etc and we're hoping to continue to head down the road of developer experience as opposed to building non-developer tooling.
This is definitely an interesting challenge you bring up.
I think regardless of the how difficult it is to remove a non-binary flag, the market has moved feature flagging away from just binary and merged with the concepts of remote configuration and experimentation, both of which require more than just ON/OFF states.
For us, we're not trying to shy away from that challenge, so it forces us to come up with interesting solutions to the problem.
A couple ways we're solving for this problem are:
1. Variable Schemas - We just launched a feature that allows for engineers to strictly define the acceptable values of any feature flag they are creating, so that as other team members interact with those flags, there are programmatic controls in place that create guardrails on the input. This also does double-duty in creating strongly typed code, so that usage in code is clear, easy to navigate, use and cleanup when the time comes.
2. Code Cleanup - An example of one of those solutions is our Code Cleanup CLI command. Regardless of what the flag type is (boolean, number, string, JSON) you can provide the prompt with what you would like the end state to be and the AST logic built into the CLI will create a proposed diff for your code wherever a DevCycle flag exists which you can then either edit further or submit directly for a PR.
I 100% agree non-binary flags present a challenge, but we are definitely interested in finding unique ways to solve that problem.
The primary differences stem from a difference in focus. We believe that LaunchDarkly is a great first-mover in the space and has done well in their validation of the space. Their focus has traditionally been on the enterprise, which manifests itself in a product focus on things that large enterprises require, like tooling around governance.
For DevCycle we believe feature flagging is about more than just enterprise risk management, and is actually more deeply related to the way in which teams build and ship code together. As such, our focus is on the developer experience and mapping our product more closely to how developers actually work.
This manifests itself in a few key areas:
1. We believe that all of the interfaces that engineers interact with need to be delightful including SDKs, APIs, CLIs, docs, etc.
2. We've built DevCycle from the ground up to better match to a concept of building features, with coordinated releases vs distinct and disparate feature flags. What this means is that we natively bundle feature flags within the concept of a feature, so that a feature and all of its component flags can be rolled out in coordination without the need for workflow automations.
3. It should be as easy to remove our flags as it is to create them, to reduce the cognitive load and complexity of feature flagging over time.
4. All aspects of the platform from the way its built, to the way it is priced (seat based pricing vs usage based pricing) should make it as easy as possible to have all engineers on a team be able to work together on feature flags, as opposed to creating friction and complexity that reduces the number of people that interact with flags on a daily basis.
I hope that helps, if I can clarify further let me know.
I completely agree with this point that it is extremely challenging to make money on mobile. There are options, however, in the market if you are looking for a mobile A/B testing platform that understands this.
To be completely open and honest, I am a co-founder of Taplytics. I just wanted to hop in here and point out that we have a Startup Plan that gives independent developers and mobile teams completely free use of our platform.
Thanks for the comment. We agree that keeping your web presence in sync with your mobile product is critical. We have built Taplytics out as a big API engine with the goal of managing multiple platforms, iOS is just where we're starting.
This article just seems to reinforce how the markets really are only driven by greed and fear. Obviously fear is driving this downward trend. Legitimate that Apple is potentially butting up against some growth constraints, but it seems ludicrous to me that Apple would be trading at a $9 price/earnings ratio while LinkedIn would be trading at a $914 price/earnings ratio. That seems a little misguided to me.
At this point there is nothing to me that would suggest that it should. Obviously over time the idea of a true international currency would be beneficial. But something like bitcoin that was created by a random individual with no government support, no inherent or scarce value shouldn't be able to hold value.
To me it is irrational to put money behind bitcoin, it's a bubble like the Dutch Tulip Mania from the 1600's. No reason for it, and it won't last.
I would suggest that it is both, as I don't think the two are mutually exclusive, and with the way commodity and currency exchanges operate the lines are definitely blurred.
As for your particular examples; commodities have always been used as a means of purchase whether by way of trade, barter or as a currency substitute (gold, silver, etc). The trade of commodities are protected by law. And currency volatility ranges with some currencies being highly stable and others hugely volatile, more so than most commodities.
So trying to bucket bitcoin like this doesn't seem to be worthwhile. I think the better discussion would be whether or not bitcoin should actually hold any value.
I think companies are starting to take advantage of what has always been a "look the other way" loophole in the system. In the past internships led almost directly to jobs, now they essentially lead to nothing, with companies saying that they are offering valuable experience. Internships used to be about giving new hires a place to start in the company, and work their way up. Now internships are essentially unpaid <12 month contract jobs that are revolving doors for young people with no chance of a job when the contract is up.
Young people are now hopping from unpaid internship to unpaid internship, creating a new kind of working poor.
The situation can't last, I think this is just the start of a pushback.
This is very true. The current experience of legal tv content delivery is terrible. It is stuck trying to squeeze the customer for every dollar possible, while not delivering the service that people really want.
The music industry is finally starting to get it, even if they are being dragged kicking and screaming by Rdio, Spotify, iTunes, etc. But still, these are all great services that are giving customers what they want when they want it. I just hope people like Netflix, Hulu and now Vdio will do the same thing for movie and TV content.
I find all of these learn to code posts very interesting. I would consider myself to be a beginner coder even though over the years I have spent time learning or trying to learn C++, HTML, CSS, Javascript, Node.js, jQuery, Objective-C, Python, Ruby and others. For each language I had a different reason for wanting to learn, generally it amounted to wanting to build something and trying my best to learn the pieces necessary to start.
The key thing that ties all of my different attempts to learn together, and why I still consider myself to be a beginner is that I always stopped short of achieving my goal. Generally this was due to hitting some sort of blockage that I couldn't figure out how to get past, or generally getting bored with the slow learning process.
Both of these recent articles have really resonated with me, as I have personally struggled with Codecademy (currently 66% done code year), and I regularly bite off more than I can chew. I like the suggestion of finding a mentor and putting my head down, as well as focusing on small projects that build off of each other.
In the end, I really want to learn how to code, but so far I haven't found a method that sticks. Maybe that says I don't really want it, but to me it says there isn't a great learning method out there for me yet. So while Codecademy is great and all, I really think there is still a hole in the market. Figuring out how to fill it is the key.
I would say the reason Microsoft slumped was that they lost the main driver of their innovation, Bill Gates. While this article (http://www.zdnet.com/blog/btl/chart-microsofts-performance-u...) is a bit old now it shows pretty clearly a difference in Microsoft's performance before and after Gates.
To me it's the same question that has to be answered for Apple. Will Apple post-Jobs, be able to keep performing? We'll find out in a couple of years, but it is possible that the issues with Apple Maps, Siri and iMessages are a sign of the pre and post Jobs eras. I contend that Apple would not have released any of these products in their 'beta' states if Jobs were still CEO. It is that type of sloppiness that could keep them from reaching $1 trillion and falling from grace.
DevCycle is quite new, we just started working on it in 2022.