The Marketecture of Community

Socrates argued that the unexamined life is not worth living. For the past decade, the two of us—along with many colleagues, organizations, and commercial firms—have been immersed in the booming, buzzing confusion that is the community landscape of higher education. We have communities that build software (e.g., Jasig, Kuali, Moodle, Sakai), communities that buy together (e.g., Internet2, Net+), and communities that create services unique to the academy (e.g., Digital Preservation Network, DuraSpace, HathiTrust).¹ Some of these communities are thriving as they solve common institutional problems, whereas some remain short of their aspirations. For others, it is still far too early to discern if they will reach critical mass and succeed.

"Community"—an approach that has benefited many institutions around the world—has also been a fascinating place to dwell professionally. But as we look to the future, we find ourselves confronted by Socrates' admonition and by the growing number of challenges in the higher education environment. The 2008-9 global financial crisis reduced public funding to colleges and universities; higher education is increasingly viewed as a privately financed good; the much-discussed student debt crisis is a continuing concern as a demographic wave has shifted public interest from education to health care and dying; and most notably, new educational models are proffering innovative and less-expensive alternatives for some types of education. Collectively, these challenges are causing major shifts in the economics of higher education.

We must find ways to be more effective in solving the problems that face us all. Communities can be an essential part of the solution. But how do we know which type of communities will provide sustainable value toward addressing these common challenges? When should we start, or end, a community? Is there an architecture that will enable the creation of strong and vibrant communities—that will provide the foundations, girders, and crossbeams to structure such communities in the marketplace of ideas? And are there times when the development of communities simply isn't worth the hard work and effort? After all, we know that creating and growing communities requires considerable time and energy. Participants can be both passionate and fickle. The successes can be amazing, and the disappointments can be profound. Exploring the marketecture of community can help answer these questions.²

The Structure of Community

The term community, by definition, implies more than one participant. We often use it in very broad strokes: the higher ed community, the vendor community, the library community, the open-source community, the Moodle community. But what makes a community, and what stickiness binds its participants together?

The Partnership Imperative

The economic and productivity challenges confronting colleges and universities (e.g., debt crisis, declining public support, flattening research investment) are on a scale that eclipses any single institution. If previous decades were defined by institutional competition over everything, the shift now is to judiciously compete in some areas (e.g., for the best students, faculty, grants) but to cooperate in other areas (e.g., for cost reduction through economies of scale, business simplification, better learner analytics, large-scale contracts and grants, alliances for local and international education). Cost and productivity pressures necessitate a new approach, and institutional success increasingly depends on picking the right set of partner institutions.

The veracity of this "shared fate" perspective is even more apparent for institutional investments in information technology. To be sure, the quality and the cost of implementing essential systems vary, but competitive advantage or even comparative advantage, the sine qua non of strategic decision-making, is rarely tied to how a utility IT system is implemented. And from an industry cost perspective, the competitive approach among institutions has failed miserably: ten years ago, Robert B. Kvavik and Richard N. Katz conservatively estimated that institutions had spent $5 billion on the first round of big-system investments.³ In the absence of working together effectively with any real intentional interdependence, institutions have seen pricing and implementation costs skyrocket as each institution negotiates one-off contracts, pays consultants to help implement the vast complexity, and discovers anew the pitfalls of implementing systems in isolation.⁴ Where is the financing today to repeat the $5 billion payment for aging systems and for remedying, yet again, inefficient business processes? Benjamin Franklin may have provided sage advice for IT leaders in an era of diminished resources: "We must all hang together, or assuredly we shall all hang separately."

Cooperate or Collaborate?

If these new economic conditions drive greater intentional interdependence for some kinds of IT services, then how should we work together? Though the terms cooperate and collaborate are frequently used interchangeably, they are actually useful labels for distinct motivations and behaviors.

Cooperation essentially boils down to agreeing to abide by a set of common rules or principles. Chess players cooperate around the agreed-upon rules of the game even as they compete vigorously to determine who wins. Similarly, members of Sam's Club engage in cooperative buying when they agree to a set of membership rules that convey market advantage to the Sam's Club wholesale buyers. At the extreme, agreeing to abide by the principle "I won't hurt you if you won't hurt me" is an example of cooperation. Cooperation is common, it is easily documented, and it has a long time horizon.

In contrast, collaboration requires a greater level of engagement and goal alignment. Successful collaboration involves aligning around shared objectives and actively working together to pursue those objectives. Passive collaboration fails. Unbalanced collaboration, in which participants bring different expectations and relative resource commitments to the endeavor, also fails. Collaboration requires an intense and continuous focus on purpose and investment. And when priorities change, collaboration likely ends—a fact not to be mourned but simply to be recognized as part of the life cycle.

The distinction between cooperation and collaboration means that development and shared service communities can be classified into two basic types: communities of cooperation and communities of collaboration.

Communities of Cooperation. Communities of cooperation are formed around shared principles and/or shared aspirations, but individual members fundamentally retain their autonomy. User groups, professional associations, and institutional associations such as the Committee on Institutional Cooperation (CIC) are examples of cooperative communities. Similarly, Apache, Drupal, and Moodle are examples of thriving, cooperative software-development communities. In each case, the members of the community share an aspiration—for example, bringing greater efficiency to and coordination between institutions, in the case of the CIC, or improving a learning management system (LMS), in the case of Moodle—and are bound together by an emergent membership culture, agreements, and routines. Cooperative communities can last a very long time.

Communities of Collaboration. In contrast, communities of collaboration are bound together by a shared and fairly specific vision. Participants in communities of collaboration embrace intentional interdependence as instrumental to their individual success. These communities are built on principles of shared investment and coordinated action to achieve mutually desired outcomes within a known period of time. Collaborative communities require members to limit their autonomy in the interest of directed action to pursue shared goals.

Collaborative communities come in many forms. For example, multi-institution research teams assemble to compete for grants funded by the National Science Foundation (NSF) or the National Institutes of Health (NIH); the collaboration lasts only as long as the specific goals and funding are in place, though the fruits of the work and relationships may live on. Community source projects such as the Kuali Financial System are created and sustained by a charter and governance structure that explicitly sacrifices individual developer autonomy in favor of clearly specified and coordinated roles (e.g., functional council, executive board, technical council). In shared-services projects such as the recently launched Digital Preservation Network, participants trade autonomy in the interest of building a jointly owned and managed preservation network. In each case, laissez faire local activity gives way to directed, collaborative activity for a specified period of time.

Community Ingredients

Whether cooperative or collaborative, all communities are made up of several key ingredients, including goal alignment, sufficient resources, and shared values.

Goal Alignment. Communities are formed and sustained through explicit and tacit shared goals. Goals are necessarily plural, since few communities form with 100 percent buy-in to a single, unified goal. Local institutional imperatives necessarily shape the ability to invest limited time and resources. For example, HathiTrust was formed to serve an economic goal as a digital repository for copies of Google-scanned books that were provided to participating institutions. In the absence of the HathiTrust community, each institution would have had to invest in its own software and storage mechanisms for the extremely large digital book files. Beyond the economic argument, however, the goal of providing access to knowledge is part of the mission of colleges and universities. HathiTrust investors and participants valued a social goal via the ability to make millions of volumes of out-of-copyright works freely available to the world. Others may have valued an affiliation goal to essentially "buy an option" for the future and be part of a group of prestigious institutions.

Explicit goal clarity is sometimes illusive during community formation, however. For example, in the late 2003 formation of the Sakai Project community, Indiana University, MIT, Stanford University, and the University of Michigan devised plans to build a community-source LMS that would be suitable for large-scale use. The institutions were well into the first year of work before one founder clarified that the institution's real interest was to build a layer of middleware for connecting various campus tools rather than building a full-feature LMS.

Sufficient Resources. Sufficiency of resources is a second key ingredient for developing successful, thriving communities. Community resources come in many forms: volunteer talent, institutionally assigned staff who work on a community project for their day job, cash investments, in-kind resources, and/or commercial support. Sufficient investment enables stickiness and a shared belief in a community's ability to achieve common goals. An absence of resources may prove fatal. For example, tens of thousands of open-source projects at SourceForge remain stuck, if not fully abandoned, due to a lack of resources. The march of technology moves on and can ultimately render good efforts moot due to a lack of resources to advance them further.

Shared Values. Third, communities need some minimal shared values to hold them together. For example, the Kuali Foundation was formed with a shared value of "member equality" with common rights and privileges afforded to colleges, universities, and commercial firms. This value of the Kuali ecosystem is formally affirmed in the legal bylaws of the foundation, and at least one seat on the Kuali Foundation's board of directors must be held by a commercial member elected by the members. Yet even with this "member equality" community value, there is a very strong set of shared assumptions regarding what kinds of communications are suitable over the community's e-mail and wiki services. Commercial marketing is a community no-no, and those who step across the line get a quick reminder of the community's values.

Software licensing is another means for a community to define and express shared values.⁵ When members of a community labor together to create software, documentation, data models, and so forth, who owns these products and under what conditions may they be used, repurposed, combined, or sold? This topic becomes particularly interesting for service-providing communities like HathiTrust, Internet2's InCommon, or Kuali Ready. Each of these communities develops software, but members pay annual subscriptions to receive cloud-based services. Should the software also be freely available to anyone, including nonmembers, for any use? What about add-on modules developed by members of the community? Diverging views on openness, perceived fairness, profit, and control can sometimes make software licensing a proxy debate for deeper disagreements that can threaten the essential stickiness of a community.

Sustaining Collaboration and Cooperation over Time

Although cooperation and collaboration share variants of these key ingredients, changes in the blend of ingredients may lead to periods of transition during which collaborative projects become cooperative or vice-versa. Since collaborations require more effort to sustain, a shift in goal alignment, resources, or values is likely to weaken the intentional interdependence and time objectives. This may cause an intentional shift or natural drift to cooperation. Likewise, goals, resources, and a time imperative may create an episodic collaboration within a community of cooperation.

Consider, for example, the history of Internet2, which has gone through several distinct organizational phases. In the founding phase, it was a highly collaborative project among thirty-four research universities. These institutions joined forces for a very specific, shared strategic purpose: building a high-performance network owned by and operated for the academy. Each institution sacrificed a degree of institutional/regional network autonomy in the service of creating a shared national backbone. Their efforts were highly successful. Today Internet2 has approximately two hundred members and provides network access to thousands of institutions. Along the way, though, the intense focus on strategic alignment among a growing number of members started giving way to a more commoditized view of a general-purpose network. Internet2's mix of key ingredients shifted from a collaborative community to more of a cooperative community. Access to a more commodity-like network trumped the initial goal for research-enabling performance as more members with less-specialized needs joined. Their goals put pressure on Internet2 to focus less on the research side of the equation and more on the customer service and cost reduction side of the equation. Eventually, the tension became so strong that a subgroup of universities formed National LambdaRail (with Internet2 as a member) as a new collaboration with a shared goal to return to a focus on an alternative high-performance network for advanced research uses. That move led to an intense period of self-examination within Internet2 and its research university members, eventually resulting in a new governance structure that again placed a premium on collaboration around a shared strategic purpose for advanced networking. This is evidenced in the recent announcements about the Innovation Platform with 100 Gigabit services. Even though Internet2 continues to serve many customers, it is governed by the research-intensive universities and their shared strategic priorities.

Likewise, the Sakai Project was officially launched in early 2004 with a $6 million collective investment from four institutions and a grant from the Andrew W. Mellon Foundation. That collaboration grew to more than one hundred institutions as the software matured with known and committed resources. In more recent years, the community has continued to develop the software through a cooperative community with episodic bursts of pooled investment and shared goals for periodic enhancements.

Since collaboration requires continually aligning and investing around ever-evolving, shared strategic goals, collaborative communities are naturally more rare and more transient than cooperative communities. Collaborations last only as long as the tradeoff between autonomy and collective action pays off for the community members. A change in goals or vision among the members of a collaborative community can easily shift behaviors to cooperation—or even to dissolution. This is neither tragic nor unexpected but is, rather, a natural part of the life-cycle of collaboration.

In sum, the economic challenges facing higher education necessitate that institutions work together to obtain benefits that are available only at the scale of multi-institutional engagements. Communities of cooperation and communities of collaboration provide two distinct means to achieve those goals.

The Marketecture Matrix

What makes community approaches unique from other choices, and how might institutions best assess which approach is right for a particular need? The Marketecture Matrix (see Figure 1) can help answer those questions. The two axes, authority and influence, define four quadrants, or archetypes, with a view from the lens of an institution of higher education.

Authority and Influence

Oliver Williamson shared (with Elinor Ostrom) the 2009 Nobel Prize in Economics for his work in arguing that markets and ownership are alternative means to resolve conflicts. For example, if Ford needs batteries for a new model of car, it could seek those batteries from sellers that offer the particular specifications that Ford requires. There would likely be negotiations regarding price, warranty, service-level agreements, liability, and similar issues. Offers to buy and offers to sell provide a means to resolve conflicts, and through negotiation in a vibrant marketplace, Ford could likely fill its need for batteries.

In contrast, Ford might decide that it needs greater control over battery design for its new model or that it needs to develop its own understanding of batteries due to their growing importance for electric vehicles. If these conflicts are not suitably resolved through the marketplace, Ford may choose to resolve them through direct ownership of a battery-production facility. It might invest resources and operate the facility on its own, or it might create a joint venture with another firm that Ford views as non-competing as a means to share some of the cost, risk, and potential reward. Direct ownership provides the authority to resolve conflicts in favor of the interests of the owners.

The horizontal axis of the Marketecture Matrix—authority—expresses Williamson's means of resolving conflicts via (1) the decision authority of a marketplace of buyers and sellers or (2) the ownership authority of a community. A community is a means for colleges and universities to exert the privileges of ownership to resolve conflicts as they see fit. For example, Kuali participants have sometimes expressed (only half-jokingly) this value of collaborative communities as the golden rule: "You bring the gold, you make the rules." In contrast, most privately owned firms that sell software and services retain the ultimate privilege of ownership. They set prices, limit use via licenses and seat counts, support costs, and choose when to drop specific products or versions of software and services to suit their goals. Ownership conveys the authority to resolve any customer or profit conflicts in their favor.

The vertical axis of the Marketecture Matrix expresses influence. Although authority can be decisive in resolving conflicts, those choices may be subject to some degree of institutional influence. For example, a multi-billion-dollar global publisher of journals may not feel much pressure if a small, isolated campus expressed concern regarding price or technology-integration features. The same publisher may be more responsive, however, if the vast California Digital Library or the Association of Research Libraries (ARL) pushed hard for some change.

Matrix Archetypes

The four quadrants of the Marketecture Matrix present four archetypes that describe models of varied authority and influence for obtaining essential software and services. Each archetype is described below from the point of view of institutions choosing if or how to participate in a model.

Solo Contracts. Solo contracts are the most frequent approach to IT services. They usually follow highly familiar procurement routines within an institution, such as committee formation, Requests for Information, vendor presentations, Requests for Proposal, evaluations, two-party negotiations, contracts, and ultimate implementation and use. For many institutions, the routines of solo contracts are deeply engrained as the default way the institution solves problems for needed software or service. This quadrant provides relatively low authority to resolve conflicts in the institution's interest and also relatively low influence, since the institution is just one customer in a marketplace. This is evidenced when even very large and prestigious institutions have little-to-no ability to influence a large seller.

The distinguishing feature of this archetype is an institution's independence in designing the process, means of market engagement, timing, and ultimately in choosing to accept negotiated terms. The solo contract consumes large amounts of institutional energy and is a very expensive selling process for a firm. Its prominence is based on the belief that it will allow the institution to choose "the best" product or service for a particular need. Yet industry observers question this laborious process when it repeatedly yields different conclusions for inarguably common needs like an LMS, financial management system, or student enrollment system.

Although contracts are usually one-to-one, solo contracting can also demonstrate elements of communities. For example, Oracle/PeopleSoft has long had a vibrant and highly connected Higher Education Users Group (HEUG) that shares information and best practices and provides some influence for product direction. The stickiness of this type of community is anchored in large institutional investments in a particular product and in a desire to benefit from the experiences of others. The activities (e.g., sharing code) of those communities may be constrained under the authority of the software or service owner.

Finally, innovation may be one enduring advantage of solo contracts. When a market is immature, and conditions are not yet right for sellers or buyers to establish broad deals, one-off experiments or pioneering trials that have exceptional support from both the buyer and the seller can prove enlightening for market development. Examples include Duke University's agreement with Apple to provide 1,650 freshmen with iPods in 2004, Arizona State University's move of student e-mail to Google in 2006, and Indiana University's deals with major publishers for a new e-text fee model in 2011.⁶ Each of these helped refine the terms for broader adoption, mimicking the wisdom of an oft-cited African proverb: "If you want to go fast, go alone. If you want to go far, go together."

Buying Clubs. Markets are most efficient in resolving inherent buyer and seller conflicts when there are a large number of buyers, a large number of sellers, near-perfect information, and low switching costs. The seller side of many essential software systems for higher education has consolidated over the past decade and yielded fewer, stronger sellers in the market. JD Edwards and PeopleSoft are now consolidated as Oracle; Prometheus, WebCT, and Angel are now consolidated as Blackboard; Datatel and SunGard Higher Education are now Ellucian; and Addison-Wesley, Benjamin Cummings, Prentice Hall, and others are now part of Pearson.

This marketplace imbalance of fewer sellers and many buyers has motivated a range of "buying clubs" among colleges and universities to rebalance a more efficient market. Examples include the strategic procurement initiative of the Council of Australian University Directors of Information Technology (CAUDIT) and the procurement activities of the CIC. Buying clubs can also aid sellers by simplifying procedures for pricing and terms, but many Buying Clubs still use the familiar one-to-one contracting mechanism between an institution and a seller using pre-negotiated prices.

The rise of cloud computing via fast networks offers a dramatically new approach for buying clubs to function as vibrant communities while also bringing new efficiencies to both institutions and sellers. The logic and means for institutional demand aggregation for cloud computing is clear,⁷ and now Internet2's Net+ Services is rapidly enabling that aggregation as a new form of buying club. Notably, the contracting arrangements for Net+ align to a new logic that blends the authority resolution of the marketplace with the greater influence achieved through aggregation. Net+ contracts are executed as a detailed master agreement between a service provider (e.g., Box.com, Courseload.com, Instructure.com) and Internet2. The institutional members of Internet2's InCommon service can then easily opt-in using a simple contract with Internet2 for the uniform set of terms and conditions. As an aggregated community, the institutions have collectively much stronger influence in the marketplace via the Internet2 Net+ service than with a solo contract. All agreements are nonexclusive, so institutions and sellers remain free to execute any other contract that is in their mutual interest.

The Net+ experience for cloud services is challenging the wisdom of that African proverb, since negotiating solo contracts for each institution can be infuriatingly slow for both sellers and buyers. For cloud services, the only means of going fast may be to go together in buying clubs like Net+.

Cooperative (Open Source) Communities. A shift to the right quadrants in the Marketecture Matrix is a move toward greater authority and ownership rights. Writing "homegrown" software or operating local services certainly affords absolute authority, but the scale of many software needs is beyond the investment abilities of most colleges and universities—thus the attention on community approaches to greater authority via shared, but severable, ownership.

Despite its pervasive use, the term open source is often confusing because it is used in two ways that have quite different meanings. The canonical use of the term open source is a statement about the intellectual property status of software code. Used this way, open source means that the code is free to be reused, repurposed, and redistributed for any reason and by anyone. Many open-source projects use one of the approved Open Source Initiative licenses that enable walk-away rights and reuse of the software—thus approximating the authority of ownership. More recently, some approved licenses have added new restrictions for reuse of software in commercial cloud-service providers.

But there is a second way in which the term open source is used. It can also be used to describe the method of community production (rather than the rules for the intellectual property status of the resulting code). When people talk about developing open-source code, the production method they usually have in mind is one that relies on the largely independent efforts of many developers. Just as the ultimate success of bake sales depends on the individual contributions of many cooks, open-source projects depend on individuals to volunteer their time and expertise—sometimes supported by employers—to add features and improve the software code. The work of these developers is largely self-organizing as they individually set priorities via cooperation with minimal direction. Typically, the work is submitted, and once sanctioned by some community-created governing group or individual(s), it is then included in the next release of the software, even though it may be visible and available long before it is packaged into an official release.

By design, open-source communities have both producers and consumers of software. Each community develops its own culture for goals, resources, and values. Anyone can consume (use) the software, with no engagement whatsoever with a community. Licensing rules ensure that community-work products are freely available to anyone. Some consuming institutions may additionally choose to invest as producers to further refine the software for their needs and with the hope to share their enhancements. Open-source communities have also evolved very sophisticated processes for resolving internal community conflicts (e.g., choosing which code to use in the official release or deciding when a new version will be released).

Cooperative open-source communities have a distinguished and rich history as a proven means to create, maintain, and enhance software—particularly in the lower levels of the software stack.⁸ Open-source infrastructures like Linux and Apache are widely used by both corporations and educational institutions. Open-source software is ubiquitous, and almost every institution makes some use of it. Apache, Drupal, Linux, OpenCast, and uPortal are all excellent examples of this form of open-source production.

Institutional influence in this method of production is quite low, and that includes direct management for the timing of new features to be part of an official release with the benefit of quality-assurance testing. Although a governing body may set the direction, achievement of that direction is dependent on the action of loosely coupled individuals. Indeed, the distinguishing feature of cooperative open-source communities is often, though not universally, their reliance on a meritocratic culture driven by individual software developers. Openness implies a meritocracy of ideas and code enhancements for software improvement performed by those who are most technically capable of doing so.

The cooperative open-source model works especially well when the market for the software is large, such as for infrastructure software that spans many industries. Companies and institutions sometimes subsidize open-source software community resources by enabling paid staff to invest some or all of their time on community-directed work. Other resource investments may take the form of volunteers or commercial partnering models, such as Moodle, where 10 percent of earnings are invested in sustaining the software.

Collaborative (Community Source) Communities. Some institutional needs are unique to higher education, and some serve only a small subset of institutions. For example, sophisticated research administration software to manage complex grants and repository software to enable digital preservation at libraries are not needs that span broad industries. These boutique needs, especially those with demanding timelines for essential feature releases driven by institutional compliance, may best be addressed through a community model with elements of both higher authority to resolve conflicts and higher influence to shape timely community outcomes.

The collaborative community-source model blends elements of both corporate-style software-development projects and open-source individual cooperative development. Investing institutions shape goals, resource commitments, and values through a project charter. Investors may also include corporations and individuals. Since both cooperative open-source and collaborative community-source models often share the same software licenses for intellectual property and openness of work products, the distinguishing difference is the role of influence in directing software production and community outcomes.

In collaborative communities, influence is strongly related to resource investments, but even these communities have a meritocracy of influence based on skill and expertise. That relative influence spans all roles of a project including its executive sponsoring board, the functional experts who define a system's requirements, and the developers who use their expertise to design and code the software. The level of resource investment per institution may vary from small to large and may change over the life of a particular collaboration. For example, the Kuali Financial System was created in 2005–2009 by investments of cash and staff from six institutions and a grant. It is freely available under an open-source license, and now ten institutions and one commercial firm provide ongoing investments of cash and staff to influence the evolution of the community-owned software.

Two obvious questions arise: Why invest in a collaborative community to pay for "free" software, and isn't it unfair that "free riders" can use the work of paying institutions without cost? The answer to both is that communities exist and thrive because they are a means to achieve institutional goals, and influence is the goal for investors. For the eleven sustaining members of Kuali Financial, their investments represent less than they would have paid through other software models, and they gain both influence and authority. This situation is no different from when institutions pay for conducting research that may be read by others without fee. The "Tragedy of the Commons" remains a threat if everyone wants to be a free rider, but as Elinor Ostrom proved with her work (for which she shared the 2009 Nobel Prize in Economics with Oliver Williamson), communities demonstrate vibrant self-adjustment to avoid that tragedy.

Collaborative community-source production has a far greater reliance on institutional investment to influence and direct a project. This greater level of institutional resource investment means that holding the collaboration together for directed goals over a defined time period is more difficult than in models of cooperation. The value for this work of intentional interdependence involves a community-developed (e.g., broad expertise) and predictable timeline for software and service features. These collaborative communities, through their directed influence and known timelines for software or services, can be extremely valuable for institutions. But since they are harder to sustain over time than solo contracts, buying clubs, or cooperative open-source models, institutions should use prudence in choosing which of their needs merit creating and sustaining communities of collaboration.

Straddling the Archetypes. The world rarely fits neatly into 2x2 matrices, and the marketecture of communities is no different. The archetype quadrants define the four blends of authority and influence, but some practices straddle multiple quadrants to represent other blends. For example, a buying club of institutions might influence favorable terms for the commercial offering of software produced by an open-source and/or community-source project. For example, the community colleges in a state might create a buying club that buys a Software-as-a-Service (SaaS) version of Sakai from a commercial firm that both uses the open-source Sakai software and utilizes open-source Linux, Apache, and uPortal. In this model, the community colleges could have disproportionate influence, via their aggregation, that may also include some commercial contributions of software development as part of the communities. They buy from a marketplace of multiple commercial-support offerings, yet they have the authority of ownership of the community software should they ever need to part ways with one firm for another services provider.⁹

The Reality Triangle. Institutional leaders want inexpensive projects that do everything they desire and are available yesterday. Experienced project managers know, however, that a Reality Triangle (see Figure 2) operates as an immutable law of nature in the inherent trade-offs between resources (cost), scope (features), and time: only two of the three can be controlled. For example, if an institution needs a project (e.g., software, content, system rollout, service) that does many things (large scope) and is ready now (short time), then it has little control over cost (which will likely be high). If it needs a project very soon (short time) and very cheap (low cost), then it has little control over scope (which is likely to be small).

Interestingly, the archetypes in the Marketecture Matrix align with specific trade-offs that are well known in the Reality Triangle. For solo contracts, institutions have some control over scope/features and timing, but owners of the software and services determine the costs at which they are willing to offer those features and timing. For buying clubs, institutions have some control over timing and resources/costs, but providers—especially cloud providers—choose the features they will offer. For cooperative communities, institutions have some control over features and costs, but timing is unknown. Finally, institutions in collaborative communities, as owners with high authority and high influence, have the greatest range of choices. They can choose to invest more resources, reduce scope, or extend time, and they can make those tough choices with a full understanding of the Reality Triangle constraints.

The Marketecture of 2020

Although the solo contract quadrant (low authority, low influence) has long dominated institutional strategy for obtaining software and services, there should be no single, default sourcing strategy for this decade. Many colleges and universities benefit from the growing and vast connectivity capacities of Internet2 and the Regional Optical Networks, and these networks connect institutions to new possibilities for software and off-premises cloud services via buying clubs, cooperative communities, and collaborative communities. The advantages of these refined models will quickly overwhelm the historical advantages of solo contracting for most institutions and firms.

Yet colleges and universities face great institutional inertia in adapting to models of intentional interdependence. The structure of U.S. higher education has strongly enabled the habit of "going it alone"—an independence enabled by a plurality of funding sources. Although particular campuses or institutions may feel constrained by state or university rules for multi-campus institutions, the U.S. system remains remarkable for its highly distributed authority of institutional governing boards, executive officers, deans, and shared governance with faculty. Institutions have long had the independent means to choose and fund unique, solo contract solutions for their distinct, geographically separated physical campuses. The collective sum of these costs across the industry of higher education—a sum that is quite large relative to its modest benefit—looks increasingly peculiar in a digitally connected world of open software and cloud services.

The many virtues of institutional independence are also its many vices. American higher education is a vibrant marketplace of ideas, one that has inarguably yielded numerous benefits over the last fifty-plus years. Protecting and enabling that marketplace for leading research and instruction remains essential; whether higher education can or should sustain such expensive heterogeneity in the many essential services that enable research and education is far more debatable. There is no governance means, other than leadership, to change this expensive trajectory. The responsibility thus falls to leaders—and especially to IT leaders—to inform, influence, engage, debate, and adapt their institutions to an increasingly connected world.

Per the wise admonition of Socrates, higher education IT leaders must examine the lessons learned from the last decade of network-enabled communities and must boldly envision how to best innovate solutions to the shared challenges that lie ahead. Community should be neither a vague concept nor a simple label. By exploring its marketecture, leaders can best assess which community approach matches the particular needs of their institutions.

1. See Brad Wheeler:  "The Open Source Parade," EDUCAUSE Review, vol. 39, no. 5 (September/October 2004), pp. 68-69; "Open Source 2007: How Did This Happen?" EDUCAUSE Review, vol. 39, no. 4 (July/August 2004), pp. 12–27; "Open Source 2010: Reflections on 2007," EDUCAUSE Review, vol. 42, no. 1 (January/February 2007), pp. 48–67.
2. We use the term marketecture to refer to the blending of a vibrant marketplace of ideas and the architecture or organizational structures that can bring these ideas together. Some uses of the word have referred to the excesses and sometimes vacuous claims of deceptive marketing departments in technology firms, but that use is not our definition.
3. Robert B. Kvavik and Richard N. Katz, "The Promise and Performance of Enterprise Systems for Higher Education," EDUCAUSE Center for Analysis and Research (ECAR) Research Study, vol. 4 (2002).
4. University of Minnesota, "Enterprise System Upgrade Project Overview," presentation to the Regents Finance and Operations Committee, July 11, 2012.
5. See Paul B. Gandel and Brad Wheeler, "Of Birkenstocks and Wingtips: Open Source Licenses," EDUCAUSE Review, vol. 40, no. 1 (January/February 2005), pp. 10–11.
6. Scott Carlson, "Duke U. Will Give iPod Music Players to All Freshmen," Chronicle of Higher Education, July 30, 2004; James Vito Palazzolo, "ASU, Google Offer Google Apps for Education," ASU press release, October 10, 2006,; Jeffrey R. Young, "Major Publishers Join Indiana U. Project That Requires Students to Buy E-Textbooks," Wired Campus, September 15, 2011.
7. See Brad Wheeler and Shelton Waggener, "Above-Campus Services: Shaping the Promise of Cloud Computing for Higher Education," EDUCAUSE Review, vol. 44, no. 6 (November/December 2009), pp. 52–66; Richard N. Katz, Elazar C. Harel, Anne K. Keehn, Michael D. King, Joanne M. Kossuth, Darren Wesemann, and Bradley Wheeler, "Looking at Clouds from All Sides Now," EDUCAUSE Review, vol. 45, no. 3 (May/June 2010), pp. 32–45.
8. See Steven Weber, The Success of Open Source (Cambridge: Harvard University Press, 2004).
9. Brad Wheeler, "The Inevitable Unbundling of Software and Support," Syllabus, February 27, 2004.