Default to Open

Most older companies and people default to closed. They build things in private and discuss what they’re doing behind closed doors. “Collaboration” usually means by invite only.

Most newer companies and folks default to open. They build things out in public in their Github accounts while conducting discussions in public Slack rooms that anyone can join. Even if they’re private Slack rooms, they’re open to anyone inside the company.

(I’m making a sweeping generalization here. Of course there were people doing open source for decades, and IRC has been around for forever. But note that Github and Slack are both less than 10 years old, and they’ve completely revolutionized both of their markets and decimated competitors.)

There’s nothing wrong with either closed or open. They both make sense for different companies, and even for different projects inside the same company.

I’m not young. I grew up defaulting to closed. But these days, when I start a big new client project, I try defaulting to open. How could I share this stuff with the public? Sharing work in the light has so many benefits:

• Other people can learn from the work
• Other smart people can check work, catch mistakes, and suggest improvements
• You do a better job when you know more people will be watching
• You gain a reputation for delivering quality work (because your work is basically advertising itself via outbound marketing)
• You can leverage that work again on other projects (and the public can leverage it too)

Practical example: the Faux PaaS project

kCura’s one of my favorite clients because they’re solving all kinds of fun data challenges, and they’re proud of talking about ’em publicly. At RelativityFest, their annual user conference, they offer technical sessions and engineer Q&A to talk their clients through what technical changes are coming in the future. (I’m missing Fest this year for the first time in several years because I’ve got a training class that same week.)

This month I started blogging about my Faux PaaS project at kCura. As I laid out my work in that project, I looked at each chunk of work and asked myself:

• Could this part of the project be completely public?
• If not, could I break this part into a few smaller parts, some of which could be completely public?
• If I can’t share the exact output or results, can I share the methodology I used to get the results?
• For the public parts, can I craft the documents for sharing right from the get-go?

It’s much easier to build something to be public right from the start as opposed to trying to redact sensitive information later. That thinking drove the creation of the Azure VM testing results spreadsheet you’ll see later this week, the upcoming sp_BlitzBackups script, and the upcoming Set-DbaMaxMemory PowerShell cmdlet.

I don’t lose anything by sharing my work.

It’s pretty unlikely that a prospective client will see the Azure VM testing results and say, “Great! I’ve got all Brent’s data – I have no need for Brent’s services.” Those very specific test results are a snapshot of the world as of a single point in time, and this stuff changes fast. The real value isn’t in the test results – the value’s in the methodology, the thought process, the results that mean something to the business.

And yes, I’m sharing my methodology and thought process, too – but let’s be honest, dear reader. If the only thing stopping you from stealing all my clients was you getting a hold of some methodology ideas, I’d be broke tomorrow. I ain’t the only source of methodology ideas out there.

Do things, tell people. If you wanna be really successful, you’ve gotta do both of those. Gotta let your dim light shine, and that starts by defaulting to open.