With the release of Blackmagic Design’s Public Beta for DaVinci Resolve 16, it got me thinking….are Public Beta’s a good idea.  Every year for the last few years,  BMD has released a new version of Resolve with a Public Beta, at NAB.   The lure of using the brand new application when it’s first released it tempting, but there are a few things that you need to consider when deciding if Public Betas are good for you in general, before taking the plunge and uninstalling the version you’re currently working with, and installing the latest and greatest (?) version.

PARTS OF IT WILL BE BROKEN, SO BE READY FOR THAT!

And it will probably be the part you need to work the most!  All kidding aside, though, I know that I’m exaggerating the fact that the software is broken, as most “broken” elements to beta’s happens in the alpha stage, but you have to be ready for some things (okay, possibly a lot of things) not to work correctly.  When you decide that you’re ready to jump into the world of software beta’s, there’s a certain understanding that goes along with that, and that is you are voluntarily agreeing that wherever this software ride takes you, you’re 100% on board.  No matter how good or bad the ride is.  Let’s be honest, though, in almost all cases the bumps are bigger at the start, and much smaller towards the end of the beta cycle.  I’ve already seen people posting on Facebook saying “I can’t launch Beta version “X” of Resolve at all”, and I’d consider that to be a pretty substantial bug. Speaking of Facebook, one big problem I’ve noticed with the release of Resolve 16’s beta is people jumping to Facebook groups and asking the question “Hey, XYZ feature isn’t working right in my version….is it working for you?”.  I’ve seen this a lot, and everyone’s responses are the same.  “It’s a beta.  Post feedback to Resolve’s forums” Let’s backtrack for a second and think about something that’s exceptionally important whether you’re working on the beta or not. Developers care about whether their software runs properly on systems that support their minimum hardware requirements. If your system specs don’t line up with what’s expected, you’re on your own. That’s why, when providing feedback, the first thing they will want to know is your system set-up (CPU/GPU, RAM, etc).    Also consider that features that are working fine on a Windows Machine might not be running correctly on the Mac. I’ll be honest. I’ve have been, and currently am in a few beta’s, and if you think juggling one buggy program is a lot, trying working with two or three of them at the same time. The first release of the beta is always the worst, and it will get better and better as the beta cycle progresses, but be prepared for what works on your system to not work on someone else’s and vice versa.  Where you get super happy in a beta cycle is when you find someone running into the same problem(s) as you. That means chances are it’s a bug, if more than one person has the same problem.

WHY WOULD A COMPANY DO A PUBLIC BETA?

Normally the way beta cycles go is that you have a small team of testers (I say small, but it could be up to or over 100, depending on the software being tested) who pound on the software for a few months, work out as many kinks as that many people can find, and then the software is released to the public.  Well, at that point, the unofficial beta phase two takes over.  What I mean by that is that you now have your core customers hammering down on the software with just about every hardware configuration and system setup you could imagine, and that will introduce a whole new set of bugs for the developers to fix, and that’s why it’s not that surprising to see a point update come for a piece of software a month after release, as the company has now been flooded with new issues they didn’t even know were there that need addressing as quickly as possible.  BlackMagic Design, with their Public Beta, want’s to skip the small group feedback and get Resolve as “game ready” as possible before it’s initial release, to attempt to squash as many issues as as they can, before launch.   With that being said…..

BE PREPARED TO PROVIDE AS MUCH FEEDBACK AS POSSIBLE!

There are days when I’m working with Beta software, where I have the software open on my left monitor, and the forum group where I post bugs to on my right monitor, and as I’m running into issues, I’m posting feedback to the developers to let them know what’s going on, and be prepared to hear “Well, it’s working fine here.”, and this is where you are waiting, like I mentioned before, for other users to run into similar issues, where things look more like a bug, as opposed to a random configuration issue.  Don’t be afraid to post feedback, no matter how minor or stupid you might think an issue is.  I’m sure there are other people out there running into the same issue as you.  Also, as I mentioned before, when posting feedback, always include your system setup and OS right off the bat, so developers know what they’re dealing with, and can help you troubleshoot and log bugs if necessary.

NEVER USE A BETA ON DEADLINE CRITICAL WORK…EVEN THOUGH YOU KINDA HAVE TO!

This is one that I’m always particularly bad with.  You’ll read a lot of times with beta’s where the development team warns you that the software should not be used in production situations, as they will not guarantee the stability of the software because, it’s obviously in beta, but let’s be honest for a second…..how else are you going to be able to get and give accurate, real-world feedback on the performance of a piece of software, unless you’re pounding on it for 8 hours a day, 5 days a week for the duration of the beta.  That’s where my little piece of advice comes into play. If you’re not that familiar with a piece of software, stay away from any beta’s.  If you’re not ready to commit to having to restart your application 8-10 times a day, stay away from beta’s.  If you’re not ready to commit 100% to the beta, stay away from beta’s.  You get where I’m coming from.  Resolve for me, for example, is becoming second nature, so I have no problems committing to a beta, as I know if I run into problems I should have two or three ways to get myself out of that situation to work around whatever the beta limitation is. Some who’s not as familiar with the software might not be so lucky. For those people, I normally tell them to wait a few cycles before jumping in.  And please, if you’re in a facility where you have multiple editors working on multiple systems, do not put a beta piece of software on one machine, unless it’s yours and yours alone.  Don’t put beta software on a machine you work on during the day, and where another editor comes in at night, as you might come into a nasty e-mail in the morning from that editor who’s had problems with the software from the previous night.

ALWAYS UPDATE YOUR BETA SOFTWARE

In beta cycles, new versions are being release…frequently.  I’ve seen some beta’s where a new version has been released twice in one day, as there was a workflow breaking bug that had to be fixed, or no one could keep working.   The first thing you always have to do when updating to a new beta version is read the “What’s Fixed” and “What’s Still Broken” readme’s, that are normally provided alongside a new beta release.  If you start running into problems, before you post bug reports, check to see if the development team already knows that’s an issue, before filing your report.  Resolve 16 has a new feature in it that many pieces of software do, and that’s the “Check for Updates” option.  Not sure if it’s working properly with the beta, but if you’re looking to update your beta to the current version, you can always find the current version here, in the “Latest Downloads” section!

I love beta’s.  I’ve done a ton of them, and there’s nothing more exciting about working with a product a few months before it’s released to help shape it into the Release Candidate it will become.  Public Beta’s are fantastic for companies like BlackMagic Design, as it gets an application like Resolve into as many excited hands as possible, and excited hands are more than happy to tell them what they love, and hate about the software, and it gets BlackMagic Design feedback from an absolutely staggering amount of people at one time, but on the flip side, be very, very careful when deciding to make the plunge into to Public Beta’s (or any beta for that matter), as a crippling bug in any particular cycle can derail your project, and send you scurrying back to a previous stable version, to potentially start your edit over again from scratch.  To be honest, I’m having a blast with Resolve 16, and it’s been pretty stable for me on the Mac, if that gives you any comfort, as you think about whether or not to take the plunge.  If you are currently running the Resolve 16 beta and are looking for the forum to post your feedback and bugs to, you can find it at this link.