Made by
Made by
Brad Wood
I wear many hats at Ortus. Our company grew up our consulting and development services around a suite of open source CFML products that form the core of our solutions.
I do a lot of consulting and performance tuning for clients and I’m the lead developer on one of our open source products (CommandBox CLI) and a contributor to many other open source libraries. But my very first role at Ortus was as a Developer Advocate, or Product Evangelist as the buzzword was back then.
A typical work week sees me in each of those roles, but I really enjoy the time I spend engaging our community in regards to our products, spreading information, writing tutorials, and encouraging contributions.
I’ve never felt like a good salesman and hate talking someone into something they don’t want or need, but I’m very passionate about the tools we build and I love sharing that with other developers. I see developer advocacy not as a sales sort of conversation (most of our products are free and open source anyway) but more along the lines of sharing things I’m personally excited about with people who want to learn.
If I’m not personally excited about a product, I can’t manufacture that so it’s a good thing I absolutely love talking about tools! I’m lucky enough to be able to do a lot of dev rel on the products I’m also a committer on so I’m in a direct position to enact the changes I see a need for and have intimate knowledge on what I share at conferences.
In school, I knew I wanted to be in the field of programming, but the Internet was brand new back in 1998 so I sort of stumbled into the world of web development in my free time in college.
I worked at a couple local companies in Kansas City where I began using products like ColdBox MVC and was attracted to the mailing list where I started answering questions and helping provide input on releases. After a while, I was submitting patches and writing blog posts and tutorials on my own because I loved learning and sharing. That led to my first offer to work with Ortus Solutions officially to help spread the love about Coldbox MVC, which was our only real product library at the time.
Over time, that grew into more and more products, our own yearly conference, and lots and lots of documentation. Even though I’ve taken on architect roles on many products, I still spend a lot of time making these products accessible to the CF developers out there who stand to benefit from using them.
I see two major prongs of dev rel at Ortus.
The first is simply raising awareness of our libraries, what they do, and why people should use them. That may seem really basic, but the CF community is steeped in legacy applications and legacy mindsets. I actually have conversations about why you should be using an MVC framework, source control, or automated testing. Just penetrating that can take a lot of work, and we’ve launched an entire program at Ortus called “Modernize Or Die” to combat “CFML Shaming” as we call it.
Modernize Or Die is the theme of our yearly conference, our two podcasts, and our training. We’ve got to push people to want to modernize and understand the benefits of a modern suite of CFML tools first. This is augmented by a documentation-is-a-feature mentality, tutorials aimed at beginners and advanced devs, screencasts, blogs, and newsletters. Luckily, I’m not responsible for all of this!
The second prong of dev rel at Ortus is engagement. The majority of our libraries are professional open source and I firmly believe that your community is your biggest asset. You can’t view them as just static users or ticket factories. Every user has potential to give back to a product, and in doing so they gain ownership and satisfaction in what they’ve accomplished. This can be in the form of ideas, bug reports, documentation, or pull requests.
The worst position to take on an open source product is a closed fist around the process. You’ve got to let go and allow others to help, even if it means they won’t do it exactly like you would, or it may take them a little longer. In the long run, your products will be better off, your users more engaged, and your own plate less full.
To help make sure things keep moving, we have regular meetings with our team to cover outstanding pull requests, major feature roadmaps, and coordinate release communications. Members of our developer community who support us can sometimes be a part of this as well so we get feedback directly from the user base.
The friction points from our users and clients get boiled down to new features and libraries that we add to our suite of tools and then we need to complete the cycle by making sure everyone knows about the latest tools for solving current problems regarding Docker deployment, testing automation, DB migrations, or whatever we’ve been working on.
I get to speak at several conferences a year, but the speaking slot is a footnote to the “hallway track” at conferences for me. This is where people corner you with questions and ideas, where you get to see real examples of people using your products, and where some of the best community feedback and ideas come from. I walk away from every CF conference with a stack of new tickets and a few pull requests from people I’ve talked with.
When I’m not traveling, I immerse myself in the online communities where people ask for help to keep a feel for what’s happening. This gives me early visibility to bugs that may not be reported, pain points, or missing features. If someone asks a question, I don’t just answer it. I think, “Could we have had better documentation on that feature? Does the feature really do what developers need it to do?” Every piece of feedback is a potential cycle of refinement or improvement.
Being engaged in the developer communities such as mailing lists, Facebook groups, and Slack teams is also key to enabling the engagement I spoke about earlier. So many people are waiting for permission to jump in, or just need a nudge to know where to help out. If someone finds a bug, point them to a post that shows them how to submit a ticket to your tracker. If someone submits a ticket, offer for them to take a stab at a pull request. If someone send a pull, ask if they would mind helping update the docs to cover the new feature. It’s sort of like the book, “If you give a mouse a cookie”, but this time we’re inviting developers who collectively have more free time than I will ever have to step into the cycle of creativity.
Just be prepared to help step in and finish that pull request when the dev doesn’t have time to get the tests passing. Be ready to finish up the part of the docs they weren’t sure on. And above all things, be responsive! Nothing will drive developers away from your ecosystem faster than feeling ignored, or worse, seeing their hard work wasted on an unmerged pull request that rots on the branch. I’ve seen time and time again, a dev that has a good experience contributing to your projects will come back and contribute again in the future. This is the scary and exciting point at which a product takes off and becomes an effort on a scale bigger than your internal team. That’s what gets me out of bed in the morning!
Wow, so many things that could go here. I’d say personally, the biggest challenge is reaching the so-called “dark matter” developers who exist out in the ether of your community but don’t read blogs, follow code topics on Twitter or attend conferences.
You can’t get a feedback loop in either direction on someone not plugged in and the best approach I’ve found is to use grass roots means of reaching out to devs using consistent messaging across every platform you have access to. Most dev shops seem to have at least one person who will follow some blogs or podcasts somewhere. Encourage them to get the rest of their team plugged in too.
I’m hopeful that every year we’ll get more pull requests than the last. I’m hopeful that new users will actually read the docs. I’m hopeful that one day devs will stop trolling other devs on Twitter for the language they code in.
I’m hopeful that eventually everyone will apply patches the day they come out. I’m hopeful that hiding ASCII Art stereograms as easter eggs in my CLI tools will make a stressed developer smile.
And most of all I’m hopeful that we can all realize that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.