We live in interesting times. Not a day goes by where you open a forum, scroll through Discord, read LinkedIn, or whatever your source is, and reading about someone replacing Adobe, or any other long-standing feature in Flame, Nuke, Resolve, etc. Often major features or entire applications. The more hated the app, the more likely it will be adapted. FrameIO leads the pack, followed by LucidLink.
For decades we’ve been at the mercy of roadmaps by big software companies and plugin developers. And while they generally have built apps and features we like, it was never exactly what, when, and how we like it. But there was nothing we could do about it. We felt unheard, ignored, forgotten and abused. And we dreaded the PE vultures.
Now we can. Thanks to AI and coding agents. We can have it exactly our way. To the details of where which button is, what the defaults are, etc.
Don’t like. Replace it.
We’ve never lived is such a time of abundance. And all for as little as $20/mo.
In some way its a natural reaction to years of neglect and not being heard. It’s the freedom of riding on the wide open roads with the wind blowing through your hair, the sun in the distance. Pure beauty.
Absolutely fascinating.
But it’s like politics. A community of any kind requires compromise and finding common ground. You win some and you lose some. But in total we benefit from shared resources and efforts more than we suffer.
Sharing software however imperfect it may be, makes certain things possible:
We can share knowledge of how it works. Look at the endless threads here and Logik Live sharing best practices and cool tricks on how to handle a shot in Flame. Because we all use the same software. Learning channel videos exist because there is a sizable audience to whom they apply.
If there is a defect, we can call support and they may be able to help us. We can install it on an HP or Dell system of certified config, and we count on it working. Because it was tested, because enough folks use the same system.
Of course Claude has become the new support department. But that is because Claude has been trained on existing software, where there is enough content to understand how something is supposed to work. Claude can help you configure Flame, because Claude has read the documentation and the forums, the accumulated knowledge of many shared users.
Sharing != Adoption
You might think - but we’re sharing our new software. I see 10 threads a day minimum of someone writing ‘I just wrote X, please try it, let me know what you think’.
Effective sharing requires the audience to go beyond ‘Wow, that is cool!’, and actually integrate it into their everyday workflows. That’s when knowledge and shared value is created.
How many of you have installed every new tool posted in the last two months? Howe many of you are still using one regularly that you tried out 6 months ago?
If we know something about humans - they don’t like change!
So how big is the user base of these features clones? No data exists, but human nature would suggest very few. We’re all too busy making our own feature clones, to our exact specifications. So we don’t have to think or dislike how the other person handled that. Look at the number of OFX plugins for LTX Alpha Gen? I know of at least 5, and it’s more likely 10+.
And yes, I made one of them. For specific reasons.
There’s a problem, someone please fix it!
If something goes wrong, people like someone they can call who better fixes it right away. Two unexplained errors and not fixed in 48 hours, and they move on to the next shiny object.
Have you seen the threads needing help with the new tools? Doesn’t work, please fix, and don’t give me a long explanation. Just a fresh version that works perfectly. Human nature. For anything else, they’d then rather put up with the old Flame. At least it feels familiar.
There’s sharing, and then there is really sharing it!
And that’s the reality. With Claude Code we can often fix it ourselves. Of course then we’re fixing things instead of doing billable client work. Often at the most inopportune time.
And you can only fix it, if the code has been shared. If there’s a GitHub repo. You might say, well but it’s python code, Claude can read it either way. Maybe. If it’s a script. But OFX plugins are compiled C++ code. You need the source code. And more of a dev environment. And so are some other bigger apps.
And you install several of them, and they may have conflicting needs of OS versions and python versions. You can Anaconda your way around that, but only so much.
And that community? Once everyone has their personal tool collections, it becomes harder to share setups. You can’t hire a Flame artist and expect them to know all the tools being used. In the past we fretted over studios not having all the Logik matchboxes. It got a lot more complicated than that now.
Oh, and that archive of a job from last year. 3 plugins it relies on no longer live and run. Ouch!
The cost and time starts piling up.
BTW - I’m a big fan of everyone being able to write their own tools. It makes people think about how tools could actually work, and a better understanding of what it actually takes to build quality software. And support users of your software. This improves our ability to have conversations amongst the community and with app developers, makes them more effective, and have realistic expectations.
I’m a big fan of personal freedom. Being able to do what you want, how you want it, and when you want it, is what makes modern life grand.
But what you do for yourself is different than what your role in the community is.
Go build cool stuff. Like it, love it, must have it. Use it responsibly. Tell your friends about it.
But don’t expect others to use them past the ‘checking it out’ phase. And if they do, please make them read the fine print and cherish them.
Be careful about using other tools that aren’t open source on GitHub. It will save you headaches. Life happens, bus tests get failed, people move on. We all know examples.
If you truly want others to use your shiny object, do make it open source and publish it on GitHub, including the source and the CLAUDE.md. It makes it a better product and safer for others to adopt. Invite others to contribute and make it better yet.
Don’t put it behind paywalls. Nobody is going to pay you for a plugin these days, when they can have Claude build it in a few hours or less. The paywall prevents you from making it open source, which makes it harder to adopt. The days of software side hustles are over.
98% of all the shiny objects shared recently will be forgotten code in a year. Very few will have staying power. And that’s ok. It’s all part of the journey.
Bigger Fish To Fry
A few years ago we may have fretted over Autodesk’s bleak roadmap. Now we have a way of working around it.
Watching AI change industries, how well Flame works is likely our smallest worry. A bigger risk than the stock motion vectors being so-so, is that all apps already have or will have within a year an MCP and a lot of our workflows and solutions will go away when we just prompt a lot of tasks.
Our artistic skill will still be needed. The MCP handle the first 80%, but someone with a trained eye will still have to do the last 20%.
Be mindful that MCPs and prompting workflows will favor larger apps, not niche plugins. There is more training data, and the MCPs are more feature rich.
Flame will have surprising staying power despite Claude Code.
Code away and Flame on!!