March 27th, 2009

Mental Models of Commerce and Community

Commerce and community play important roles in open source ecosystems. Companies are great at building capital and targeting it towards focused goals through products and services. Communities are great at bringing together like-minded people from all walks of life and advancing their common ideals. Together, commerce and community can be an unstoppable force for turning a shared vision into reality.

That’s not to say that this dynamic duo of collaboration is always guaranteed to materialize. It takes a sufficient level of trust and mutual understanding, and a willingness to work through contentious situations with common goals in mind. I find that the mental models that people have about commerce and community substantially influence the potential value that they can realize through these interactions.

FUD Model

At the low end of trust and understanding is what I characterize as the FUD model — marked by Fear, Uncertainty, and Doubt. Here, cynicism and defensive thinking loom large. Companies are seen as soulless entities whose only reason for existence is to exploit anything and anyone to make money. Everything that a company does is viewed through this lens. For example, if a company makes an open source contribution and dares to say anything positive about it, they are subjected to an often tortured analysis that explains how their actions are really only about increasing sales with a particular demographic, blocking a competitor, casting out for free labor, or some other exclusively self-serving motive. Simpler explanations that involve corporate employees sharing a common vision with a broader community and wanting to accomplish goals beneficial both to their company and to the community are rejected outright.

Things are just as harsh in the other direction. Community members are seen mostly as naive hobbyists whose heads are in the clouds, and who couldn’t possibly be reliable because they’re not being paid to do anything. And the rest are a threat — potential or actual competitors just lying in wait to take away business or sue over any perceived infringements. The idea that a company could rely on leadership provided by the community to achieve breakthrough results is unimaginable.

Utilitarian Model

In the middle of the spectrum is the Utilitarian model. It sees past the overt cynicism of the FUD model and adopts a pragmatic mindset. It understands the conventionally-defined roles of commerce and community, and works within the limits of these boundaries. For example, enterprises adopt open source if it saves them money. Open source needs to have a business model as close as possible to that of proprietary software in order to gain customer acceptance. Open Source developers need to be managed with similar kinds of incentives and metrics to those used with proprietary software developers. A company’s success is measured by its revenue, a project’s potency by the number of lines of code.

Along with conventional wisdom, this model is often a purveyor of political correctness. For example, corporations have a burden to “give back to the open source community” as compensation for having “taken” something, independent of the observation that downloading and using open source software actually increases its ambit. Another case is where communities are pushed to develop certification schemes to assess expertise, irrespective of whether those are germane to success.

The Utilitarian model is successful at mapping the terrain and carefully working within its boundaries. The downside is that it is not inclined to challenge and expand those boundaries. People are fairly ensconced within their roles, and aren’t primed to seize creative and unconventional opportunities. Assumptions of how “corporate people” or “community people” are expected to behave can limit the recognition of teaching moments and keep people within boxes. There is also a real risk of dampening genuine passion and energy with saccharine substitutes.

Visionary Model

At the high end is the Visionary model. It sees that commerce and community each have important parts to play in realizing a shared vision. It views people holistically, as self-actualizing individuals whose journey may take them through various corporate and community roles — sometimes holding multiple roles simultaneously. These people are able to work fluidly in different contexts, tapping resources and insights from wherever is most helpful — like making use of blogs or wikis in a corporate environment, or applying project management principles with community activities. Neither calculation nor charity is an unbalancing influence on their consumption of and contribution to open source. It’s a far more natural, conversational rhythm like listening and speaking.

The Visionary model champions high levels of openness, transparency and candor as a matter of course, surpassing anything attainable by the FUD model or the Utilitarian model. There is an unshakable confidence in the power of openness to deliver innovation while developing trust. For example, a services company might share in-depth market intelligence on key customers whose adoption would put an open source project on the map in a big way. Knowing this, the community might rally to complete the development of key features, and through their contacts help the services company sign up the customers. The customers might then collaborate with each other, through the community, to make further improvements and continue the virtuous cycle.

With its broadminded perspective, the Visionary model is optimistic and resilient in the face of impediments. It’s able to protect its interests without getting trapped in the cynicism of the FUD model, and can make strategic withdrawals without surrendering to the limits of the Utilitarian model. It can make the most out of situations where an ideal solution isn’t possible.

The Visionary model holds the greatest promise for the partnership of commerce and community. It is able to navigate the shadows of conflict, and forge a strong framework for excellence.

No comments yet to

  • Hi, this is a comment.
    To delete a comment, just log in and view the post's comments. There you will have the option to edit or delete them.

  • Jon Udell

    Interesting. For a certain circle of folks, the Twitter handle can be a proxy for a universal identifier, and thus a useful pivot for metadata. And with automation like yours, you could come along later and change that — e.g. by adding alternate ids.

  • Risto

    Interesting reading Kartik. How would you see your integration and crowd sourcing approach integrated with services like twist? http://twist.flaptor.com/

    • I think that any service that wants to associate users with areas of expertise/description could benefit. So for example, a service like Twist might be able to tell not only what topics are trending, but also what types of people are talking about those trending topics. It adds another level of metadata to the mix.

  • We are alike! FTF was life-changing for me. I haven’t felt a need to read Allen’s GTD — reading the 43folders.com description and the Wikipedia article were enough to get me going. I have 43 folders on my desktop and on my Palm Pre.

  • In spite of the optimistic view that enterprises can develop internal skills to provide their own technical support for Open Source Software packages, few actually do develop and maintain those skills. Where an enterprise lacks the internal skills to provide its own professional technical support, they need to turn to support providers just as they turned to the proprietary software developers’ support teams. The Open Source Software technical support market is consistently less expensive than comparable cost of support for proprietary products but it remains a legitimate cost that most enterprises need to budget … either in a commitment of internal resources or in a contract with an external provider. Using Open Source Software without a support plan is self-insurance with a potentially large deductible as it can be quite difficult for qualified technical support staff to suddenly get engaged and come to grips with Open Source Software integrated by the enterprise. Furthermore, enterprises need to qualify their support vendors to make sure those providers actually have team members capable of supporting mission-critical software (MySQL, Apache httpd, OpenLDAP, etc.). We agree that enterprises that become internally competent achieve the benefits you suggest but most are unwilling to make the financial commitment to sustain such a capability year on year in the face of business pressures. The technical support specialists will continue to be a valuable service pool for Open Source Software much as they are for proprietary software.

    • One point that I hope doesn’t get lost here is that even IT organizations that develop internal competence can contract effectively with open source technical support specialists. As I mention:

      “They identify where they want to be treated as a customer, where they want to interact as a peer, and where they want to play a leadership role.”

      Compared to dependent IT organizations, interdependent IT organizations can make better use of the talents of technical support specialists, since they have a deeper understanding of the value that those companies provide.

  • Well-put, Kartik! Marty offers a realistic, pragmatic reply. However, I’m seeing my employer dabble with the model that Kartik describes. Our Open Source & Linux Profession (OSLP) runs several development services that benefit our corporation. None of us doing this for the OSLP are IT workers, but we have had conversations with IT. Let’s say that they’re “intrigued” at this point. Could take years. Developing…

  • Kelly Haviland

    Great article Kartik. I think this is a great model. I have seen the power of open and collaborative IT development in my own experience. Unfortunately, I have also seen the difficulty in getting organizations to change their mindset and be open to this kind of approach. It can be done though, it just takes time and some level of trust building. I think the key is to just give it a shot and use small successes to pave the way forward.

  • John Anthony

    Kartik – I like the use of Covey’s model as a way of describing the effect on behaviors (or perhaps the required behaviors) of those that participate in Open Source Software development. Many of the points made here, as you suggest, apply well to the concepts of Open Innovation and may result in similar beneficial outcomes. Nice work.

    Likewise, Open Innovation and Open Source share many challenges. In particular, if the decision makers sitting higher up in the food chain are not themselves interdependent, then the ability for folks in lower levels to participate in open models is significantly constrained. In my mind, a key catalyst to moving IT organizations (and others) into a more open mindset is through a top-down approach. There needs to be active encouragement, rewards, and a clear support structure (e.g. support for experimentation, failures, etc.) for folks to “participate” and embrace open principles. Otherwise, the reward system is not aligned with the model presented here and interdependence remains remains relegated to corporate statements.

  • Great connection to Covey! There is a growing attention in the open source field for the human factor in decision making on open source applications in enterprises. Which is good. Because it is complex to get a yes for Open Source in situations where it can add value. As an Open Innovation Ambassador I have to admit that there is lots of organisations where Open Source Application and its services suppliers network (if any) is not suitable at present.
    In cases that we do have a great Open alternative to Closed Environments we have to be patient indeed. We can tell them, we can show them, they will see it, they will hear it, but in the end it is what people believe that makes the difference. Open Source has not yet come to the point that decision makers and IT directors feel backed by the currently available software, the infrastructure and services suppliers. System integration in Open Source sucks big time, if I may be so blunt. There is more. If all the worldwide available Open Source service suppliers would have to service 1% of the enterprises worldwide, we would run short on capacity quickly. It is no use blaming decision makers as long as we ourselves (the Open minded) focus only on the positive effects of Open Innovation.
    But we are getting there! Let us shift our attention more towards customers concerns about Open Source. These issues go way beyond software features, staffing and hiring suppliers: e.g. Total Cost of Operation, how to sell it to the boss, smooth integration, network of suppliers, training, and … building trust.

  • Using open source software is becomming an industry standard, however the most basic questions remain. That is compatibility of various open source licenses, and this is a very big legal issue. Let’s take for example an IT organisation, downloaded a sourcecode with a GPL component or licensed with GNU GPL. Now to make the required innovation it requires an EPL component or licensed using Eclipse Foundation’s EPL. The innovation will not be possible since EPL and GPL are not compatible licenses, meaning that the GPL license conditions are breached and that the originator of the GPL license can sue your organisation.

  • It made me cry. So many dreams, so many failures, is there really a company out there that can get past the crud and collaborate successfully? If so, hire me.

  • [...] I Interdependent ? By brunocornec Reading the brilliant article that Kartik Subbarao wrote recently on Open Source and Interdependent IT , I was questioning myself [...]

  • Well written, well developed, well presented thesis, Kartik. As some of my peers on the HP Open Source and Linux Profession leadership team (past and present) have already mentioned, this resonates with our own experience. I experienced a particular moment of recognition in reading your description of the limitations we place on ourselves by reducing all decisions to monetary ones. Many of us in business will identify with the general Catch-22 mindset that says “We can’t develop this capability for the marketplace because there’s no demand, hence, no business justification, no future revenue stream”. (The obvious Catch-22 here is there’s no market because we haven’t developed the products(s) that would helpcreate, or at least grow the market.)

    I hadn’t considered the Open Source model from this point of view (interdependence) before, but like so many other ideas that weave the fabric of this development model it seems intuitively obvious in retrospect. I suppose another aspect of this I find personally appealing, if occasionally frustrating, is that it reinforces the notion that this is a marathon, not a sprint. It’s a continuum that individuals and IT organizations alike can position themselves along at any given point in time, and change only infrequently appears to happen quickly. But change is the only true constant, and it’s inevitable given sufficient time. We’re making inroads with our own IT organization that will bear fruit, and I suspect we are approaching a tipping point. I’ll keep my fingers crossed.

  • Gaurav Agarwal

    A good model indeed! … Looking at your Dependent-Independent-Interdependent model, it reminds me of a line… “We are taking apart each task and sending it…to whomever can do it best… and then we are reassembling all the pieces.” – from Thomas Friedman’s ‘The World is Flat’. I’m trying to related it to the “Bottom Up” approach this book talks about. Having said that, I worry how so many versions and licences of a open source software (OSS) is maintained and integrated as rightly pointed out by Ian Vernon in his comments. What’s your take on that? What should be any IT organization’s considerations (benefits and losses) before thinking about OSS as a long term strategy if not immediate? Will you agree that any big organization (already having vendor relationship) should not go for OSS in entirety but only where required as this may take some time to mature?

    • > Looking at your Dependent-Independent-Interdependent
      > model, it reminds me of a line… “We are taking apart
      > each task and sending it…to whomever can do it
      > best…and then we are reassembling all the pieces.”
      > – from Thomas Friedman’s “The World is Flat”. I’m
      > trying to related it to the “Bottom Up” approach this
      > book talks about.

      Yes, I agree that Tom Friedman does an excellent job of
      explaining the emerging realities and possibilities of
      the flat world. In fact, this same
      delegation/specialization model is very common to Unix,
      Linux and many other other open source projects. Good
      interfaces defined by open standards, with each component
      focused on its particular job, integrated effectively
      across the board.

      >Will you agree that any big organization (already having
      >vendor relationship) should not go for OSS in entirety
      >but only where required as this may take some time to
      >mature?

      I don’t think that open source is an all-or-nothing
      proposition, and can certainly be implemented as a phased
      approach. Adopting interdependent, open ways of working
      throughout the areas of people, process, technology and
      business is the broader goal. That will naturally
      translate into a strategy of preferring (and contributing
      to) open source software, but proprietary software can be
      part of the mix too, if its value is well-understood.