Disclaimer: I’m going to name the product and company I work for in this article. I assure you this does not mean this post is a product pitch. Really, I promise.
In my capacity as the open source community manager/dev relations/community evangelist/[Enter Alternate Title Here] at Cloudify, I’m a huge advocate of knowledge sharing. My personal credo is that the single most important element in a product’s success is spreading the wealth of knowledge — empowering your users to be autonomous, and even hopefully achieve a level of understanding that surpasses the original development team. Intelligence of the masses. Better code. Better product.
To this end, I’ve been trying to cultivate a culture among our R&D to document document document everything you do. I’m not talking about a product’s traditional documentation. I’m talking about those less formal processes of trial and error and learning that are never formally written down anywhere – and are lost when the person moves on to new endeavors, or even forgets after a time.
I’m also a big fan of internal wikis…but that’s an even tougher culture to cultivate. On top of toiling endlessly to write a great product, and then adding the necessary product tools to make sure people can actually use it – from docs to tutorials – the last thing devs want is the added overhead of actually having to document the technical aspects of the process. So I relent. But I have a dream, nonetheless.
Backtracking to the actual topic at hand. So in terms of interesting stuff my team is always doing – and working with excellent, awesome, interesting and cutting-edge open source tools – we write a lot of blog posts. Really good ones (if I may say so myself) – technical, hands-on, useful…actionable posts. Kind of like meta-documentation. On top of these posts, and the existing tools we leverage in our daily work – we’ve actually discovered a lot of gaps with known tools, and have written additional open source tools that help us get the job we need done – not even as our primary work at hand, just as an added bonus. And I’ve found a scathing irony/hypocrisy when it comes to propagating this knowledge to the masses.
True story. One of our devs did an excellent job of porting Vagrant .box files to AWS. He wrote a really great post about it. There was one caveat though, in the first line he had mentioned why he had needed to do so in the context of his work. He made the major faux pas of mentioning the product he did this for.
I submitted the article to a prominent tech publication – and the response I received was:
“Sorry your product is mentioned in the first paragraph of the post…we’ll need to pass”.
That was the only mention of the product in the entire post (btw, in this new post, we were actually asked to add a bit more info on the technologies mentioned in the article, hence the augmented intro. The initial post started with the pain point). The entire post focused on Vagrant and AWS – these products they had no issue with. But the mention of our product in the first paragraph. Tsk tsk tsk.
Now, I truly and deeply understand that there are plenty of blog spammers out there. Doing all kinds of SEO shenanigans to build traffic, and writing fluffernutter posts.
But seriously just reading the article, and personally I felt this was one of the best written ones I’ve had, you can tell this one does not even remotely fall under the same category.
So then I started to have a discussion with a team member who really likes to write posts. And I love him for that. And we asked the crazy question of… when do you reach that critical mass that you can freely mention your product and its values in the context of other technologies and technological needs without being perceived as pitchy?
Why are certain technologies from the Vagrants to the Dockers (open source) and the AWS to VMwares and even Apples (not even remotely open source) given a stage to discuss the benefits of their products without being perceived as pitchy – while others are completely passed over or even scorned for their mention?
Is it a critical mass thing? A tipping point? Is it what delivers traffic? How can you know a product won’t deliver traffic if it’s not allowed to be mentioned? How can a product garner adoption if it isn’t known about?
And let’s be honest, nearly all open source tooling these days has a monetization angle – people can’t work for free, it just isn’t a sustainable model. So every single tool out there has what to gain.
So who are those powers that be that decide which product is worthy of being mentioned, and those that are only possibly allowed to be mentioned (best case scenario) in the author’s bio?
The even bigger irony is that these sites that are offered these technical posts, and are monetizing themselves off of these contributions, and building their own reputation and traffic and traction and SEO…
I’m not intending to sound bitter. I know these sites receive A LOT of content, and have to be very strict with moderation. I get it. I also know that while pastures may seem green to us on this side of the keyboard – tech sites from the prominent GigaOms to the more niche Dr. Dobbs are shutting down left and right.
And this is where I have to give a shout out to the DZones, DevOps.com and Developer.coms of the world – who do understand the technical worthiness of posts that albeit mention a now esoteric product, but provide information of technical value to their readers, and publish them.
Who knows – maybe the sites that have the foresight to give respect to new tooling will have gotten in on the ground floor of the next Docker. (Because you just can’t have a technical post without mentioning Docker.)
