The OSS co-op business model

A co-operative is a member-owned business structure with at least five members, all of whom have equal voting rights regardless of their level of involvement or investment. All members are expected to help run the cooperative.”
Small Business WA.

The co-op business model has fascinated me since doing some tech projects in the dairy industry in the deep distant past. The dairy co-ops empower collaboration of dairy farmers where the might of the collective outweighs that of each individually. As the collective, they’ve been able to establish massive processing plants, distribution lines, bargaining power, etc. The dairy co-ops are a sell-side collaboration.

By contrast open source projects like ONAP represent an interesting hybrid – part buy-side collaboration (ie the service providers acquiring software to run their organisations) and part sell-side (ie the vendors contributing code to the project alongside the service providers).

I’ve long been intrigued by the potential for a pure sell-side co-operative in OSS.

As we all know, the OSS market is highly fragmented (just look the number of vendors / products on this page), which means inefficiency because of the duplicated effort across vendors. A level of market efficiency comes from mergers and acquisitions. In addition, some comes from vendors forming partnerships to offer more complete solutions to a given customer requirement list.

But the key to a true sell-side OSS co-operative would be in the definition above – “at least five members.” Perhaps it’s an open-source project that brings them together. Perhaps it’s an extended partnership.

As Tom Nolle stated in an article that prompted the writing of today’s post, “On the vendor side, commoditization tends to force consolidation. A vendor who doesn’t have a nice market share has little to hope for but slow decline. A couple such vendors (like Infinera and Coriant, recently) can combine with the hope that the combination will be more survivable than the individual companies were likely to be. Consolidation weeds out industry inefficiencies like parallel costly operations structures, and so makes the remaining players stronger.

Imagine for a moment if instead of having developers spread across 100 alarm management tools, that same developer pool can take a consolidated 5 alarm management products forward? Do you think we’d get better, more innovative, more complete products faster?

Having said that, co-ops have their weaknesses too.

What do you think? Could such a model work? Would it be a disaster?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

2 Responses

  1. Interesting question Ryan. According to Geoff Riley (who has a fantastic website about economics http://www.tutor2u.net) there are 4 main modes of co-operation in markets:
    1) Joint ventures. Nokia Siemens Networks and Sony Ericsson are examples in telecom technology. JVs are often an alternative to a merger or acquisition. In both cases one of the partners ultimately bought the other out. On the operator side, mobile network sharing would be a good example.
    2) Industry standards. ETSI, IETF, ITU, etc. These have served the industry well in the past but are now seen as too slow moving.
    3) Open source. This is the flavour of the moment with projects like ONAP and OSM being front of mind. Linux is the key success story in OS.
    4) Co-operatives. Works for dairy farmers. Not sure it would work for telecom tech. Perhaps the closest thing in telecom is handset purchasing clubs across operators and other group buying associations. This strays into the trade body territory – organisations like GSMA. Another good example is CableLabs which is a successful pooling of R&D efforts across operators. See this article:
    https://www.cablelabs.com/cablelabs-innovation-series-transforming-ideas-into-solutions

    But to answer your question about the 100 different alarm management tools being an inefficient use of resources, normally market forces lead to consolidation around a small number of solutions. That is the case in smartphones, mobile infrastructure, ERP systems and many areas of technology. If a market remains fragmented it must be because there are not significant economies of scale because the solutions have a high level of human-delivered services attached perhaps for customisation and integration. Plumbing and hairdressing are fragmented industries; social networking and search engines are not because they exhibit high network effects (winner takes all) and are very scalable (little incremental human effort or additional cost required to grow).
    Telecom is naturally a scalable business with high network effects; it is the result of regulation that telecom is fragmented and barely covering its cost of capital.

  2. Great stuff James. The exact type of well-thought-out opinion I was seeking.

    Geoff Riley provides a great list. I’d probably add a fifth one (perhaps similar to JV), which is Partnerships, where 2-3 vendors get together on specific opportunities (eg an assurance-fulfillment-inventory RFP is issued by a telco, so 3 entities partner to bid as one because they each specialise in assurance, fulfillment and inventory respectively).

    On item 4), yes there are buyer-side co-ops that I’d excluded from my blog (intentionally excluded, as I have some thoughts / experiences that I’ll include in a future blog…. probably).

    Your CableLabs example is a really good one. With projects like SNAP, they’re almost venturing into collaborative OSS.

    There are lots of elements to unpack on your sentence, “If a market remains fragmented it must be because there are not significant economies of scale because the solutions have a high level of human-delivered services attached perhaps for customisation and integration.” I’d like to split OSS into two parts – products and project delivery.

    The products side “should” be largely repeatable (ie economies of scale). Most customers around the world have a similar set of key use cases that allow the core of the products to be re-used by many. In this case, one effort can be re-used / re-sold many times (unlike a hairdresser or plumber).

    The project delivery side is only partially repeatable. Every customer has a different configuration (and often product customisations) to meet their particular needs. This definitely has elements of the hairdresser and plumber to it.

    The mindsets required for these two sides are very different and OSS sellers (vendors / SIs) tend to be much stronger at one or the other. Rarely both.

    It seems to me that there is great opportunity for consolidation on the product side, particularly at the smaller end of the scale. It seems ripe for co-operatives to thrive… to persist beyond single opportunities like the Partnership model and conduct joint R&D (eg conjoined feature development, integrations, etc). When you start adding “new” OSS specialisations such as analytics, machine learning, virtualised networks, etc the multi-partnership model appears even more attractive.

Leave a Reply

Your email address will not be published. Required fields are marked *

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