Open source software marketing

Get the message? Open source is about control…

In my last post I described the threat open-source and internally-developed software poses to traditional, proprietary software vendors. This week, based on what customers tell me about open source, I’ll suggest some themes mainline vendors should hit in their messaging (and in their product development) to compete.

Open Source: Not Just for Free Anymore

First, some definitions, to clarify terms and emphasize the nature and scale of the change traditional vendors are facing.

Proprietary software is typically developed, owned, sold and maintained by a for-profit company. Think Microsoft Office, Oracle databases, or systems management software from HP, CA, or BMC. The customer buys a license and usually pays a yearly maintenance fee of 15-20% of the purchase price for enhancements, support, and upgrades. Also – and this is important – the vendor owns the underlying source code, and only it can make changes to it.

Open source software such as the Linux operating system, the Hadoop software library for “Big Data” analytics, and tens of thousands of other examples, is not “owned” by any one entity. It is offered free, or at minimal cost, by its developer. Just as importantly, its source code is available for modification by any user. The more useful and popular the software, the most users develop enhancements and bug fixes for it.

It is also sold and supported by vendors, some of whom also (or only) provide services. But the community drives its ongoing development.

...and Mirantis helps provide it.

…and Mirantis helps provide it.

This leads directly to some of the pressing pain points that are drawing the youngest and most innovative IT types to open source and away from proprietary software. Here are seven of these pain points more traditional software vendor need to hit in their messaging.

Hot Buttons

Speed: It’s long been an annoyance that corporate IT can’t meet user’s needs. With today’s shrinking product cycles and pace of change, the internal IT group – and often the company it serves – are toast if they can’t change adapt their services quickly to meet new market needs.

Messaging suggestion: Stress product features and case study examples of how your software speeds DevOps– style development, deployment, and enhancement of applications or services. Describe your ease of use, the number and range of supporting software libraries, and any “frameworks” or best practices you offer.

Cost: Maybe you can’t match the pricing of a start-up with offices in a third-tier office park (or no offices at all). But you should at least be in the same ballpark. If not, be prepared to explain why you’re worth more.

Messaging suggestions: Highlight flexible licensing terms, or your SaaS offerings that can help match open-source  cost and flexibility. If you can justify a higher price with your scalability, manageability, security, etc., explain it clearly. If you lack such advantages, go back to the development drawing board. If you require less in-house skills and tuning than open source alternatives, stress this as its a legitimate cost factor.

Collaboration: The day of the solitary coder sitting in their cube doing what they’re told may not be over, but it’s not where the market-changing innovation is coming from. One consultant told me of a very mundane trouble ticket application that turned into an enjoyable, “Is it already five o’clock?” project because he was paired with a business user in the development process.

Marketing messages: Stress any of the ways in which you support collaborative development, both within the organization and in the open source community. Have you open-sourced any or all of your components, or support open-source frameworks? Do you support or host some of your work in progress, in on-line repositories such as GitHub? Do you support, or encourage, the use of in-house collaborative techniques such as pair programming in which developers work as teams?

Excitement:  Your customers are struggling with small, exciting startups for talent. They can’t match the salaries at a Google or Amazon, or the potential stock payout at a startup. But they can get and keep good talent by giving them the chance to develop something important and game-changing.

Marketing messages: If your product was ever used to develop anything game-changing, highlight it as an example of how an internal team can accomplish great, and even fun, things. If you can include (good luck!) the name and photo of the developer(s) who did wonders at a customer, all the better. Make it personal and real. 

 Scale: Can your technology scale from zero users to thousands or millions in a week? If so, explain how; if not, maybe another opportunity to go back to the drawing board.

Marketing messages: What fundamentally new technology, processes or skills do you bring to the table that allows massive, very inexpensive, dynamic scaling up and down as needs change? What about your technology allows is to scale out to infinite amounts of data, transactions, users, data types or protocols?

Security: Most observers agree open source software can be as safe or safer than proprietary software. But that doesn’t guarantee that the right processes are in place to ensure the most critical vulnerabilities are found and corrected.

Marketing message: If your software or service has the chops to consistently outdo the open source development process in finding and remediating vulnerabilities, flaunt it. If you specifically play in the open-source security space, play that up, too.

Fun: Do you sound open-source, or old and tired?

Marketing message: Get a hipster to give your product an edgy name. Would BMC, Cisco, IBM, or EMC name a product  MongoDB, Cucumber-Chef or Voldemort?

Again, cost isn’t the main driver behind open source adoption — it’s top-line benefits such as speed, scalability and flexibility. Drop me a line if you need marketing collateral to help fight – or ride – the open source wave.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Will open source software kill proprietary vendors?Talk to any CIO or IT analyst and it’s likely they won’t be talking about the latest database from Oracle or development platform from Microsoft. There’s even less excitement about hardware like the latest network switch from Cisco, storage gear from EMC or server from HP.

In fact, they’re probably not talking about any proprietary hardware or software at all. Today’s buzz is around cloud-oriented provisioning, management and integration tools such as Puppet, Chef and Jenkins and big data repositories such as Hadoop. They are only the tip of the iceberg of a veritable zoo of tools developed by the open-source community (or built in-house using open source tools).

Open source software is usually low-cost or free. But the biggest draw, according to many customers I’ve spoken with recently, is that anyone can enhance the software and share their improvements through open source code repositories such as GitHub. That allows organizations to develop, scale and improve innovative digital products at warp speed, in the DevOps model of near-continuous development, tweaking and deployment.

The New Normal

For example, business networking site LinkedIn conducts more than 100 experiments on its site per day to see which features its 175 million users like best. It stores 450Tbytes of data on storage from established vendors Oracle and Teradata, but another whopping five Pbytes (with another ten available) in Hadoop.

Much of LinkedIn’s heavy lifting is done by the Sensei distributed real-time database, the Azkaban job scheduler for Hadoop, the Bobo search platform and Zoie real-time indexing system for “elastic, faceted real-time search,” Norbert to manage clusters and workload distribution, and Kafka for messaging. Not only are all these open source, but LinkedIn built Sensei, Azkaban, Kafka and Voldemort in-house.

Or consider the Instagram photo-sharing site, which scaled from 25,000 members the first day to more than 30 million  in under two years. All this was done with only two engineers in 2010, three in 2011 and five in 2012, the year Facebook bought the site for $1 billion. Their infrastructure included the Nginx HTTP server and reverse proxy), the Redis keyvalue store database, the PostgreSQL object-relational database and the Django Web framework for Website creation – again, all open source.

That’s a pretty high-profile business, which earned a fortune for its founders, that didn’t generate many purchase orders for Fortune 500 software or services companies.

Need for Speed

This combination of speed, flexibility, scalability and low cost makes open source a huge challenge to the business model of mainstream software vendors. The mantra used to be that “Big companies like to buy from big companies.” But at a recent conference a CIO quipped that these days, you can indeed be fired buying IBM if open source could have delivered more capabilities for less money.

Some skeptics say the old-line vendors aren’t in close enough touch with the latest market requirements in areas like social, big data, Web 2.0 and mobile. In a big company, after all, requirements must be filtered through marketing committees and big development organizations before they reach the market. In open source, someone sees a need, codes it, and shares it. Even if legacy software providers survive, what (and how far) will they have to cut to meet open source price points?

Most proprietary software vendors are scrambling to respond. IBM was among the first, choosing not to fight the open-source Linux operating system but to embrace it as a way to sell other software, as well as hardware and services.

“I’m not sure there’s anything like a traditional proprietary software company left,” Ashesh Badani, General Manager of the Cloud Business Unit and OpenShift PaaS at Red Hat told me at the recent Red Hat Summit in Boston. Companies ranging from Intel to Microsoft are major contributors to open source efforts, he said. And even vendors who are not going the total open source route are approaching Red Hat for help developing user communities and using its partners to distribute their products.

Whatever software companies do on the technology front, they’ll need to tailor their marketing to play in the open source world. Once they’ve chosen a cute name and mascot for their offerings, there are some key messages they need to hit. Look for those in Part II of this series later this week.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Using an E-Book To Make a Complex Sell

Cover croppedE-books (short, illustration-rich explainers of complex concepts) can be good or they can be trite. Too much dense copy and they become as hard to read as the worst white paper. Too little copy, or a too-cute theme, and they turn off serious buyers.

Sonatype, in my opinion, hit the sweet spot with their promo pamphlet “Go fast. Be Secure.”  While I picked up a paper copy at the MIT Sloan CIO Summit last week, it’s crying out for re-purposing as an ebook.

It uses a medieval type face and “knights in shining armor” theme to explain how Sonatype’s  software automatically ensures that Java code from the global open source community (rather than from commercial software vendors) won’t pose a security threat to corporate developers.

Short and Sweet

They had me on the cover page with a concise value statement. “Go fast. Be Secure.” The subhead explains: “A true story of how Development and Security came together to fix the risk in open source.” Note the short, direct sentences. (One quibble: Using present tense would emphasize this is a service available now, not something that happened in the past.)

Keep reading and you see big, clear pictures and a maximum of about two dozen words per page, in large type for easy reading. The words are carefully chosen for maximum impact, without redundant background or jargon. “Development wanted to GO FAST. But Security wanted to slow down and BE SAFE.” I like that the wording is specific enough that CCF05252013_00002experts in software development “get it” but even an outsider (like a CFO or CEO) can get the general drift. And the illustrations reinforce, rather than confuse, the message.

About four pages in, the e-book introduces technical concepts and the pain point they solve. “Code became like Legos™ – applications easily assembled from thousands of freely available parts. Developers ran even FASTER and Security found it even harder to SECURE.”  Note there’s only one concept introduced per page, and not a word is wasted.

A few pages on they describe the answer: “Bringing SECURITY and SPEED together by building component intelligence and governance in from the START…using all the tools developers love to use today!” Again, the sentences are short, direct, and describe what’s new and better about their approach.

Halfway through the ebook they introduce their notion of “component lifecycle management.” This might turn a reader off as jargon if the vendor had led with it. Instead, they wait until they’ve described what type of components they’re talking about, what kind of lifecycle these components have and why those components need to be managed.

Ye Olde Mini Demo

The second half of the book is essentially a mini-demo of the service. There’s a standard format with a short, concise value proposition on the left (“AUTOMATE and enforce GOVERNANCE in the tools you use today”) and a screen shot CCF05252013_00001on the right. A one-sentence supplemental explainer sits under each screen shot.

One added benefit of the e-book format is that it makes these screen shots large enough to actually read — long a pet peeve of mine in conventional white papers and trade pubs.

Finally, at the end, there’s the call to action (a link to a free snapshot of the reader’s application vulnerabilities) and a “Learn more” page.

Looks Easy But It Ain’t

Creating an e-book this clear required, I would guess, a lot of gut-wrenching work behind the scenes. You need to:

  • Define very, very clearly the top two or three messages you need to convey.
  • Find a very, very clear and concise way to say them.
  • Choose your words carefully so you’re not speaking down to or confusing or reader.
  • Choose and execute a graphical theme that supports but doesn’t distract from your message.
Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Is Open Source Branding Right For You?

I told you the database server was overloaded...

I told you the database server was overloaded…

Are you an old, enterprise software guy (or one of their marketing minions) who is tired of having sand kicked in your face at the beach by cool new open source competitors?

My reporting is telling me that open source software (whose source code can be tweaked by customers or anyone else) is often outpacing commercial offerings, even in large accounts. While cost is an advantage (much open source code is free) customers tell me the real reason they choose it is because it often provides the scalability and management capabilities commercial offerings can’t, at any price.

It’s tough to compete with free, especially when free stuff works better than what you charge for. As a marketing or PR person, you can’t control price or functionality. But you can argue for the kind of cute, oddball name that seems to be table stakes these days in the open-source world.

The rules of this new branding, as far as I can figure them out, include:

  • Keep it short and weird. Going random works (the Hadoop framework for managing distributed data is, according to Wikipedia, named after a toy elephant.) Riffing off a real word works, too (the mongoDB open source document database, is a play on the “humongous” amounts of data it can store. Work your name into it, as Linus Torvalds did with the Linux variation of the Unix operating system that made open-source mainstream.
  • Paint me a picture: The Puppet lets you manage servers and other IT components from afar, like a puppet on strings. Chef takes the metaphor further by letting you create “cookbooks” and “recipes” to automate infrastructure management. The Jenkins continuous integration server performs services for you, much like a butler would. NetFlix’ Chaos Monkey randomly shuts down servers to see how well your application can survive.
  • Get a mascot: Linux got this rolling with its penguin. Hadoop as its cute elephant, MySQL a dolphin and Netflix’ Simian Army of automated stress-testers…well, you can only imagine.
  • Make it sound like code, or Klingon: If it looks strange enough, you’ll care enough to learn that Nginx is a high-performance HTTP server and reverse proxy, Zoie is a real time search and indexing system, Bobo provides search for semi-structured and unstructured data and that Redis, of course, is a key-value store.
  • Make a vague popular culture reference: What came first, Django the Quentin Tarantino movie or the Web app development framework? No such questions about the Azkaban Hadoop job scheduler or Voldemort distributed key value system. Sensei is not only a Japanese word for teacher but a distributed, elastic, real time searchable database. In mythology, Cassandra unsuccessfully warned of the destruction of Troy. Since she also foresaw the Trojan Horse, I think she’d be a security scanner. Alas, she’s a database.
  • Misspell: The free Git open-source code repository and version control system is where you go to store code under development and “git” the latest version of what others have coded. GitHub (the “hub” where you look for such code) is the commercial version, combining the benefits of a misspelling and a single word. Git it?
  • Don’t take it too far: Why call a behavior driven development tool Cucumber? At least Gherkin makes sense as a spinoff that provides documentation and testing for Cucumber. But I’m not sure whether to smile or groan when I read on GitHub that “mitsuhiko/flask is a microframework based on Werkzeug, Jinja2 and good intentions,” while AFNetworking/AFNetworking is a “delightful iOS and OS X networking framework” (best served with fish or venison?)

In the open source world, maybe you’re not trying hard enough if a name doesn’t 1) make you smile, or 2) ask “Can we really do that?” On the other hand, maybe most open-source software (except for Linux or the Apache Web server) is chosen so far down in the technical hierarchy that names don’t matter.

Are you trying to get more Mongo in your naming, and if so, how’s that working for you?

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Demystify DevOps — Or Else

DevOps? I thought you meant SPECIAL ops. Watch me collapse those deployment cycles...

DevOps? I thought you meant SPECIAL ops. Watch me collapse those deployment cycles…

Doing one thing at a time is so…nineties. We now have to do everything, all the time, like the guy texting as he walked past me into a ladies’ room in O’Hare Airport.

But that’s a different story.

The big emerging trend in IT multitasking is DevOps. It means combining what used to be the sequential tasks of creating an application (development) and keeping it running (operations.) Doing both in parallel should allow businesses to roll out new applications and services more quickly. That’s essential when a photo sharing site like Instagram needs to add 1 million users in 12 hours, users expect constantly updated mobile applications, and popular Web sites do continuous “A/B” testing to see if users like the scroll bar looking like this or like that.

 Beyond Process Change

 You might think DevOps is largely a “soft skills” story – how to get often warring development and operations teams to play nice. Development, after all, is paid to get cool new apps out the door quickly. Operations is paid to slow down and make sure they work right and are secure. And there are, indeed, plenty of good stories for marketers to tell about consultants who can do the necessary training and process change.

But it turns out there’s also a big technology story. Operations, after all, collects reams of log files and other data that track the operation of everything from Web servers to load balancers. By feeding that data back to the developers, in real time, they can tweak their applications and system architectures to avoid slowdowns, and adapt user interfaces based on what’s hot from the Web analytics that week.

This has raised the profiles of vendors such as Splunk, whose software monitors and analyses “everything from customer clickstreams and transactions to network activity to call records.” This can be used, among other purposes, “to debug and troubleshoot applications during development and test cycles.” Likewise, the CA LISA software suite from CA Technologies (one of my clients) simulates production environments to help multiple development teams work in parallel and manage test environments, another important part of the DevOps process,

Eschew Obfuscation 

So we know there’s a tech story to tell here. But in my conversation with vendors I’m finding some common challenges:

  •  Many customers either don’t know what DevOps is, or think it is hype. Define DevOps carefully and put it in context of related buzzwords like agile and open source. How you position all these trends isn’t as important as being clear in how they relate. Case studies of how DevOps has scaled securely in the real world will also help win over skeptics.
  •  Especially if you provide products or services on the data analysis side, make sure you explain exactly how you fit into DevOps process. This is a classic opportunity to define the conversation around an emerging market space by being first to explain it. (One sign of confusion: One of my clients described Splunk as a leader in the DevOps space, but Splunk itself doesn’t seem to agree, as a search for “DevOps” on their site yielded no hits.)
  •  Again, if you play in the data warehouse/data analysis/query tools space of DevOps, make sure you explain you’re analyzing machine data from the IT infrastructure, and not business data like when to put the beer next to the diapers to sell more of each. (A classic “Big Data” insight which, by the way, may have been ignored.)

So is DevOps real? Everyone from rocket scientist billionaires at social Web sites to somewhat staider outfits like the German Post Office say yes. Others will take more convincing. Ladies and gents, start your explanation engines.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Cloud Framework Marketing a Murky Mess

Lesssee, the framework supports the APIs which support storage but not authentication...

In more than 25 years of technology reporting rarely ran into such chaos as I did reporting a recent story for Computerworld on open source cloud frameworks. Just about everyone worth talking to claims to have a framework; just about everything valuable calls itself a framework; and just because you have (or are) a framework doesn’t mean you don’t need another framework to get anything done.

Let’s start simple: A framework is a collection (or, if you prefer, library) of software that helps you do something. In the case of cloud frameworks, the objective is to develop, deploy and/or manage a cloud-based application. The “library” of enabling software that makes up a framework might include development, management and test tools, middleware to link the application to other cloud components such as databases, or APIs to make it easier to move applications among clouds.

A Pain in the PaaS and the IaaS

Some frameworks are designed for use with private clouds (those within a customer’s own data center.) Others are for public clouds, such as those hosted in multitenant (multiple customer) environments such as Amazon. Others are designed for “hybrid” clouds (a mix of public and private) except, of course, if by “hybrid” we’re talking about a mix of physical and virtual servers, as some vendors do.

Then, of course, there are cloud frameworks built at various levels of the “stack” that leads from the base hardware to the applications user see. Infrastructure as a service (IaaS) clouds help customers deploy servers, storage and networks; platform as a service (PaaS) platforms have all the tools needed to deploy actual applications. Each level of framework provides a different combination of price, agility, control and security. A customer might need one framework (such as OpenStack) to provision virtual machines, and another (such as Opscode Chef) to describe how those servers will be configured.

Confused yet? Consider that not all frameworks have all the pieces customers need to not only deploy but manage very large, complex applications over time. Some, such as Eucalyptus and Deltacloud, are APIs (application programming interfaces) aimed at making it easier to move applications from one cloud to another. But customers have found that without the ability to also move underlying services, such as data storage, from cloud to cloud these APIs fall short. If your framework can provide that (or you need another to do this work) say so.

Some have even built their own frameworks after being unable to find one that handled enterprise-scale requirements. These requirements include updating hundreds of applications, providing the strict levels of authentication needed for financial applications and discovering and reusing services such as security and data warehousing. If you can provide these services, these are big draws for enterprise customers.

Open Source or Not?

Many large organizations now see open source software (where the source code is freely shared and open to improvement by customers and others) as a safer choice than proprietary code, as long as they can get enterprise-level support. But whether a framework is truly open source and not tied to one vendor can be another mystery.

Some frameworks have a true open-source feel (geeky Web pages with no major company logos.) Other frameworks are backed with financial and technical help from big-name software vendors. Cloud Foundry, for example, is backed by VMware, while Red Hat’s Open Shift is based on Red Hat Enterprise Linux.

That big-name backing is often a plus, not a minus, to customers. But it raises another question in customers’ minds about just how committed the vendor, or partnership of vendors, is to open-source versus their own in-house products. Providing details like the number of developers you’re committing to open source, what modules or code you are contributing to the effort, and how open you are to new members joining the “community” and pitching in. Those are all questions I hear customers asking when considering open source frameworks.

Guess What I Am. Go Ahead. Guess.

Kudos to those who clearly explain what type of framework they are (the level at which they operate, what functions they do and don’t provide, and exactly what role commercial vendors play vs. the volunteer “community.” But others confuse customers with cute product names and high-level benefits such as “agility,” “flexibility” and “portability” without explaining whether or how these hold up under the scalability, manageability and security requirements of the real world.

To avoid being swept away in a flood of look-alike offerings, use my tried and true “fill in the blanks” formula to make your framework pitch more understandable:

               “(Product name) is a “(noun) that (verb, verb, verb.)

                The product consists of (noun, noun, noun.)

                 It is better than competitive products (adjective, adjective, adjective) because it (specific claim, specific claim, specific claim.)”

 And be sure to describe, clearly and up-front, how you meet the life cycle application demands of complex enterprise environments if you hope to serve that market.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.