We all have to promote things: products, open source projects, some people may even promote themselves.
There is a certain thread about promotion that seems to have stuck, one where you define what you’re promoting based on its competitors or contemporaries. I believe it was DDH who first boasted his strategy for marketing Rails was to find the biggest players in the space (at the time I think it was Java frameworks) and state why they don’t work and why you’re better.
This sounds like a good strategy, especially when your competitors are clearly failing, but it has a devastating long term impact on credibility in the GitHub Era. When Rails was first released the only notable open source projects were very large ones and the turnaround time for those projects was long. If you associated a person with a project you could expect it would be a long while before you would associate them with another.
Nowadays, with GitHub, projects are created and discarded much faster. I can think of many people who not only moved their focus from one project to another but who actually discarded the old project for a new one that solves the exact same problem but with a new approach. In this world you have to be much more responsible in how you promote your projects or else you’re slowly eroding your own credibility.
This is not to say that you should never promote your project, on the contrary, you need to promote your project. If you’re spending time on something it’s probably because you think you’re right. Your project will gain adoption and, more importantly, contributions if you spend some time getting other people to use it. But, you must accept that you are not the smartest person on the planet, that you are fallible, and that the success of your future project may now be dependent on proving your current project wrong.
You didn’t start with the answer you have now to your problem. It’s also unlikely that you embarked on this effort out of spite for a similar project. It’s more likely that you examined your problem carefully and decided that not only did existing solutions not impress you but you thought you could do better, that you had a better solution to the problem at hand.
One of the reasons people tend to disparage their competitors is that it gets them out of explaining the problem well because your competitor has already done it for you. You just say “I’m solving the same problem, they suck, I’m better and here is why”. This is great until you find yourself in front of the same group of people a year from now explaining again why another project is terrible, maybe even your old project, and that you’ve struck gold, again.
We’re all smart people, your competitors and your contemporaries are smart people, what tends to set one product apart from the next is a better understanding of the problem and their ability to focus. This means that when your project is superior it’s more than likely that you have examined the problem in a way that is superior and your solution has emerged from it. The best way to promote your project is to first promote that understanding of the problem. The better you are at sharing that understanding of the problem the more your audience can appreciate your solution.
A great thing happens when you share that understanding of the problem, you create an audience that is critical of solutions without being prompted by you. It also means your solution is allowed to be wrong without you losing much credibility. People are wrong, we’ve all been wrong, our very smart friends and colleagues have been wrong, you lose credibility when you convince others to invest in a brand or a specific project instead of the problem, to invest in you rather than something mutual like the problem at hand.
You don’t need to talk about what others do poorly, only about what you do well and in an environment of shared understanding about the problem you’ll be easily set apart from your contemporaries. You are free to talk about the best aspects of your solution and you aren’t defined on your competitors terms.
This is how I promote node.js. I describe what applications tend to look like nowadays (they look like servers, more of this in past and future articles). Node.js is obsessed with the problem of easily building a server so it stands out when solving this problem. It’s allowed to be imperfect, to have warts, to make improvement and even large changes, because it’s all in service of better solving this problem. When I’m asked to compare node.js to Rails or PHP I don’t talk about what they are bad at, I simply describe the problem they were designed to solve, which they solve very well, and show the choices they made to solve that problem that no longer fit this newer model of building applications.
We need to stay critical, we need to stay iterative, and we do our communities and our products a huge disservice when we invest in brand rather than in a shared effort to solve our problems.