Supporting the long tail of open source

Supporting the long tail of open source

Summary: Few good developers have patience for stupid people with questions.

TOPICS: Open Source

Roberto GaloppiniMost enterprises, and most individuals, use a small number of open source projects.

LAMP stacks are big. CRM and ERP systems, based on databases, are also big. Applications like Firefox, Open Office and The Gimp are very, very big.

But there are many, many smaller projects, with specialty capabilities used by only a few. How do you get support on them?

The simple answer is to contact the developer and offer to write a check. But the skills of a good developer and a good support person are different. Few good developers have patience for stupid people with questions.

Roberto Galoppini and I chatted about this yesterday. I smelled an opportunity. He expressed reservations.

The context of this was an OSCON meeting which Roberto attended where the Open Solutions Alliance indicated that most open source customers use at least one product from this "open source long tail."

Dominic Sartoro called this the "open source mediation conundrum" and it bears watching. Because, as Roberto notes, software has to work together or the whole system crashes. It's not like books or music where long tail products just need shelf space.

Proprietary companies have a simple solution to this problem. They limit their product lines. Open source does not have that luxury.

So how do we support the long tail of open source?

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Perhaps a good start...

    ...would be for "good developers" to not consider people with questions as "stupid".

    Carl Rapson
    • Good to see you back, Carl.

      I'll add that responsiveness is good marketing. Someone patient with easy questions builds confidence in the product among users who may be intimidated by the product.

      That's why the fall-off of Dell sales, for instance, was associated with a decline in (offshored) customer service. And related to the reason why Dell was willing to make the effort to sell Linux-preloaded computers. Sales of these devices will never be a substantial profit center, but being responsive to the (wistful) yearnings of Linux fanciers builds gratitude for other, more significant purchases.

      Thinking well of a company is a significant part of branding.
      Anton Philidor
    • Also good to see you back, Carl

      The quote is from an old ESPN ad for its Sunday football show. From the season where they pretended to be Bristol University.

      It was from Chris Berman, playing a professor in front of a class. "There are no stupid questions," he said, "only stupid people who ask questions."

      It stuck with me, but I should have referenced it.
      • Thanks for the clarification (nt)

        Carl Rapson
      • I believe it is-

        There are no stupid questions,only stupid answers.
    • Great answer...nt

  • Mixing models

    It depends on what "model" (or paradigm or whatever you want to call it) produced the piece of OS software.

    Was it the IBM / Redhat "we'll professionally develop this free software so we can sell you services" model?

    Was it the Linus Torvaldis "hey, I'm a super smart geeky college kid with a cool project - let me know what you think" model?

    Was it the "I'm a developer and needed to write this utility, but it's kinda cool so I'll share it with you" model?

    Was it the "Hey, I hate spyware so much I'm going to dedicate my life to stamping it out and I made this great piece of software called SpyBot and oh BTW, send me ten bucks if you like it."

    How do you come up with THE answer to "customer support" in such a diverse development environment? You can't, which is both the strength and weakness of open source.
    • Slight modification

      You wrote:

      Was it the IBM / Redhat "we'll professionally develop this free software so we can sell you services" model?

      [End quote]

      More precisely:

      Was it the Redhat "we'll professionally develop this free software so we can sell it to you" model?

      Services are a line on the bill. Red Hat refers to itself as a software distributor. Any company of significant size supports its software, so services are not actually a separate item.

      The IBM model is closer to what you wrote originally, though it might be emended:

      Was it the IBM "we'll professionally develop this free software so we can sell you services and later on expensive software" model?

      Open source can be used to make money in various ways.
      Anton Philidor
      • That's right

        Matt has a great interview today with RedHat's man for Latin America, which I recommend.;title

        We're talking here of companies which are too small, which aren't even companies, in the "long tail" end of the market.
  • Two types of support.

    support for when the product doesn't perform as promised and support when the user doesn't have a clue.

    Both of these issues, more often than not, are brought about by the developer themselves. The former because of poorly written software, the latter by poorly written software as well as poor documentation.

    But proprietary offerings suffer from these issues right along with open source. I will have to say that I have found proprietary documentation usually out paces OS documentation in both coverage and understandability.
  • Not just developers involved.

    One of the best things about open source is that you don't have to be a developer to participate and add value. Most developers hate to write documentation. Much of the documentation that they do write is, well, badly written from a usability standpoint. Taking on the job of writing documentation, be they help files, webpages or wikis can give a good program that push to greatness. It also makes support less of an issue because a good FAQ question bank can make many types of inquiries for support unnecessary. Especially the easy questions, because those are the ones everybody has.
    • Good points

      Every good project needs a good user community.
  • Accountability

    I've long felt that a programmer who does tech support becomes a better programmer because he's forced to confront how people use software in practice (his own, and others). If he supports his own code and actually listens to his users, he'll likely have a very good idea of what needs improvement and what can be left alone.

    Free software programmers are certainly right to charge for tech support (most adults do need to work for a living), but if they don't have the patience to deal with stupid questions, then it's a skill well worth developing. It might even improve the software.
    John L. Ries
    • You offer a fine perspective, John

      Let me be the devil's advocate a moment. It may be better for the programmer to learn how to deal with people, but is it better for the people being dealt with?
      • Learned skill

        I'm as geekish as they come, but I work for a small company, so if tech support queries come in that involve my areas of expertise, I get them far more often than not, and I have learned over time how to convey the information so that non-technical people can understand it.

        Amazing what you can learn if your paying job requires it.
        John L. Ries
        • It's a great way to be promoted

          I have seen that programmers who take the time to learn how to talk to real people become much better programmers, too.

          But not everyone is willing to do this. And this can be damaging to a long-tail program without back-up.

          Someone should provide back-up, and it may be possible to do this at a profit.
          • OS3

            Open Source Service & Support?

            Ms. Blankenhorn, are you suggesting third party players begin a subscription-based service offering of servicing and supporting open source software?

            Perhaps I'm cynical, but I imagine that a company big enough to do this model justice would be big enough to exert/coerce influence on the small open source developers, regardless of what the end user community needs and/or wants.

            I sincerely hope a third party service company would not forecast any profitability in such a venture and would avoid it.

            The less likely scenario (due to a weak business model) that would be more developer/user friendly would be for various developers to join into a cooperative support program, sharing support duties among the group.
          • What's wrong with profit?

            I support a lot of software I didn't write, as do a lot of individuals and companies. I make a profit doing this. I don't hold any undue influence over any individuals or companies whose software I support. As an example, several years ago (1999 if memory serves) I was working on a corporate website was written by someone else. They had integrated an open source component called VBSendMail into their website for handling emails. There was a bug in this component I uncovered when implementing some new functionality on the website. I fired an email off to the author of the component explaining the problem and where I felt he could best fix it looking at his code. He sent me a new .dll the same day with the bug fixed. As thanks for the quick response, I had the company I was working for send him a new set of Klipsch ProMedia speakers. Had I not gotten a response back from him that same day, I would have made the changes myself. That's the beauty of open source've got the flexibility to fix things yourself if you have the requisite skills. Given your response, it would appear that you don't really like that capability.
          • Nothing at all.

            In fact part of the beauty of open source is what you describe. The ability to report bugs and have them fixed quickly.

            And, had you needed to fix it yourself for whatever reason, you could still have sent the fix back to the developer so that others don't have to wrestle with the same bug.

            I don't know anyone who finds that troubling.

            Oh, and you do influence FOSS that way, too, by giving back what was given to you.

            (Something Anton will never understand!)


          • Already exist

            This is actually one of the ways free software advocates like Richard Stallman have proposed for programmers to support themselves. There was a company called Cygnus ("Cover Your GNUs") that was founded to provide exactly this sort of support before it was bought out by Red Hat (I assume RH is still in this business).

            Such a company might exert influence on small open source developers (or it might hire them), but the barrier to entry would be low (all you need are knowledge, computers, and a way to communicate with customers), so if the demand was there, I would think that a competitive market could develop in a hurry. This would limit the influence of any one tech support firm. Of course, a reasonable person would expect such businesses to be profitable, otherwise, it's a hobby or a charity, not a business.
            John L. Ries