Are You "OSS-SOL" or "OSS-OK"?

The New "Battle-Preparedness" Requirement:
Open Source Challenges For Software Sales Teams

By Henry W. (Hank) Jones, III
Intersect Technology Consulting -and- Law Office of Henry W. Jones, III

Your road-tested, career-long plans for selling no longer provide an adequate playbook. The old rules for selling software don't govern the entire game anymore. Do you have a "General Public License ["GPL"] defense"? Has your squad huddled about the impacts on your quota and value proposition of the Free Software Foundation and the Open Source Initiative? Have you gotten down and dirty in the field banging heads with customers about "freeware""? It's time for your team to improve your performance of the sport of modern-day software sales. If you're a v.c. or other investor, there are new questions for smart "team ownership" and for hiring, assessing, assisting, and even firing coaches.

Over seven months ago, the cover story of CIO magazine said "The CIO who doesn't have an open source software plan implemented in 2003, will be paying too much for software in 2004." Way back in the springtime, the emergence of Linux and other open source was the cover story of Business Week. What have you done about it?

What has your sales team gone about OSS? How has your sales training been modified to adapt to OSS? How have your company's products, pricing, licensing terms, marketing messages, and other habits and tools changed?

If your prospects think that they can "get it for free" (rightly or wrongly), why should they marry up with you? What will you be forced to do about OSS to survive and hopefully thrive?

You don't have a choice. In the last year, your customers and prospects have been adjusting their perspectives on budgeting, i.t. spend ROI, and supplier choices. So have senior executives and boards of directors - the decision-makers who control funding for new software, upgrades, and even studies to consider new i.t. expenditures.

So, what have you and your sales team done so far, to adapt promptly to the accelerating, broadening OSS revolution and its multiple impacts? Where is OSS in the agenda of your next sales meeting? What is your "OSS action plan" for the remainder of 2003? What are your specific plans, their timing, and their interdependencies during Q4 of '03?

This is the first of a planned series of articles addressing why you should, and how you can, adapt to OSS. This installment covers the why's, who's, and when's of the new OSS threats to enterprise and other software sales. A second article, to appear in a later issue of The Sterling Report, will lay out more detailed suggested solutions - recommended how-to's for coping with the new software world order.

So What's The Big New Deal About Open Source?

What, me worry? If my company claims proprietary technology inside our products, can't I laugh off those freeware geeks? My R&D people would never cut a corner - download third-party code from the Web and then bake that into our products that I sell - right? Must I really consider OSS as a relevant management issue, or a threat, if my company has solid products, management, funding, customers, prospects, marketing, and tech support? I have years of software sales experience, do I really need to reassess the adequacy of my software-related skills and prospects?

Savvy sales executives and teams have already modified their training, messaging, and contracts to cope with the new reality of OSS. And technology vendors have modified their strategies, product offerings, license terms, and value propositions, to adapt to the new "free code" paradigm. Why?

1. OSS Is A New Challenge In Sales Calls

If you're part of a true "A Team," then your shop should be able to address right now, without hesitation or muddling, the questions below (and other questions that will appear in a later installment of this series). If you want to be part of a survivor, then consider whether every member of your sales team (and marketing, tech support, and other groups) is prepared to answer credibly and persuasively the new questions triggered by the "OSS inside" phenomenon.

Read each question below and imagine that you're meeting face-to-face now with the buying manager(s) of a key customer or prospect. If you haven't yet been confronted with these objections, worries, or requirements by customers or prospects, you will be soon.

  • "What exactly are the differences between "open source," "freeware," "copyleft," and "shareware" anyway?"


  • "Why did that industry executive say at a recent conference "now OSS≠ just Linux and = LAMP and"? What does that mean, in our industry and to me?"


  • "Do your products include any OSS now?"


  • "If you say 'no', why are you so sure, when every programmer can download and bake in third-party code easily, including from home PCs?"


  • "Has any third party audited all your company's code and verified your individual understanding about this? When? What qualifications and expertise in OSS issues do they have? What were the results of the audit? Can we see it?"


  • "What written, specific policies, processes, and tools have been implemented inside your company to prevent leakage of OSS code into your product line?"


  • "If your answer is 'yes, we do have some OSS inside our product(s)' and an intellectual property problem arises with the OSS component(s), then you'll pay all our legal, internal, and other costs (i.e., fully indemnify us), right?"


  • "If your answer is 'yes, we do have some OSS inside our product(s)', how do I know that your company has complied with the GPL? Is the GPL code incorporated by 'static' or 'dynamic' linking in your products?"


  • "If your answer is 'yes, we do have some OSS inside our product(s)', how does any strict license for your upstream component(s) limit my company's modification, extension, or integration of your product - if we decide to buy from you?"


  • "If your answer is 'yes, we do have some OSS inside our product(s)', was it OSS with one of those more flexible types of OSS licenses? Which one(s)? BSD? Academic? Mozilla? Some variant? Will you please explain to me the differences between the restrictive and more permissive OSS licenses involved here?"


  • "If your answer is 'yes, we do have some OSS inside our product(s)', since your development cost is reduced as a result, by how much will you reduce your prior pricing?"


  • "How can I be confident regarding the quality of your products, once you've baked in OSS? Shouldn't I lose sleep, imagining my internal audit manager, CFO, Audit Committee to our Board of Directors, and 20/20 News chasing me?


  • "Will your competitors who incorporate OSS into their products consequently have reduced costs and be more competitive in the future, especially in the down economy?


  • "If your answer is 'no', why aren't you adopting OSS, to reduce your costs and my pricing?"


  • "How have you changed your customer license contract terms to address OSS components?"


  • "Has your company modified its H.R. policies within your product development organization, to help take advantage of OSS cost control and other benefits, and to attract and keep OSS-leaning techies? What have been your company's particular changes regarding hiring, training, performance evaluation, and moonlighting or side projects?"


  • "What's your company's position on the validity and future outcome of the SCO v. IBM litigation, now that SCO got a $50,000,000 investment in mid-October? How long will it last? Who will get subpoenaed to provide factual testimony or documents?"


  • "Is my company at risk of getting sued, if you incorporate OSS? If you say 'no', then why have other publicly traded tech vendors included such product-content litigation warnings in their recent S.E.C. filings?"


  • "Will you place some of your product code into an OSS model, to hopefully allow it have more support among tech folk, as have Netscape, RealNetworks, and others? If so, how? If not, why not?"


  • "What training activities has your company initiated inside, to adapt to OSS? Which modules have you personally completed?"


  • 2. OSS Changes The Rules Of Competition Among Vendors

    "It's hard to compete with free."

    As you should have heard by now, "freeware," "copyleft," and "open" code, applications, and tools bear no license fees. Yes, there are costs for planning, integration, and technical support included in any correct calculation of "total cost of ownership." But have your customers and prospects really forgotten that foul word, "free"?

    More tech vendors now feel and confess to the threat of open source alternatives. For example, the impacts and variety of OSS challenges increasingly are specified in risk disclosures to current and prospective shareholders in annual reports, quarterly reports, stock offering prospecti, and merger deal documents filed with the U.S. Securities and Exchange Commission.

    For example, what do you think was the number-one threat to profitability admitted by Microsoft in its October 15 prospectus, stated before a dozen other competitive, technology, litigation, and other pressures? Answer: open source.

    The same acknowledgement that "it's a new world" has surfaced in S.E.C. filings in recent weeks from Palm (10/14), Sun (9/29), Silicon Graphics (9/29), Caliddus Software (9/22), Provide Commerce (9/22), Oracle (9/18), Opsware (9/12), RealNetworks (9/12), NetIQ (9/9), and others. "OSS worries" are a clear, accelerating trend for traditional, proprietary-only vendors - both pure software companies and vendors of hardware, peripherals, and other technology products with software inside.

    3. OSS Changes Your Prospects' Procurement Processes and Standards

    Preparation beats inspiration. Planning and synchronization is better than fast-talking improvisation.

    What do you say when your prospect asks "Is there any freeware in your products?" How will your reps reply, when the RFP now requires you to "Disclose any open, free, or other non-proprietary code in your product design, development tools, delivered version, or documentation"?

    Be ready. Vendors are encountering such interrogation from their recent leads. Also, in recent months customer-centric contract negotiating seminars have added open source to their recommendations of "what to watch out for, from those rascally vendors." And lawyers advising your prospects are telling them to get new disclosures, warranties, and potential penalties if a tech vendor includes OSS without approval. Finally, MIS managers and their bosses want more assurances that software and network security won't be compromised by uncertain code in the post-9/11 era.

    Customers and prospects have been sensitized to these new issues by the SCO v. IBM and Red Hat v. SCO lawsuits, their widespread publicity, and angry Internet postings by OSS-favoring geeks. Now, in the post-Enron, Sarbanes-Oxley law era, corporate managers worry that "things aren't always what they seem -- or need to be." This increased caution and diligence includes the history and contents of software offered by vendors. You have the need to know now about OSS in your wares.

    4. OSS Might Impair Your Partnering Potential, or May Help It Someday

    Microsoft has over $49,000,000,000 in cash (as of its 9/5/03 10-K report to the S.E.C.). Want some?

    Microsoft continues to expand its goals, product offerings, aid to friendly symbiotic vendors, and cash reserves. (Any surprise?) But it resists and even battles both Linux and other OSS, urging instead the benefits to customers of the traditional, proprietary business model for software development, licensing, and support. Its "shared source" initiative is sometimes viewed as a begrudging, small, but necessary adjustment to the OSS revolution.

    Recently-disclosed documents show that Microsoft will prohibit an OEM licensee from mixing Microsoft code with OSS code or processes. Such "identified software" (it doesn't have to be called "open source" or "freeware", which might make it harder to find in your code base) can't be mingled with a partner's code. (Can you blame Microsoft or other vendors for such prohibitions, given the potential adverse effect on software proprietary rights of the stronger, restrictive forms of OSS licenses?)

    In the future, resellers, integrators, VARs, and other potential business partners may decide who they ally with and who they'll avoid in part on "whether or not there's OSS inside, how much, and how well it's been managed and documented."

    On the other hand, a coherent, well-managed "OSS usage and risk management strategy" can make your company more desirable and hence more competitive. Other business partners might smile on a cost-cutting, nimble product strategy -- a modern-style business model that deploys OSS.

    So robust, pro-active OSS management in your company's strategy, product development, marketing, and technical support may impact your "business ecosystem," for good or bad.

    5. The OSS Devil Is In The Design, Development, and Documentation Details

    There are significant differences in OSS code, OSS licenses, and OSS development groups - the particular impacts on your customers, company, and career lie "in the details". You need to know the rules, the players, the new lingo, the new decisions to be made, and the new processes to implement in order to compete well in this modified ballgame of software.

    If your coders, product managers, or tech support personnel use free code from the Web and its bands of smart coder donors, they can obligate your company to release source code to the world, if your output is a "derivative work" and the GPL applied. If your products take from "the community" of "open" coders, then your formerly "closed" (i.e., traditional, proprietary) products may be required to be licensed on terms dictated by that reused, upstream component code - not your company's "standard" contract. And there are other potentially applicable OSS requirements, depending on the particular code and license involved and how the code is used. (This scenario assumes the OSS code is included in a product. Most OSS licenses have little or no high-risk impact -if- the code is changed and used -only- within the user/licensee operations. But, does that cover subsidiaries, employee home equipment, sharing with your supply chain via an extranet, or other types of software "distribution"? No one knows yet. And nobody wants to be a test case.)

    But some OSS licenses are permissive. Your developers can bake the raw material of some (but not most) freeware into your company's proprietary, object-code-only products with impunity. It all depends on the particular code and how it's used.

    And there are several dozens of common OSS licenses. On top of that, some OSS developers modify the license terms - so your engineer's assumption that a download is "standard" may be heartfelt, but dead wrong. (Remember the old joke re. " 'assume' makes an 'ass out of you and me' "? It might also make "a sue me".)

    In any event, many OSS licenses include major ambiguities or holes that can impact operations. For example, do your OEMs, VARs, and other resellers get the certain right to modify the upstream code? Can they set up their own indirect channels, for the portion of the software that your company doesn't own?

    Code is real estate, in the software business. Your team should check in detail all the titles, maps, zoning, easements, flooding, termites, and other "rules of the land" underlying your business - i.e., the code components, provenance, and licenses - before your build your "shopping center" or "skyscraper" (i.e., your business) on top of them.

    6. OSS Changes Your Exit Strategy Scenarios

    Got stock options? Got good odds of a home run (or at least a "triple" or "double") financial result if your company gets bought out? Think that your company will be one to escape the predicted consolidations among the ranks of enterprise software vendors?

    Maybe you'll be fortunate. But you need to know that there's a new, OSS-specific threat. It's this: the terms of recent merger and acquisition agreements among tech vendors ban or restrict OSS. So "exit via acquisition" has a new barrier (or at least a very tight filter). The usual "t's & c's" of tech mergers have changed, in a way that's much tougher for the target companies.

    Studying the contractual terms of the new era of tech acquisitions in recent weeks reveals a new hurdle, not contained in the mergers of prior years. It's in these deals, and more: EMC-Documentum, Lawson-Apexion, eBay-Fairmarket, Click2Learn-Docent, EMC-Legato, Hyperion-Brio, Interwoven-iManage, RealNetworks-Listen.com, Filenet-Shana, Mercury Interactive-Kintana, Veritas-Precise Software, Mercator-Ascential, Informatica-Striva, Autonomy-Virage, Epicor-ROI Systems, SSA-Exe Tech, Ross Systems-chinadotcom, and others. And the list is growing monthly.

    First, the buyers (folks with bigger bucks that your customers) now ask target companies to swear that they never baked any OSS into any part of a product. Can your company promise that? Knowledgeably? Accurately?

    Second, some buyers require a warranty that no OSS obligations will apply to them, if and when the deal closes. Now they require contractual assurances that the acquiring company won't be obligated to follow those messy OSS obligations after and if the deal closes. They demand they won't be required later, by the target company's prior development decisions, to:

    (a) give source code to anybody and everybody,
    (b) give the world the right to modify the product as desired, and
    (c) use only the same licensing terms that flowed down from "upstream" (rather than proprietary, traditional license terms).

    Third, some acquirers demand that the target company specify the particular ways and days that OSS was used in the research, design, development, or documentation of products. That is, you must disclose and list the particular genealogy and "provenance" of all OSS in your code base and product line, as a condition to being bought out. "Product provenance certainty" is a new buyer value or requirement in the OSS era.

    These anti-OSS requirements, contained in the recently disclosed acquisition agreements of other software and tech companies in the last few months, have a current impact on you. They mean that your company needs a comprehensive OSS management plan in place now. The challenges to a sales team's selling and training plan is only a part of the new OSS puzzle.

    OSS and You: Action = Survival

    If you have robust, smart, consistent answers and processes implemented and tuned up to address the new OSS questions and challenges, then maybe you'll get that question that you want: "OK, where do I sign?" You can be OSS-OK, rather than OSS Strictly Out of Luck, if you act.

    In a later issue, we'll suggest "homework" resources, particular needed actions, and additional OSS questions that you'll face, to help both your company and you survive the new OSS era.


Henry W. (Hank) Jones, III is a 23-year software/tech. lawyer, consultant, executive, trainer, and writer who has worked with over 100 software and other information technology vendors. He operates both technology law and consulting practices from Austin, Texas. Hank is an alum of the senior management teams of 3 publicly traded tech vendors, where he served as a "utility infielder," head in-house counsel for two, and V.P., I.P. Dev. for a third (Ashton-Tate, QMS, and U.S. Robotics). He also has worked as a senior software and technology lawyer and manager inside Accenture, (Arthur) Andersen, 3Com and in private practice. Hank has spoken on and chaired panels on open source and other software business topics at COMDEX, Software Publishers Association, Austin Software Council, and many other industry groups. He has conducted sales, licensing, and negotiation training workshops, process reviews, and other special projects for various technology vendors. Hank welcomes feedback on this article (512-695-4673 or memphishank@aol.com).

© HWJ 2003.








To Subscribe to The Sterling Report, please click here.