The nice folks over at the SQL Data Partners Podcast, Carlos & Steve, talked to me and Chrissy LeMaire (of DBAtools.io fame) recently about what it’s like to build an open source project with the community.
Here’s the episode: Building Community Tools – and you can listen to it while you read this. I really like how they edited it together, mixing their thoughts in with ours.
Since the podcast, I’ve had a few other thoughts that I wanted to include.
At first, you have to be consumer #1.
Build something that solves a real pain for you every day. If you’re feeling the pain, other people are feeling it too, and there’s nobody else who understands your pain the way you do.
If you use your tool every day, then you’ll be motivated to keep making it better. You’ll even get excited when other people propose improvements because their work will make your life even easier. (Eventually.)
On the other hand, if you build something thinking “this would be cool for somebody,” then you’re already at a disadvantage because you don’t really understand the target market.
Sometimes, you’ll get the wrong consumers.
People will see your tool and say, “Wow! That’s cool, but it’d be even better if it did ___.” They’ll ask you to write code to do ___, and you’ll feel guilty because they like part of your tool, but you want them to like the whole thing. Later, people will even say things like, “Your tool just sucks because it doesn’t do ___,” or “Your tool doesn’t do ___ the right way.”
You have to be comfortable saying no.
I get this a lot with sp_Blitz – people say things like it should do security audits, or run on Azure SQL DB, or be written entirely in PowerShell. Those are all great ideas – but they’re for someone else. I wouldn’t be a consumer for that, so I’m not really the right author to write those tools. They’re welcome to write ’em, though.
Later, you’ll get the wrong developers, too.
At first, when you start getting code contributions, you’ll be just so excited no matter how bad the code is or no matter what features it tries to accomplish.
Over time, that gets old because you are the one who has to support it. Someone will do a drive-by contribution, put in really bad code, and then not be around to answer the inevitable bug reports.
To deal with that, read Daniel Bachhuber’s wonderful post, My condolences, you’re now the maintainer of a popular open source project. It does a great job of capturing the highs and lows of building something that captures public attention. You end up feeling guilty because you can’t do enough work – there’s always people wanting you to do even more. You have to set boundaries, make yourself happy first, and do what you can, where you can.
Building open source costs real time and money.
At first, since you’re consumer #1, the tool you’re building saves you time and money.
Later, as you start dealing with other consumers and developers, a open source project can become less about solving your own problems, and more about giving back to the community. Our company uses sp_Blitz/sp_BlitzCache/sp_BlitzIndex/etc in our daily work to put bread on our table, but there’s a cost to sharing it with the public. No, I’m not talking about the cost of competition – we don’t lose money if other consultants use our tools to do health checks – but we have to maintain & document the code for other folks to use it.
Right now, we spend between 2-4 days per month doing coding, testing, documentation, and releases. That equates to one SQL Critical Care of lost revenue per month – so we lose around $85k/year on the First Responder Kit. You have to think of it as an investment, and be conscious of what you’re buying with that. Open source projects can be of business value, marketing value, or just plain giving back to the community – but you have to make a conscious decision as the project grows to make sure you’re getting the value you need out of the project.