OS Framework Selection: How to Read Subliminal Messages in Framework Marketing

DZone 's Guide to

OS Framework Selection: How to Read Subliminal Messages in Framework Marketing

These are signals to pick up on and investigate during framework selection.

· Open Source Zone ·
Free Resource

These are signals to pick up on and investigate during framework selection.

When you select frameworks, you check their website first, which is part of their marketing. There's a lot more information in this marketing than you might realize.

This article will take you through some good, bad, and warning signs in framework marketing. These are signals to pick up on and investigate during framework selection.

You may also like: OS Framework Selection: How to Examine an API

Marketing? What Marketing?

Whether it's a non-profit or commercial open-source framework, or closed source, all of them contain marketing. Framework marketing comes in many forms. It's not just the framework's website. It's strategic alliances, success stories, supporting brands, well-known investor names, developer testimonials on YouTube, personal blogs, StackOverflow answers, Wikipedia topics, tweets, events, word-of-mouth tactics, the product FAQ, markdown pages on GitHub, technical books — you name it. 

Anything that adds to the message "choose me, not them" is marketing.

Marketing is good. Purpose, strongpoints, and selection reasons need to be told. A shiny storefront is good, no one can judge quality through a shabby presentation. A little bragging is good, it gives you nudges to decide and ammo to convince people who aren't sure yet.

Marketing communicates the good news. But everything has pros and cons, and you need to know about both. Even the best software has trade-offs that turn out favorable for one use case, and unfavorable for another. How marketing handles (or omits) the downsides tells what the cons probably are, how bad they are, and where to find them.

Warning: Predictors of Vendor Lock-in Frameworks

All frameworks are vendor lock-in to a certain extent, but the following signals point to deliberate vendor lock-in tactics:

  • Complacent tone of voice, murky terms for "intrusive": an intrusive framework

  • If you select this framework, you need a lot more from the same vendor: vendor champion

  • Illogical incompatibilities: vendor geopolitics

  • Very advanced, unexplained features: service plugging

  • "I am the sun, you are planets" diagram,  /* your code goes here*/ , overemphasis on elegance: an immersive framework

Warning: Hip Cartoons

If the marketing shows hip cartoons of happy developers and symbols of speed (space rockets, naked bikes, slingshots, skateboards, arrows), in a style that's very in fashion at the moment, be careful.

Hip cartoons usually mean there's something to hide. You got to find out what that is.

This is my experience. I don't really know why they do that.

My unsatisfactory and unfounded theory is that its Freudian marketing: A vendor with something to hide feels an urge to distract the still-unsuspecting public before they even start asking difficult questions. And do so by spreading a feeling of "join our very cool and super-exclusive community" where you're not supposed to spoil everyone's party mood by being too critical.

Warning: Appeal to Happy Flow Overfocus

Some frameworks are marketed to appeal to happy flow, the meditative feeling caused by long hours of coding, propelled by cans of energy drink, and midnight pizza.

They say things like "coding this is a breeze". Of course, good coding is very pleasurable; it's fun to use something that works very well. There are two reasons to be cautious and investigate deeper:

  • Fun over features: pleasure without purpose and results is not worth much. If the framework would bring substantial, clear, explainable benefits, they'd rub your face in the ad nauseam. They would not dilute a strong message with emotion-arguments like fun.

  • No more dull work: Happy flow marketing also refers to the stuff we developers most hate to work on and hope to avoid with a better framework: ugly legacy code and technical debt.

The unspoken message here is: "if you use our framework, only elegance and fun, no ugly code, no legacy and no other stuff you hate". This suggestion is deceitful, as the opposite is true. The more you focus on coding the happy flow, the bigger the technical debt and legacy code maintenance you get.

Happy flow overfocus marketing is a very quick way to gain market share. Buzz can spread far and wide before it rears up its ugly head, six months later when you start working on version 2.0. (more on happy flow overfocus here)

Warning: Cryptic Positive Statements

Marketers have a law that says you must turn everything into a positive and never use negative words. That can lead to confusing statements when it comes to a product's limitations and shortcomings.

Therefore, confusing positive statements deserve further investigation.

It might be innocent. Often, well-intended technicians write an honest product description first. Then. the marketer says it can't be shared with customers and provides an excess of "fluff" and positive language around the text so that no one understands what it means anymore.

But they might as well be sweeping important information under the rug.

For example, to avoid having to say a piece of software "does not support threads," a marketer might say: "Make the most of a CPU core's power while avoiding the complexity traditionally associated with multi-threaded environments."

But don't assume it's good or bad; investigate.

Bad: Successor That Can't Explain Why It Is Better

Some new frameworks say they are better and hipper than previous frameworks, sometimes with naming and shaming. But if you read on, they don't really explain what is so new, better, or special about it. Why? Because it isn't! Usually, it's a copycat that wants a piece of the market by imitating another framework with slight differences.

Bad, Therefore Good: FUD

Fear, Uncertainty, and Doubt (FUD) is a frequently deployed tactic in software marketing. Don't say why you are better, just say that the others are worse. This is done by leaking plausible-sounding, scary secrets about competitors.

The psychology is clever and effective: Suppose you select the FUDded competitor, and it does become a fiasco? Then, you get the blame for ignoring the warnings. It is safer to believe that at least some of it must be true...

The good thing about a framework doing FUD is that it has a feared competitor that probably does things better than they do. They need to resort to weak arguments by a lack of strong arguments. Good news. Find that competitor, and investigate it. It probably is a great selection candidate.

Good: Being Clear About the Exact Problem it Solves

Most frameworks were built because someone had a practical problem, and decided to make a generic solution for it. With some luck, their solution overlaps your problem well enough.

Prefer frameworks that just say what problem they solve. It makes it very easy and concrete to see if it's the right solution for you, why it is so, or why not. For a healthy codebase, you should select focused, solution-specific frameworks over broad-range frameworks.

Prefer frameworks that state the problem they solve, instead of frameworks where the elegance itself is the solution and the problem it's supposed to solve, remains unclear.

Good: Being Frank About Limitations

Do not trust frameworks that look flawless and say they can do everything, because they do not exist. All frameworks have trade-offs. What makes a framework special often is the same thing that causes its downsides.

Many of a framework's advertised strongpoints become a weakness if used in a wrong way.

If the framework makes clear and frank statements about what it's most suited for and less suited for, it is good news. The vendor is realistic about what results to expect. You will use it as intended, which always gives the best results and the best performance.

Good: Recommend Alternatives for Non-Scope Use Cases

Good frameworks have a focused, specific scope and don't attempt to be everything to everybody. Often a framework vendor receives feature requests from users which they think don't belong in the framework, and tell you what to use instead.

Referring to alternatives for such use cases breathes confidence, focus, direction, and vision. And they will only recommend frameworks which they think are good.


If you look at framework marketing from a distance, there's a lot of information you can distill from it. Don't just go by what they say, but also how they say it, and what's not said.

But don't go by the sign alone, see it as a clue to investigate, and decide on what you find. This way, you make better framework selection choices.

Further Reading

OS Framework Selection: How to Examine an API

Lock-In: Let Me Count the Ways

framework ,frameworks ,frameworks compare ,open source ,open source best practices ,open source framework ,product advertising ,product branding and marketing ,product marketing ,software marketing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}