Maven as a Candidate: Winning Over the “Undecideds”

It isn’t a perfect analogy, Maven isn’t constantly having to raise money or make tough votes on legislation, but I’ve always thought of Maven as a politician with an established positive base and an established negative base. Like any politician, there is an established base of people who are predisposed to “vote” for you, there is an established base of people who are predisposed to “vote” against you, and then there are the valuable undecideds. This is the real audience, you don’t fight for your base, you try to convince the undecideds to vote for you.

If you were trying to campaign for Maven, you have three options:

  1. Convince the Opposition – It doesn’t work. If you are deadset against Maven in 2010, you are probably not going to move toward Maven in the coming months unless something dramatic happens. Ok, that’s not true, I’ve seen this work, but you can’t make a direct attack on the opposition, you have to cede some ground to gain some ground (but that is a different blog post).
  2. Play to Your Own Base – Believe it or not, this is important. If you lose your base, you’ve lost your support. Maven’s in the #1 spot for build tools at the moment, but in technology things can change quickly. Maven’s base is under an almost constant assault from people peddling other options. Your base has to feel supported.
  3. Win Over the Undecideds – This is where it gets interesting. Since Maven is constantly under attack (deserved or undeserved) we’re constantly seeing people Tweet or comment about having to make a decision about Maven. The competition tends to attack Maven’s deficiencies, and it is easy to get baited into a fight about the deficiencies of alternative tools.

Winning Over the Undecided

Arguing over Maven’s “problems” with the competition is unproductive. You might score points with your base, but undecided voters just see conflict. Think of a nasty political campaign with negative ads: it almost always depresses turnout on election day because undecided voters just don’t care. All they see is a nasty fight. (You might think I’m being overdramatic here, but development infrastructure has sparked passionate, all-out fights, it is something programmers *care* about.)

These fights are unproductive because as soon as you let someone bait you into a fight (“Maven can’t do XYZ, blah blah blah”), you are playing in a lop-sided arena. Yes, Maven has a somewhat verbose approach to configuration if your build is highly customized. Yes, Maven’s repository has some edge cases that make dependency exclusion difficult (but not impossible). If you start answering every single criticism about Maven, the conversation starts to focus on deficiency.

The best strategy is to turn it around. Focus on what Maven allows you to achieve, acknowledge the problems with the tool, and then talk about continued investment in improving it. I’m pretty sure this strategy works, but more importantly you don’t come off as being a combative jackass. Again, back to the politician analogy. Have you ever seen one of those knockdown election cycles full of negative ads and scandals. The victor always ends up sullied by the experience. This is not to say that there’s never a good time to answer dishonest criticism, but it has to rise to very high level to gain acknowledgement.

Remember, there’s a baby in that bathwater…

There are problems with every tool, when you tackle a problem as difficult and universal as project builds you are bound to make someone unhappy. When you “mess with” a programmer’s set of tools, you are going to get complaints from artisans who disagree with fundamental design decisions. Hell, I disagree with a few decisions in core Maven, but, on balance, my experience is more positive than negative.

Do I often spend a few hours debugging some crazy resource filtering issue that makes no sense even after I have fixed it? Totally. But, I’d have much worse problems if I were trying to debug my own, customized build script. Would it be easier to fix a specific problem? Yes, because I would have created the build system myself. But, that’s not the point, the real benefits of Maven are not the direct, first-order benefits, they are organizational. If someone comes up to me and asks how to build the system, I can tell them to checkout the source code and run “mvn clean install”. That’s it. It works very well in my IDE, and I can also use it to deploy applications to production. It runs complex integration tests out of the box with minimal configuration, and there is a wealth of plugins available.

Does it have problems? Yep, but there’s a community working hard to address these problems. Will they ever be “done”? Will Maven ever be perfect. No. But, If you are considering voting for the other guys, I would like to remind you that there’s a baby in that bathwater.