More on Build versus Buy versus Opensource

There have been a number of interesting comments on my recent post on the build/buy debate. Leo de Sousa feels I have missed out “reuse” as the first port of call. And I guess he’s right, since I haven’t been explicit about the role of reuse in all this. So I will modify what I said earlier and try and make this more explicit:

  • For common problems use Opensource (thereby reusing community property)
  • For rare problems use Buy (thereby reusing the learning of someone who has already solved the problem for a few others)
  • For unique problems use Build (but do so in an environment of component architecture and reuse)


I could just say

  • For common problems use Opensource
  • For rare problems use Buy
  • For unique problems use Build
  • And in all cases make sure you maximise reuse

Abhijit Nadgouda points out that “with opensource, it is quite possible that you end up doing all three”. Which is also something I agree with, I think we are heading towards a time when opensource is the heart of all software development, but with some local builds and some specialised builds in a hybrid model. The distinction between build and buy and opensource then becomes one of scarcity economics versus abundance economics. Everyone’s got bills to pay, we just have to get the funding models right. Whatever the answer, one thing’s for sure, the current model’s busted.

Louis Nauges takes the argument in a slightly tangential direction, suggesting that SaaS plus open APIs is a different option. I guess I considered it nothing more than a variant of Buy, but then I may have misinterpreted what Louis said. Yes there are SaaS examples that are free-as-in-gratis, but opensource to me remains free-as-in-freedom, so I can’t really find examples of “opensource” SaaS. I need to think about this a little more.

Jag takes a completely different line, one that I am still pondering. What kind of ontology and taxonomy is needed in order for us to classify the problems and their domains accurately? How do we have to educate IT professionals as a consequence of this? More of this later.

Once again, do keep the comments coming. I really do appreciate them, even where I don’t answer back individually. And I learn from them. Occasionally I land up with quite a backlog as a result, but that’s a nice problem to have.

And remember, these conversations are snowballs. None of us should be proprietary about how they evolve and where they get to. You start them off and soon they have a life of their own. Sometimes someone else starts them off, and all you do is add bits to it.

Yes of course the conversations get fragmented. But this is better than stultifying and straitjacketing the conversation in the first place. And if we use tags and folksonomies sensibly, we can always de-fragment them.

10 thoughts on “More on Build versus Buy versus Opensource”

  1. I’m sure some Rare or Unique problems can lend themselves to being solved using lower level Open Source components as well….(or are those by definition not rare or unique :)

  2. Tend to agree, Alan. I’m not going to be popular for saying this, but I think we need to allow the problem solvers some modicum of creativity, above and beyond putting components together. Otherwise they lack the motivation to solve the problem. So a little reinvention is good for the soul…..and not particularly expensive. When I see the fortunes laid waste by not invented here attitudes, it seems a small price to pay.

  3. JP, you ask “What kind of ontology and taxonomy is needed in order for us to classify the problems and their domains accurately?” I answer that you need look no further than one of your own posts ant the discussion it prompted:

    Any noun-based approach can only deal with “the structure of software objects,” which addresses nothing more than interface issues. Any questions of utility require a verb-based approach that deals with the processes embodied by those objects. As the hippies from our past would have put it, you have to forget about BEING and get “into” BECOMING!

  4. JP…and then there are the fortunes laid waste by the “lets invent it here” (again) attitudes ;)

    Take your point re creative work though.

  5. I think the key point is ‘do the right thing for selfish reasons’

    A company will choose to use (and perhaps release) open source if it’s in that companies interest to do so, not because of some notion of the common good :-)


  6. Tagging vs. ontologies. Some random thoughts.

    In theory, an ontology has been designed by a community (or at least a committee) to be a common model of a particular problem space (ie, SNOWMED CT). But, therein lies the cost… you have to get agreement beforehand on the actual meaning (understanding/usage) of concepts.

    Tagging on the otherhand requires no agreement by anyone (and I can even use my own tags inconsistently). Just because I happen to use the same sequence of characters (‘t’, ‘a’, ‘g’) on two different items infers some kind of link. Folksonomies happen to emerge through sheer weight of mass of people choosing the same sequence. But, does that (should that) actually become the basis of shared meaning?

  7. Nick, this is probably a good time for me to invoke a precept I picked up from one of my colleagues at (then) Xerox PARC, which is that knowledge cannot be shared but it can be MADE SHARABLE:

    It this light we can view tagging as an instrument for making knowledge sharable without worrying about whether or not it guarantees any results!

    Also, in the world of “natural language,” ontologies are not “designed.” They emerge from the ways in which we use our language. (Wittgenstein strikes again!) That process of emergence-through-use entails that an ontology can never be cast in concrete; but we see very little (anything?) in the Semantic Web community about how ontologies can change over time in response to Web-based activities.

  8. Hi Stehen, yes, I agree with the sharability (sic) issue. See in particular [1, 2, 3, 4, 5, 6]. Or, a supporting comment “I come here to work, not do knowledge management”. How do you make the sharing either invisible or a natural part of your everyday activities?

    Sharing also implies a bi-directional communication (both parties learn) otherwise it is a broadcast medium.

    I’ve been working on the SEKT project ( ) and one of the many issues was how to cope with evolving (inconsistent) ontologies. Look at the work on Frank Van Harmelan VUA (Free University Netherlands) in ontology reasoning. University of Karlsruhe and the Joseph Stephan Institute have done considerable work on lautomagic learning of ontologies from bodies of text.

    [1] RAFAELI, S. & RABAN, D. R. (2005) Information sharing online: a research challenge. International Journal of Knowledge and Learning, 1, 2, 62-79. Web page, viewed on 27th February, 2007.

    [2] FAIRTLOUGH, G. (1994) Creative Compartments: A Design for Future Organisations, London, Adamantine Press Limited.

    [3] CONNELLY, T. & THORN, B. K. (1990) Discretionary Databases: Theory, Data and Implications. IN FULK, J. & STEINFELD, C. (Eds.) Organizations and Communication Technology. Thousand Oaks, Sage Publications.

    [4] HYAMS, J. & SELLEN, A. (2003) How Knowledge Workers Gather Information from the Web: Implications for Peer-to-Peer File Sharing Tools. HCI 2003: Designing for Society. Bath, UK. Web page, viewed on 27th April, 2005.

    [5] HYAMS, J. & SELLEN, A. (2003) Gathering and sharing Web-based information: Implications for “ePersons” concepts. HP Laboratories, Bristol. Web page, viewed on 27th April, 2005.

    [6] BANKS, D., CAYZER, S., DICKINSON, I. & REYNOLDS, D. (2002) The ePerson Snippet Manager: a Semantic Web Application. HP Labs., Bristol. Web page, viewed on 12th May, 2005.

  9. Nick, that is a nice set of citations. Did you know that A(bigail) Sellen was at XRCE (Xerox Research Center Europe) before she went over to HP? I knew her more for her affordances of paper work, however, rather than research into sharability.

    Actually, these days I am more likely to balk at a verb like “make.” Eureka, which was probably the most successful Xerox effort in “knowledge flow,” did not, strictly speaking “make knowledge sharable.” Rather, it used anthropological field work to identify knowledge sharing practices that were already in place. Because these were LOCAL practices, the challenge was to expand them to a more GLOBAL scope; and the PARC researchers came up with a technology to do this (which was actually a very light-weight piece of technology).

    This is the sort experience that sends me into my rants about the dangers of ignoring the social world:

    Just about every organization already has practices in place for “making knowledge sharable,” even if those practices are not “officially” recognized. (Any organization that has none of these practices is hopelessly toxic and is going to need a lot more than knowledge management to solve its problems!) Technology should be facilitating successful practices that are already in place, rather than obsessing over introducing something “innovative.” Once those practices are facilitated, they are likely to beget more such practices; and those are the innovations that matter! This, of course, is nothing more than structurationist thinking; but I doubt that there are very many serious Giddens readers out there in the business world!

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.