That is, good sub-titles for the book could be “brand tactics” or “using brands.” As that pragmatic bent implies, the book is all about how brands fit into business strategy, down to the day-to-day activities of employees, e.g., from the section on using brands to stimulate innovation:
A strong brand should embody the aspirations of the organization. It should align the efforts of the people inside the company with the tastes, preferences, and needs of the consumers. If employees have this frame of reference, they are simply more likely to see new and appropriate opportunities. A strong brand provides a sense of purpose to an organization — if you like, a sense of future. Without this sense, it’s harder to recognize opportunities, and innovation becomes impossible.
Throwing a Brand Hijack mask on top of the above: the brand should be the identity of the company and provide the company with purpose, meaning, and a mission. Similarly, if those purposes, meanings, and missions match with the buyers of the brand, then you’ve got gas on the fire.
Brand Tactics
The tactical part of the book is incredibly well summed up in the table of contents. Each chapter title tells you a way to use brand:
The book, of course, is about brands in all contexts. My interest is around using brands in software and hi-tech, especially what seems like the future of software, open source, commercial and otherwise.
Open Source and Brands
My interest in all of this comes from a conversation I had with Sara Dornsife over Camaran Diablos and fajitas at Polvos this past summer. We got talking about branding in open source and how it compares to branding in the closed source world.
Since then, I’ve been noticing the way brand plays in the open source world. Something flighty like brand is hard to finalize in any area, but here are some notes thus far:
Barriers to Entry
RedMonk has always emphasized lowering barriers to entry, so the brief chapter on using brand as a barrier to entry is especially interesting. The “tactics” aren’t based on blocking competitors or locking in customers. Instead, the point is that a brand with good reputation is hard for a buyer to leave.
Taking some Brand Hijack thinking in, once juiced up what we’d call “the community” around the brand, leaving becomes even harder for buyers/community members who’ve sunk not only a lot of technological time and skills into the brand, but also added the brand as part of their identity, and vice-versa.
That is, when you have the freedom to leave, there’s still brand lock-in. In addition to the community detachment issues above, in software, a large part of brand strength is the established support relationship a buyer has with a brand. Once a buyer’s gotten everything working and has an established a track record with a vendor and/or community — a brand — switching to another stack requires a huge amount of differentiation for the pain.
Switching software brands can be like divorcing and re-marrying if you’re “OK” with your current spouse.
Brand Goals
One of the key difference between closed and open source software are the goals, at least at a nut-and-bolts level, of brand. In the closed source world, the goal is make more money or “increase share-holder value.” That may be the case for companies around open source, but not a direct concern for groups like Apache.
The goals of an open source project range from “I just wanted to write this” to disruptive “I want to change the world” and everthing in-between. That is, where a business has a clear-cut, end-goal for using a brand — make more money for stakeholders — any given open source project could have an entirely different set of goals…increasingly in addition to the goal of making at least enough money to keep the core project members happy.
Who Controls the Brand?
Another peculiarity of OSS branding is that, in theory, the community controls the brand. In our legalistic world, it’s impossible to fully distribute “ownership” of a brand: Linux is trade marked by Linus, but de facto owned by the community. The GPL is another fascinating bag of intentions and legal necessity: in order to grant it’s version of freedom, much must be owned and dictated by the creators.
Though it’s hard to come up with clear cut paperwork to put around a community owning a brand, you can rest assured that a strong brand with an equally strong community will rebel if the cheese starts to stink.
Reputation
Clearly, brand is used to establish trust between and OSS project and it’s users, but even more as a short-cut to evaluating dependebility and quality. You’re more likely to trust something from Apache or JBoss than “some random” project on sf.net. That said, individual projects like JUnit have established strong reputations by (a.) being started by rock-star coders, and, (b.) proven track records of deliver rock-solid versions over the years.
Of course, that reputation can back-fire. Don’t think that the person-to-person world of open source is all rainbow and sandals: there’s enough in-fighting and “open source sports” to make your eyes go yellow. Licenses themselves play a huge part in projects brand and usually provide the best lazy man’s tool to evaluate what type of reputation any given project will have with other groups.
Identity and Community
Open source contrasted with closed source has always had a huge identity component. I call out the contrast because, back in the days of yore when all source was open, there was no “other” in this instance to pull identity from (instead, there was vendor and platform “others” to draw from). Now that were have both types of software, it’s natural that using and being part of each community gives brands powerful identity levers to jiggle around.
Along these lines, watching the GPL and Linux open source sub-cultures respond to Sun released Java under the GPL was interesting and encouraging. Contrast that with the “soul searching” that we’re seeing from the Agile community as more and more people flock to it. When/if Toyota becomes the #1 auto-dealer, it’ll be interesting to see how the resulting PR and “how did Toyota beat GM?” follow on effects the identity of the Agile and Lean groups. (Consultants! Prepare your slide-decks!)
Brand Extension
Building on a good reputation, an OSS project can prefix it’s name to a new product and more easily introduce a new project. JBoss in particular uses it’s brand to extend and grow the “goodness” of existing projects.
That extension is often more than just prefixing. That said, the marketplaces’ trust in a brand is one input in how widely new offering is used. Apache and other venerable open source organizations do an interesting sort of duel extension when they suck an external, often already successful project into their incubator. At the same time they’re extending the Apache brand to that project and also pulling that project’s brand into Apache.
More
There’s a trove of other considerations: pricing (for support, consulting, or otherwise paying for something), recruiting new project members, the motivational aspects of brand for non-traditional software project management, and more.
As with the small aside in the previous post on brand, to me the important thing is for long jaundiced geeks to scrape the poop off the idea of brand and look at how it can be used to reach their goals instead of either ignore use of brand, or, worse, getting used a brand.
Disclaimer: Microsoft is a client. Sun, where Sara works, is a client as well. She bought me those shrimp. They were hella tasty.
Previous Topic
