Key open source considerations for businesses, communities and developers.
OSCON’s theme last year was “from disruption to default.” Over the last decade, we’ve seen open source shift from the shadows to the limelight. Today, more businesses than ever are considering the role of open source in their strategies. I’ve had the chance to watch and participate in the transitions of numerous businesses and business units to using open source for the first time, as well as observing how open source strategies evolve for software businesses, both old and new.
In the view of many, open source is the pragmatic expression of the ethical idea of “software freedom,” articulated in various ways for several decades by communities around both Richard Stallman’s GNU Project and the BSD project. The elements of open source and free software are simple to grasp; software freedom delivers the rights to use, study, modify and distribute software for any purpose, and the Open Source Definition clarifies one area of that ethical construct with pragmatic rules that help identify copyright licenses that promote software freedom. But just as simple LEGO bricks unlock an infinite world of creativity, so these open source building blocks offer a wide range of usage models, which are still evolving.
This paper offers some thinking tools for those involved in the consideration and implementation of open source strategies, both in software consuming organizations and by software creators. It aims to equip you with transferrable explanations for some of the concepts your business leaders will need to consider. It includes:
A model for understanding the different layers of community that can form around an open source code “commons” and how you should (and should not) approach them.
An exploration of the symbiotic relationship of transparency and privacy in open source communities.
An explanation of where customer value comes from in enterprise open source, which illuminates the problems with “open core” strategies for communities and customers.
A reflection on the principle that can be seen at work across all these examples: “trade control for influence”
Community types
At every stage of the journey for businesses from the software adoption models that preceded the Internet to those that embrace it, I often find I need to distinguish between the different kinds of community that are layered around various free software commons. Community members are frequently characterised as either “developers” (the “open source” worldview often emphasizes this) or “users” (the “free software” worldview often emphasizes this). All the same, using the term “community” to apply to every style of gathering leads to confusion, especially regarding motivations for participating.
A free software commons is a body of software contained in some sort of repository — usually a version control system but sometimes as simple as just a download directory — and licensed under an OSI-approved open source license, with rules to determine who can modify the contents of the repository. There are also often other rules regarding use of trademarks, discussion forums and other resources, and there are also often rules concerning who may change some or all of the rules and how people gain the right to do so. All these rules are collectively termed the “community governance.” The subject of good governance is extremely important, but this section does not attempt to cover it.
As I’ve watched various community engagements of many companies and individuals, and discussed this with various experienced open source practitioners, it seems to me that there are at least four different clearly differentiated software commons-centric community types, in two bands. These aren’t absolute classifications with hard-and-fast boundaries, and most communities span two of the types, but the distinction is helpful for enterprises when discussing communities.
Layered model
This model is not suited to every kind of discussion, as there are other ways to think about community layers. Most notably, the model I’m proposing here looks at the community layers from the outside, and it is also appropriate to use a model that looks from inside if the context is a community discussion. But the realisation that there is not just one open source community, nor even one kind of community, is a critical evolutionary step for enterprises wanting to engage in open source collaboration.
In the model I’ve found useful for enterprise discussions, community types are layered around the free software commons like the layers of an onion.
From the centre outwards, the categories of community are in two groups:
Co-developer communities — These are the people who directly engage with the core source code for the project. This is the place the project itself is made by a range of people who choose to synchronise an overlapping subset of their interests. Some of the people here may be paid to work on the project code, but all will be here because this is the code they want to work on.
Deployer communities — These are the people whose main engagement with the code involves a running instance that is configured and deployed by the community members in conjunction with other software that forms a deployment environment or stack. While they will contribute bug reports, test cases and occasional fixes, they don’t write the project code themselves; they are experts at configuring, deploying and using it. They also may train other people to do so.
They can be further distinguished into two sub-categories each:
Co-developer communities:
Core co-developers — These are the people whose contributions implement, evolve and maintain the code in the commons. They will have broad permission to change sensitive parts of the code arising from their track record for excellence. They may also include people who specialise in designing the user experience for the software. Many of them will describe themselves as working on the project rather than working for their employer, and some of them may have worked on the same code for several different employers. They are likely to have a strong culture that you’ll want to approach with respect. Importantly, no-one has an automatic right to admission by or respect from this community, even though your company may be a major source of funding. Your star developer or program manager gets the same rights as anyone else, when she has earned them. Attempts at management control of any aspect of this community layer will be most unwelcome and will likely be considered as damage. Moreover, they won’t welcome marketing messages, “developer programmes” and the like.
Extending co-developers (extenders) — These are people who co-develop software and other resources that builds on, enhances or aggregates the work in the commons. They localise the code, port it to different platforms, package it for different operating system distributions and more. They create extensions, plug-ins, prototypes of new features, sample configurations. They work on documentation and training materials. While they will be interested in the tools for doing all these things, they too are unlikely to be welcoming targets for marketing activities.
Deployer communities:
Deployer-developers — These are the people who take the contents of the commons and configure and customise them for deployment. They’re likely to be enthusiastic advocates of the project and very familiar with how to install it in particular applications. They will know all the configuration details, the tricks for tuning and perfecting an installation, the ways to secure and protect it. They may well be in-house developers integrating the project with specific enterprise applications. They are likely to be interested in both competing and complementary products, and to be receptive to developer programs. These are the people you are most likely to meet at user groups.
Users — These are the people who commission, specify and use — and whose employers may pay for — the work of deployer-developers and put it to productive use. They may well be enthusiastic advocates on behalf of the project. They are likely to be interested in offers of services, training, consulting, complementary and competitive services. They are unlikely to have development skills.
Implications of the model
This model for community types has gradually developed over time for me. Naming no names, I have especially observed the following points arising from the model:
1. There are four distinct community types here, but people may play different roles in other communities too. For example, package maintainers working on an operating system distribution may be extenders with regard to the code they are packaging from another project and core co-developers with regard to the distribution itself. People offering bug reports as deployers may well be co-developers in other communities.
2. People may play multiple roles within a given community too. A deployer-developer may be contributing code as an co-developer as they address problems during deployment, for example. Testers are likely to span multiple layers, as are documentation authors. Many people in all four of the layers are also users.
3. There are many different ways to contribute to the commons while participating. Users are often a crucial source of documentation, case studies, bug reports and feature requests and the user role is by no means to be considered unimportant. Mature communities will recognise a variety of ways of contributing to the project.
4. The freedoms people need protected vary between the roles. For example, a user is likely to view being protected from lock-in as a primary freedom and to want a choice of deployer-developers working on their behalf as well as the use of open standards in the design. While the original Four Freedoms provide a baseline, I’m increasingly convinced they need interpreting carefully for each “layer” so that the freedoms essential to smooth operation are understood and respected.
5. The way a commercial organisation engages with communities must respect both the role the organisation plays in relation to the community and also the roles of the people they wish to influence. Treating everyone as if they were, for example, deployer-developers, will lead to negative reactions from all the co-developers. There’s no faster way to alienate the most influential members of a community than to broadcast marketing messages to everyone.
6. There are a number of different ways to model open source communities, but I used this model extensively within Sun Microsystems to advise the engineering, marketing and management teams on their community engagements. Having a set of shared terminology to distinguish roles was important for avoiding the assumption that everyone means the same thing when they say “community.”
7. It’s common for software companies to have people who think that “community” is a synonym for “market.” It’s also common for enterprise software consumers to think that “community” is a synonym for “free support.” Both have their place, but a good understanding of community layering will help avoid career-limiting decisions and company-damaging actions resulting from these false associations.
Transparency and privacy
Whichever “layer” is involved, one of the keys to a successful open source community is the equality of every participant. Equality is a much-used word that’s become overloaded, but in an open source community it is the practical consequence of a combination of transparency around every action within the community and respect for the privacy of every participant outside the scope of the community’s actions. Equality does not automatically imply democracy, but it does mean mutual respect based on contribution alone.
Any community that is truly open will thus have strong values around transparency as well as respecting its participants’ privacy and independence. Such a community will also consequently be unlikely to have a copyright assignment benefiting a commercial party. Here’s why.
Synchronization of interest
It’s important to consider why people are in a community in the first place. While generosity and philanthropy are usually abundant in a healthy open source community, they are not the primary reason for participation. An open source community arises from the synchronization of the individual interests of many parties. Each person:
comes to the community at their own (or their employer’s) expense,
seeks to derive from the commons software that satisfies the need that brought them, and
freely brings with them their own abilities and contributions.
No community member is owed a living by any other user or community member. Communities themselves do not have business models; only (some of) the participants gathering in them do. Participants with a business interest in the code express that interest elsewhere, if it’s a truly open community.
To create an environment where people are willing to synchronize their individual interests and collaborate over code, there has to be transparency. Each action that takes place has to stand on its own merits. Each code commit needs to be understandable, each rule needs to be rational and justified, each expenditure needs to be explained and appropriate.
But that transparency doesn’t have to extend beyond the community into the lives and business interests of the participants themselves. Your motivations for being involved in the community are of no direct relevance to my contribution because our relationship in the community depends on code, not on a relationship between us outside the scope of the code.
It’s very important to realise that, if we do have a relationship outside the scope of the community, it is probably harmful both to our reputations and to the wellbeing of the community for us to allow it to secretly influence our actions in our roles as community members. Some of the worst problems I have seen in open source communities have arisen from community members negotiating in private and then carrying the conclusions into the community either as a fait accompli or with some untruthful rationalisation, usually based on legalism with regard to community rules.
The code, the community and how they interact are transparent, but motivations for participating in it are opaque. My reasons are up to me and yours up to you. They’re outside the immediate scope of the project because the code speaks for itself. Most importantly, you have no right to force acceptance of your business model on me in the name of the project. That’s true even if you started the project, even if you’re still the main funding source. Once you’ve created an open source community, this becomes true no matter how wonderful your historical contribution may have been. Any attempt at control is very likely to backfire.
Private motivations, transparent community
Thus in a healthy open source community, I’m free to maintain my privacy around my motivations and how I’m funding my involvement if I wish. On the other hand, I’m able to work in an environment of transparency where all the code is known, all its origins are known, all its defects are potentially known, all its design decisions are held in the mailing lists. That combination of transparency with privacy is, in my opinion, a primary characteristic of an effective open source community. Communities without the rule “if it didn’t happen as a matter of open record, it didn’t happen” are closed, regardless of the software license.
Open source is about transparency at the community level but also about the privacy of the individuals involved. The interface between the two is where a formal community/contribution agreement is relevant. To maintain trust, enable development transparency and permit individual privacy, it’s reasonable to ask every participant to assent to an agreement promising to stick to community norms, especially with respect to the originality of contributions and the possibility that they are associated with parallel-filed patents.
But it has to be every participant — including the “project sponsor”, if any. Any participant agreement has to impose a community norm. Unlike Orwell’s “Animal Farm,” there’s no scope for one participant or class of participants to be “more equal than the others.”
No exclusivity
To be specific here, it’s not reasonable to give any one participant the exclusive advantage of aggregated copyright for them to use privately. Doing so breaches the transparency-privacy boundary, damages trust by enabling opaque behaviour with the community commons and introduces private business-model reasoning into the community where it doesn’t belong.
I’ve heard arguments such as “we have to be able to make a profit” or “we contributed the original code” to justify copyright assignments, but these are personal not community arguments. Your need for profit is yours, not the community’s, and if you didn’t have it nailed before you started the community and irreversibly licensed the code under an OSI-approved license, that’s your problem. Your business need is no reason for me to surrender my copyright to you, so please don’t demand it. There is no amount of contribution on your part that permits you to demand anything from me — your rights are not proportional to your contribution in an open source community.
This isn’t just a matter of philosophy — it’s practical too. In “The Role of Participation Architecture in Growing Sponsored Open Source Communities,” Joel West and Siobhán O’Mahony make clear that if you’re a company trying to start an open source community, trying to maintain exclusivity will harm the outcome. Your attempt at control will either result in the failure of the community to grow as you hope, or ultimately in the community you created forking and working around you. It has happened before, repeatedly, and it will happen again.
Gaming the system
All this separation of interests has its limits, of course. The Apache Software Foundation has operated on this basis for well over a decade. It has been very effective when diverse peer communities have come together under such rules, and Apache’s model is about the best general-purpose open source community model there is.
But as a consequence it has also been a magnet for would-be abusers. While Apache has successfully dealt with many of these cases, there have still been a few where we’ve seen this combination of high transparency and high privacy being “gamed.” At various points in its history, Apache has seen corporate participants engage around projects in ways that aren’t good for the larger community. It’s not just Apache’s problem, either; other open source communities face the gaming of their models with maturity.
Here’s what happens: An experienced, well-staffed corporation with skilled, experienced professionals and with political power in the software market can make agreements privately. These can be among its own staff and with members of its partner ecosystem, and can be informally framed. They lead to effective control of an open source project run on these terms but with the appearance of openness. Further, the enforced transparency of the community means the abusers quickly become aware of any attempt by competitors — or by individual contributors they can’t control — to disrupt their game.
Ironically, the culture of privacy also discourages intervention. By highlighting the individual status of each participant and treating their external motivations as private, it’s hard to talk about problems arising from corporate motivations, or to ask participants to report or discuss out-of-band agreements. The high value of contribution is gamed too. A culture of “do-ocracy” — where those who can contribute are favoured, and those who can’t or won’t instead step back and disengage — leads to people who identify these subtle problems either staying quiet or even being pushed aside in the community.
Apache has taken steps to deal with this, by instituting its Incubator Project. The Incubator is a “container” into which new projects are placed under the supervision of experienced mentors. In addition to helping incoming projects adapt to the Apache Way, they can also be scrutinised for issues before they become an autonomous party of the larger community. It’s a device any large or general-purpose open source community should consider emulating. Even so, the ability to “game” the privacy/transparency dynamic remains. It’s inevitable — any system contains within it the game that will eventually exploit it. The only defence is a diverse, engaged and empowered community that’s willing to call foul — something Apache also thankfully has!
Open source business models: Open core is bad for you
We’ve considered types of community, and the disposition of participants in open source communities. The next topic to consider is the structure of the business models used by open source community participants. There are a wide range of open source business models, but to generalise wildly, they can all be distilled into one general structure: satisfy your customers’ scarcity from your abundance. The key to a good open source business model is to ensure that the scarcity is genuine and not manufactured, and that the abundance is truly yours!
The topic of business models around open source software is huge and attracts controversy, as the Wikipedia article discussing it demonstrates. Researcher Carlo Daffera has an excellent series on the subject which I recommend. I couldn’t possibly consider every business model that might involve open source, but there’s one that provides a useful case study. The open core business model has been feted as the new default “open source business model,” especially by venture capitalists; so much so that the presence of an open core model is a great indicator of VC funding behind a new company.
But I assert it does not deliver and sustain the principle that provides cost savings and flexibility to the customer — software freedom. As a consequence, businesses that live or die by open core risk the fate of Compiere ERP — which, being undermined by a community fork of its own code, effectively went bust — unless they can manage the incredibly delicate balance their customers will discover they demand.
The idea of open core is simple enough. Here’s a modified quote from a business leader in a company that depends on an open core business-model. He said:
“We deliver a fully functional production with our community edition. You can download it under a GPL v3 license. But, additionally, we provide enterprise features only if you pay for them. It’s open core.”
While that sounds reasonable, there are important unstated issues in that approach. Before you decide to commit yourself to such an approach — either as a software supplier or a software consumer — it’s important to understand those issues and ensure the decision you’re taking is made in the light of that understanding.
A game on software freedom
All systems have loopholes. As we found in the previous section, any system contains within itself by implication the game that will exploit it. Exploiting the loopholes is almost always an unintended consequence of the system. That’s as true of open source as it is of anything else. The open core model exploits open source and is a game on software freedom. The fact the game is played does not invalidate software freedom, but it suggests we may need to revisit definitions and make this particular game harder to play.
Open core is a game on rather than a valid expression of software freedom, because it does not cultivate software freedom for the software user. In an open core business, there is a core package that is open source and which delivers basic functions. That package can be used freely under the terms of an open source licence, and there’s no issue involved at this point — as Andrew Lampitt, who coined the term “open core,” asserts:
“… the customers enjoy, in a way, guarantee of liberty from the vendor; if things go sideways for the vendor, there is a sort of a ‘guaranteed escrow’ of the source code.”
But to use the package effectively in production, a business probably won’t find the functions of the core package sufficient, even in the (usual) case of the core package being highly capable. They will find the core package largely ineffective without certain “extras,” and these are only available in the “enterprise version” of the package, which is not open source.
To use those features, you are forced to be a customer only of the sponsoring company. There’s no alternative, no way to do it yourself if the value delivered doesn’t justify the expense involved or if you are time-rich and cash-poor. Worse, using the package locks you in to the supplier. If they prove a bad choice as a supplier, or if your business needs change, you have no real choice beyond “take it or leave it.” In many cases, ending your subscription with the supplier will mean losing your rights to use the enterprise version all together.
Hiding the problem in plain sight
It is typical of open core apologists to skip this point entirely, preferring to put opposition such as mine down to religious fundamentalism and trying to hide the problems in plain sight. They confuse “dual licensing” (which can respect customer liberties if the vendor chooses to make it so) with open core (which can’t) without observing dual licenses are not applied to the closed add-ons most “open core” vendors sell.
They speak of “vibrant communities” but in most cases those are user communities, not communities of co-developers offering an alternative to the closed add-ons. They speak of “lively ecosystems” without noting that most open core vendors use their power over the code to try to ensure those ecosystems are built of partners, not alternatives. Open core is also not a guaranteed win, even for a great system like Compiere ERP. According to Compiere founder Jorg Janke:
“Compiere certainly did not fail due to its technology. It failed due to lack of sales and marketing expertise, execution and the wrong bet to ‘upgrade’ open source minded partners and customers to a traditional, commercial model. I think that the Commercial Open Source model is still valid, but Compiere overstepped the balance between proprietary and open product components.”
This is not to say it’s never OK to wrap additional services around an open source project. In different ways, both the GPL-ish and BSD-ish wings of the open source movement depend on that ability.
I asked a former president of the Apache Software Foundation how he viewed open core. He replied:
“Open core — as it is practiced within Apache — is that the functionality which makes the product compelling to its users is freely available and released through the auspices of the foundation. It is critical that the open offering be able to stand on its own and address the needs of the community or it will not be attractive enough to merit a diverse community which adheres to Apache’s standards. Since the open offering is released under a permissive license and developed in a transparent manner, the various collaborators within the Apache community — many of which have significant revenue streams or venture capital backing — are able to offer their own products which incorporate and complement the open option.”
Yes, the whole premise of Apache was that its founders could share the various Apache projects as a “core” for other work, but in every case the Apache project is complete and sufficient for deployment at an enterprise level including “the functionality which makes the product compelling to its users.”
As a well-known expert has said, some people have money and need time, and others have time and want money. Open source allows both to participate freely; open core does not.
Open core harms software users
To generalize the analysis, the problem with open core is that instead of delivering and cultivating software freedom, the open core business model induces dependency on closed software and lock-in to a vendor. Open core businesses hope that you will be willing to trade your freedom for tangible short-term benefits or even just for “shiny.”
They stand to benefit massively from having you locked-in; they want to trade your freedom for their profit. So while open core businesses truthfully say they are sustaining open source core software, their actual business is nothing to do with open source. It’s a bait-and-switch, wrapping the same old lock-in in the flag of open source and hoping you won’t notice.
This is not just a philosophical game. “Software freedom” may sound abstract, but it is the system of thinking behind the very practical and tangible benefits that have drawn vast numbers of businesses to use open source. As I have written previously, the four freedoms (to use, study, modify and distribute the software without restriction) have created a vast market by enabling cost savings and flexibility. So a business model that cultivates a casual disregard for and discarding of those liberties while pretending otherwise deserves to be challenged.
If you are a software vendor, please respect your customers’ freedoms. Help them see that they are worth paying for. If you choose not to, remember that just because the business model you have chosen demands that you withhold software freedom from your customers, that doesn’t mean the only way to do business around open source involves doing the same. Don’t hide a desire for control that you can artificially exploit behind apparently good words about deserving to make a profit.
If you’re an enterprise software consumer, it’s crucial you cultivate your degrees of freedom. They are the source of your ability to respond to changed market conditions; to negotiate with suppliers strongly because you always have choices that allow you to walk away from any deal; to hire staff from a free market beyond any vendors’ control; to expect constant new innovation because the market in which you purchase remains competitive. Ultimately, to save money by surrendering your freedoms will mean you never save money again.
Copyright accumulation?
This leads inevitably to the controversial subject of copyright accumulation in open source communities. My position is that it is a rarely-needed and exceptional tool that should be avoided unless essential, because of the negative effects it has on the dynamics of open source communities. In the rare cases they are needed, they should accumulate copyright into the hands of a legal entity that embodies the interests of the whole community-of-communities gathered around the software commons in question. It should not be for the benefit of just one company. That creates an inequity that will poison the community.
All the same, I’ve heard prominent commentators assert that a software company that wants to promote open source has to use copyright accumulation if it wants to make money. While that sounds superficially reasonable, I contend that statement is a circular argument. If you’ve chosen to build your business around a model that requires the accumulation of copyright, then you will need a contributor agreement that makes it happen. But it’s a matter of choice whether you use a business model like that, or whether you pick another business model that does not demand copyright accumulation. As an entrepreneur, one has a choice in this matter.
Scarcity
Ultimately any business runs by meeting a scarcity faced by their customer with an abundance they have themselves, and creating profit from the resulting win-win. In the software business, scarcity is harder to identify. While the world was still operating on the hub-and-spoke topology inherited from the Industrial Revolution, the artificial creation of scarcity by licensing copyright restrictively worked well as a payment gateway. But in today’s meshed society, where the ability to connect direct means mediation is now artificial interference, trying to charge for the right-to-use software appears to the Internet as damage and is routed around. It also creates an insurmountable barrier for communities.
I can understand why a long-established corporation trying to come to terms with open source in the early stages of the road to freedom might think they need a contributor agreement. But it’s churlish and contrarian to start a new business today that relies for its revenue on the artificial scarcity of yesterday. There are plenty of scarcities to monetise — cloud infrastructure, operations skill, stack integration, jurisdictional differences and many more — without the need to try to apply a gateway to open source software. The requirement for a copyright accumulation in order to create an artificial scarcity is the genetic marker for a desire for control, and in the meshed society that the Internet is creating, that’s a sign of damage that needs working around.
Participation agreements
Just to be completely clear, this warning against copyright assignment is not a prohibition of having participant agreements that confirm the community norms and ensure every participant has recorded their agreement in a consistent way. Participant agreements can have a variety of uses. For example, they may set default licensing terms when none are stated, and may indicate a commitment to originality in all contributions. These sorts of agreements are common enough.
Even they impose a barrier to participation for some potential community members; any developer who has to get permission to proceed from his employer’s general counsel will need to be highly motivated in order to do so. You need to make sure you’ve done the cost-benefit analysis in a way that includes an allowance for the extra community-building effort that will be needed to overcome each barrier to participation you’ve deemed essential.
One of the needs that drives some communities to copyright accumulation is the desire to protect against a future need for license change. If the copyrights for contributions are left in the hands of their original contributors, getting their permission to change the license at a later date could be a nightmare. But copyright accumulation isn’t the only tool available. You could use a license like the Apache License version 2, which grants rights so broad that the addition of another license with different but complementary terms is very easy.
Alternatively, you could select a “plus license” for the project, which includes language permitting relicensing under a later revision of the same license. This “license upgrade” capability covers most valid cases where a community might want to relicense. For projects wanting file-level copyleft (“weak copyleft”) the Mozilla Public License version 2 is the best choice at present. Projects wanting a strong copyleft license may want to use the GNU General Public License version 3, or may prefer to license under version 2 using the .”.. or any later version” language.
Whose freedom?
In designing a new business, the ultimate diagnostic is who is left with the benefits of software freedom; you or you and your customers? The “bubble” of new companies starting and gaining funding based on business models that subvert open source by “dual licensing” and “open core” are effectively over. The branding of hot startups can no longer rely on smoke-and-mirrors tricks of terminology relating to open source because too many people are familiar with the every-day reality of software freedom. And communities are wising up to the hazards of copyright accumulation.
Conclusion: Trade control for influence
In each of these examples of how enterprises collaborate across communities, there’s a common thread running through all the best practices. In communities, when we seek greater control, unless it’s control that’s for the overall good of the community and granted with the full consent of the community, there is a great risk it will backfire. The controversies around the Hudson/Jenkins projects and the OpenOffice.org/LibreOffice projects show the damage that can result.
Instead, a wiser strategy is in each case to seek greater influence over the direction each community chooses for itself. Just as a design principle of the Internet was to route around damage, so open source communities do the same. The open source licenses under which they operate always allow anyone to take the code elsewhere and work on it without you — a “fork.” If they’re justified in doing so, one or more layers of the community will go with them.
Maybe you’re from a rich, powerful corporation that can use its relationships with partners to simulate an open source community in spite of the fork. But why do that? Instead, live and work as a supporter of transparency and privacy. Avoid private agreements that make other community members behave in ways that subvert that transparency. Develop code in the open. Trade with your customers on the value you can deliver to them rather than on the control you are able to gain over them.
As you do this, your influence in the community will grow strong. Influence allows you to steer community decisions because other participants trust and respect you. It makes other community members support and defend you against challengers. It is the basis for successful business in the open source age. Ultimately, your best community collaboration strategy is to trade control for influence.
OSCON’s theme last year was “from disruption to default.” Over the last decade, we’ve seen open source shift from the shadows to the limelight. Today, more businesses than ever are considering the role of open source in their strategies. I’ve had the chance to watch and participate in the transitions of numerous businesses and business units to using open source for the first time, as well as observing how open source strategies evolve for software businesses, both old and new.
In the view of many, open source is the pragmatic expression of the ethical idea of “software freedom,” articulated in various ways for several decades by communities around both Richard Stallman’s GNU Project and the BSD project. The elements of open source and free software are simple to grasp; software freedom delivers the rights to use, study, modify and distribute software for any purpose, and the Open Source Definition clarifies one area of that ethical construct with pragmatic rules that help identify copyright licenses that promote software freedom. But just as simple LEGO bricks unlock an infinite world of creativity, so these open source building blocks offer a wide range of usage models, which are still evolving.
This paper offers some thinking tools for those involved in the consideration and implementation of open source strategies, both in software consuming organizations and by software creators. It aims to equip you with transferrable explanations for some of the concepts your business leaders will need to consider. It includes:
A model for understanding the different layers of community that can form around an open source code “commons” and how you should (and should not) approach them.
An exploration of the symbiotic relationship of transparency and privacy in open source communities.
An explanation of where customer value comes from in enterprise open source, which illuminates the problems with “open core” strategies for communities and customers.
A reflection on the principle that can be seen at work across all these examples: “trade control for influence”
Community types
At every stage of the journey for businesses from the software adoption models that preceded the Internet to those that embrace it, I often find I need to distinguish between the different kinds of community that are layered around various free software commons. Community members are frequently characterised as either “developers” (the “open source” worldview often emphasizes this) or “users” (the “free software” worldview often emphasizes this). All the same, using the term “community” to apply to every style of gathering leads to confusion, especially regarding motivations for participating.
A free software commons is a body of software contained in some sort of repository — usually a version control system but sometimes as simple as just a download directory — and licensed under an OSI-approved open source license, with rules to determine who can modify the contents of the repository. There are also often other rules regarding use of trademarks, discussion forums and other resources, and there are also often rules concerning who may change some or all of the rules and how people gain the right to do so. All these rules are collectively termed the “community governance.” The subject of good governance is extremely important, but this section does not attempt to cover it.
As I’ve watched various community engagements of many companies and individuals, and discussed this with various experienced open source practitioners, it seems to me that there are at least four different clearly differentiated software commons-centric community types, in two bands. These aren’t absolute classifications with hard-and-fast boundaries, and most communities span two of the types, but the distinction is helpful for enterprises when discussing communities.
Layered model
This model is not suited to every kind of discussion, as there are other ways to think about community layers. Most notably, the model I’m proposing here looks at the community layers from the outside, and it is also appropriate to use a model that looks from inside if the context is a community discussion. But the realisation that there is not just one open source community, nor even one kind of community, is a critical evolutionary step for enterprises wanting to engage in open source collaboration.
In the model I’ve found useful for enterprise discussions, community types are layered around the free software commons like the layers of an onion.
From the centre outwards, the categories of community are in two groups:
Co-developer communities — These are the people who directly engage with the core source code for the project. This is the place the project itself is made by a range of people who choose to synchronise an overlapping subset of their interests. Some of the people here may be paid to work on the project code, but all will be here because this is the code they want to work on.
Deployer communities — These are the people whose main engagement with the code involves a running instance that is configured and deployed by the community members in conjunction with other software that forms a deployment environment or stack. While they will contribute bug reports, test cases and occasional fixes, they don’t write the project code themselves; they are experts at configuring, deploying and using it. They also may train other people to do so.
They can be further distinguished into two sub-categories each:
Co-developer communities:
Core co-developers — These are the people whose contributions implement, evolve and maintain the code in the commons. They will have broad permission to change sensitive parts of the code arising from their track record for excellence. They may also include people who specialise in designing the user experience for the software. Many of them will describe themselves as working on the project rather than working for their employer, and some of them may have worked on the same code for several different employers. They are likely to have a strong culture that you’ll want to approach with respect. Importantly, no-one has an automatic right to admission by or respect from this community, even though your company may be a major source of funding. Your star developer or program manager gets the same rights as anyone else, when she has earned them. Attempts at management control of any aspect of this community layer will be most unwelcome and will likely be considered as damage. Moreover, they won’t welcome marketing messages, “developer programmes” and the like.
Extending co-developers (extenders) — These are people who co-develop software and other resources that builds on, enhances or aggregates the work in the commons. They localise the code, port it to different platforms, package it for different operating system distributions and more. They create extensions, plug-ins, prototypes of new features, sample configurations. They work on documentation and training materials. While they will be interested in the tools for doing all these things, they too are unlikely to be welcoming targets for marketing activities.
Deployer communities:
Deployer-developers — These are the people who take the contents of the commons and configure and customise them for deployment. They’re likely to be enthusiastic advocates of the project and very familiar with how to install it in particular applications. They will know all the configuration details, the tricks for tuning and perfecting an installation, the ways to secure and protect it. They may well be in-house developers integrating the project with specific enterprise applications. They are likely to be interested in both competing and complementary products, and to be receptive to developer programs. These are the people you are most likely to meet at user groups.
Users — These are the people who commission, specify and use — and whose employers may pay for — the work of deployer-developers and put it to productive use. They may well be enthusiastic advocates on behalf of the project. They are likely to be interested in offers of services, training, consulting, complementary and competitive services. They are unlikely to have development skills.
Implications of the model
This model for community types has gradually developed over time for me. Naming no names, I have especially observed the following points arising from the model:
1. There are four distinct community types here, but people may play different roles in other communities too. For example, package maintainers working on an operating system distribution may be extenders with regard to the code they are packaging from another project and core co-developers with regard to the distribution itself. People offering bug reports as deployers may well be co-developers in other communities.
2. People may play multiple roles within a given community too. A deployer-developer may be contributing code as an co-developer as they address problems during deployment, for example. Testers are likely to span multiple layers, as are documentation authors. Many people in all four of the layers are also users.
3. There are many different ways to contribute to the commons while participating. Users are often a crucial source of documentation, case studies, bug reports and feature requests and the user role is by no means to be considered unimportant. Mature communities will recognise a variety of ways of contributing to the project.
4. The freedoms people need protected vary between the roles. For example, a user is likely to view being protected from lock-in as a primary freedom and to want a choice of deployer-developers working on their behalf as well as the use of open standards in the design. While the original Four Freedoms provide a baseline, I’m increasingly convinced they need interpreting carefully for each “layer” so that the freedoms essential to smooth operation are understood and respected.
5. The way a commercial organisation engages with communities must respect both the role the organisation plays in relation to the community and also the roles of the people they wish to influence. Treating everyone as if they were, for example, deployer-developers, will lead to negative reactions from all the co-developers. There’s no faster way to alienate the most influential members of a community than to broadcast marketing messages to everyone.
6. There are a number of different ways to model open source communities, but I used this model extensively within Sun Microsystems to advise the engineering, marketing and management teams on their community engagements. Having a set of shared terminology to distinguish roles was important for avoiding the assumption that everyone means the same thing when they say “community.”
7. It’s common for software companies to have people who think that “community” is a synonym for “market.” It’s also common for enterprise software consumers to think that “community” is a synonym for “free support.” Both have their place, but a good understanding of community layering will help avoid career-limiting decisions and company-damaging actions resulting from these false associations.
Transparency and privacy
Whichever “layer” is involved, one of the keys to a successful open source community is the equality of every participant. Equality is a much-used word that’s become overloaded, but in an open source community it is the practical consequence of a combination of transparency around every action within the community and respect for the privacy of every participant outside the scope of the community’s actions. Equality does not automatically imply democracy, but it does mean mutual respect based on contribution alone.
Any community that is truly open will thus have strong values around transparency as well as respecting its participants’ privacy and independence. Such a community will also consequently be unlikely to have a copyright assignment benefiting a commercial party. Here’s why.
Synchronization of interest
It’s important to consider why people are in a community in the first place. While generosity and philanthropy are usually abundant in a healthy open source community, they are not the primary reason for participation. An open source community arises from the synchronization of the individual interests of many parties. Each person:
comes to the community at their own (or their employer’s) expense,
seeks to derive from the commons software that satisfies the need that brought them, and
freely brings with them their own abilities and contributions.
No community member is owed a living by any other user or community member. Communities themselves do not have business models; only (some of) the participants gathering in them do. Participants with a business interest in the code express that interest elsewhere, if it’s a truly open community.
To create an environment where people are willing to synchronize their individual interests and collaborate over code, there has to be transparency. Each action that takes place has to stand on its own merits. Each code commit needs to be understandable, each rule needs to be rational and justified, each expenditure needs to be explained and appropriate.
But that transparency doesn’t have to extend beyond the community into the lives and business interests of the participants themselves. Your motivations for being involved in the community are of no direct relevance to my contribution because our relationship in the community depends on code, not on a relationship between us outside the scope of the code.
It’s very important to realise that, if we do have a relationship outside the scope of the community, it is probably harmful both to our reputations and to the wellbeing of the community for us to allow it to secretly influence our actions in our roles as community members. Some of the worst problems I have seen in open source communities have arisen from community members negotiating in private and then carrying the conclusions into the community either as a fait accompli or with some untruthful rationalisation, usually based on legalism with regard to community rules.
The code, the community and how they interact are transparent, but motivations for participating in it are opaque. My reasons are up to me and yours up to you. They’re outside the immediate scope of the project because the code speaks for itself. Most importantly, you have no right to force acceptance of your business model on me in the name of the project. That’s true even if you started the project, even if you’re still the main funding source. Once you’ve created an open source community, this becomes true no matter how wonderful your historical contribution may have been. Any attempt at control is very likely to backfire.
Private motivations, transparent community
Thus in a healthy open source community, I’m free to maintain my privacy around my motivations and how I’m funding my involvement if I wish. On the other hand, I’m able to work in an environment of transparency where all the code is known, all its origins are known, all its defects are potentially known, all its design decisions are held in the mailing lists. That combination of transparency with privacy is, in my opinion, a primary characteristic of an effective open source community. Communities without the rule “if it didn’t happen as a matter of open record, it didn’t happen” are closed, regardless of the software license.
Open source is about transparency at the community level but also about the privacy of the individuals involved. The interface between the two is where a formal community/contribution agreement is relevant. To maintain trust, enable development transparency and permit individual privacy, it’s reasonable to ask every participant to assent to an agreement promising to stick to community norms, especially with respect to the originality of contributions and the possibility that they are associated with parallel-filed patents.
But it has to be every participant — including the “project sponsor”, if any. Any participant agreement has to impose a community norm. Unlike Orwell’s “Animal Farm,” there’s no scope for one participant or class of participants to be “more equal than the others.”
No exclusivity
To be specific here, it’s not reasonable to give any one participant the exclusive advantage of aggregated copyright for them to use privately. Doing so breaches the transparency-privacy boundary, damages trust by enabling opaque behaviour with the community commons and introduces private business-model reasoning into the community where it doesn’t belong.
I’ve heard arguments such as “we have to be able to make a profit” or “we contributed the original code” to justify copyright assignments, but these are personal not community arguments. Your need for profit is yours, not the community’s, and if you didn’t have it nailed before you started the community and irreversibly licensed the code under an OSI-approved license, that’s your problem. Your business need is no reason for me to surrender my copyright to you, so please don’t demand it. There is no amount of contribution on your part that permits you to demand anything from me — your rights are not proportional to your contribution in an open source community.
This isn’t just a matter of philosophy — it’s practical too. In “The Role of Participation Architecture in Growing Sponsored Open Source Communities,” Joel West and Siobhán O’Mahony make clear that if you’re a company trying to start an open source community, trying to maintain exclusivity will harm the outcome. Your attempt at control will either result in the failure of the community to grow as you hope, or ultimately in the community you created forking and working around you. It has happened before, repeatedly, and it will happen again.
Gaming the system
All this separation of interests has its limits, of course. The Apache Software Foundation has operated on this basis for well over a decade. It has been very effective when diverse peer communities have come together under such rules, and Apache’s model is about the best general-purpose open source community model there is.
But as a consequence it has also been a magnet for would-be abusers. While Apache has successfully dealt with many of these cases, there have still been a few where we’ve seen this combination of high transparency and high privacy being “gamed.” At various points in its history, Apache has seen corporate participants engage around projects in ways that aren’t good for the larger community. It’s not just Apache’s problem, either; other open source communities face the gaming of their models with maturity.
Here’s what happens: An experienced, well-staffed corporation with skilled, experienced professionals and with political power in the software market can make agreements privately. These can be among its own staff and with members of its partner ecosystem, and can be informally framed. They lead to effective control of an open source project run on these terms but with the appearance of openness. Further, the enforced transparency of the community means the abusers quickly become aware of any attempt by competitors — or by individual contributors they can’t control — to disrupt their game.
Ironically, the culture of privacy also discourages intervention. By highlighting the individual status of each participant and treating their external motivations as private, it’s hard to talk about problems arising from corporate motivations, or to ask participants to report or discuss out-of-band agreements. The high value of contribution is gamed too. A culture of “do-ocracy” — where those who can contribute are favoured, and those who can’t or won’t instead step back and disengage — leads to people who identify these subtle problems either staying quiet or even being pushed aside in the community.
Apache has taken steps to deal with this, by instituting its Incubator Project. The Incubator is a “container” into which new projects are placed under the supervision of experienced mentors. In addition to helping incoming projects adapt to the Apache Way, they can also be scrutinised for issues before they become an autonomous party of the larger community. It’s a device any large or general-purpose open source community should consider emulating. Even so, the ability to “game” the privacy/transparency dynamic remains. It’s inevitable — any system contains within it the game that will eventually exploit it. The only defence is a diverse, engaged and empowered community that’s willing to call foul — something Apache also thankfully has!
Open source business models: Open core is bad for you
We’ve considered types of community, and the disposition of participants in open source communities. The next topic to consider is the structure of the business models used by open source community participants. There are a wide range of open source business models, but to generalise wildly, they can all be distilled into one general structure: satisfy your customers’ scarcity from your abundance. The key to a good open source business model is to ensure that the scarcity is genuine and not manufactured, and that the abundance is truly yours!
The topic of business models around open source software is huge and attracts controversy, as the Wikipedia article discussing it demonstrates. Researcher Carlo Daffera has an excellent series on the subject which I recommend. I couldn’t possibly consider every business model that might involve open source, but there’s one that provides a useful case study. The open core business model has been feted as the new default “open source business model,” especially by venture capitalists; so much so that the presence of an open core model is a great indicator of VC funding behind a new company.
But I assert it does not deliver and sustain the principle that provides cost savings and flexibility to the customer — software freedom. As a consequence, businesses that live or die by open core risk the fate of Compiere ERP — which, being undermined by a community fork of its own code, effectively went bust — unless they can manage the incredibly delicate balance their customers will discover they demand.
The idea of open core is simple enough. Here’s a modified quote from a business leader in a company that depends on an open core business-model. He said:
“We deliver a fully functional production with our community edition. You can download it under a GPL v3 license. But, additionally, we provide enterprise features only if you pay for them. It’s open core.”
While that sounds reasonable, there are important unstated issues in that approach. Before you decide to commit yourself to such an approach — either as a software supplier or a software consumer — it’s important to understand those issues and ensure the decision you’re taking is made in the light of that understanding.
A game on software freedom
All systems have loopholes. As we found in the previous section, any system contains within itself by implication the game that will exploit it. Exploiting the loopholes is almost always an unintended consequence of the system. That’s as true of open source as it is of anything else. The open core model exploits open source and is a game on software freedom. The fact the game is played does not invalidate software freedom, but it suggests we may need to revisit definitions and make this particular game harder to play.
Open core is a game on rather than a valid expression of software freedom, because it does not cultivate software freedom for the software user. In an open core business, there is a core package that is open source and which delivers basic functions. That package can be used freely under the terms of an open source licence, and there’s no issue involved at this point — as Andrew Lampitt, who coined the term “open core,” asserts:
“… the customers enjoy, in a way, guarantee of liberty from the vendor; if things go sideways for the vendor, there is a sort of a ‘guaranteed escrow’ of the source code.”
But to use the package effectively in production, a business probably won’t find the functions of the core package sufficient, even in the (usual) case of the core package being highly capable. They will find the core package largely ineffective without certain “extras,” and these are only available in the “enterprise version” of the package, which is not open source.
To use those features, you are forced to be a customer only of the sponsoring company. There’s no alternative, no way to do it yourself if the value delivered doesn’t justify the expense involved or if you are time-rich and cash-poor. Worse, using the package locks you in to the supplier. If they prove a bad choice as a supplier, or if your business needs change, you have no real choice beyond “take it or leave it.” In many cases, ending your subscription with the supplier will mean losing your rights to use the enterprise version all together.
Hiding the problem in plain sight
It is typical of open core apologists to skip this point entirely, preferring to put opposition such as mine down to religious fundamentalism and trying to hide the problems in plain sight. They confuse “dual licensing” (which can respect customer liberties if the vendor chooses to make it so) with open core (which can’t) without observing dual licenses are not applied to the closed add-ons most “open core” vendors sell.
They speak of “vibrant communities” but in most cases those are user communities, not communities of co-developers offering an alternative to the closed add-ons. They speak of “lively ecosystems” without noting that most open core vendors use their power over the code to try to ensure those ecosystems are built of partners, not alternatives. Open core is also not a guaranteed win, even for a great system like Compiere ERP. According to Compiere founder Jorg Janke:
“Compiere certainly did not fail due to its technology. It failed due to lack of sales and marketing expertise, execution and the wrong bet to ‘upgrade’ open source minded partners and customers to a traditional, commercial model. I think that the Commercial Open Source model is still valid, but Compiere overstepped the balance between proprietary and open product components.”
This is not to say it’s never OK to wrap additional services around an open source project. In different ways, both the GPL-ish and BSD-ish wings of the open source movement depend on that ability.
I asked a former president of the Apache Software Foundation how he viewed open core. He replied:
“Open core — as it is practiced within Apache — is that the functionality which makes the product compelling to its users is freely available and released through the auspices of the foundation. It is critical that the open offering be able to stand on its own and address the needs of the community or it will not be attractive enough to merit a diverse community which adheres to Apache’s standards. Since the open offering is released under a permissive license and developed in a transparent manner, the various collaborators within the Apache community — many of which have significant revenue streams or venture capital backing — are able to offer their own products which incorporate and complement the open option.”
Yes, the whole premise of Apache was that its founders could share the various Apache projects as a “core” for other work, but in every case the Apache project is complete and sufficient for deployment at an enterprise level including “the functionality which makes the product compelling to its users.”
As a well-known expert has said, some people have money and need time, and others have time and want money. Open source allows both to participate freely; open core does not.
Open core harms software users
To generalize the analysis, the problem with open core is that instead of delivering and cultivating software freedom, the open core business model induces dependency on closed software and lock-in to a vendor. Open core businesses hope that you will be willing to trade your freedom for tangible short-term benefits or even just for “shiny.”
They stand to benefit massively from having you locked-in; they want to trade your freedom for their profit. So while open core businesses truthfully say they are sustaining open source core software, their actual business is nothing to do with open source. It’s a bait-and-switch, wrapping the same old lock-in in the flag of open source and hoping you won’t notice.
This is not just a philosophical game. “Software freedom” may sound abstract, but it is the system of thinking behind the very practical and tangible benefits that have drawn vast numbers of businesses to use open source. As I have written previously, the four freedoms (to use, study, modify and distribute the software without restriction) have created a vast market by enabling cost savings and flexibility. So a business model that cultivates a casual disregard for and discarding of those liberties while pretending otherwise deserves to be challenged.
If you are a software vendor, please respect your customers’ freedoms. Help them see that they are worth paying for. If you choose not to, remember that just because the business model you have chosen demands that you withhold software freedom from your customers, that doesn’t mean the only way to do business around open source involves doing the same. Don’t hide a desire for control that you can artificially exploit behind apparently good words about deserving to make a profit.
If you’re an enterprise software consumer, it’s crucial you cultivate your degrees of freedom. They are the source of your ability to respond to changed market conditions; to negotiate with suppliers strongly because you always have choices that allow you to walk away from any deal; to hire staff from a free market beyond any vendors’ control; to expect constant new innovation because the market in which you purchase remains competitive. Ultimately, to save money by surrendering your freedoms will mean you never save money again.
Copyright accumulation?
This leads inevitably to the controversial subject of copyright accumulation in open source communities. My position is that it is a rarely-needed and exceptional tool that should be avoided unless essential, because of the negative effects it has on the dynamics of open source communities. In the rare cases they are needed, they should accumulate copyright into the hands of a legal entity that embodies the interests of the whole community-of-communities gathered around the software commons in question. It should not be for the benefit of just one company. That creates an inequity that will poison the community.
All the same, I’ve heard prominent commentators assert that a software company that wants to promote open source has to use copyright accumulation if it wants to make money. While that sounds superficially reasonable, I contend that statement is a circular argument. If you’ve chosen to build your business around a model that requires the accumulation of copyright, then you will need a contributor agreement that makes it happen. But it’s a matter of choice whether you use a business model like that, or whether you pick another business model that does not demand copyright accumulation. As an entrepreneur, one has a choice in this matter.
Scarcity
Ultimately any business runs by meeting a scarcity faced by their customer with an abundance they have themselves, and creating profit from the resulting win-win. In the software business, scarcity is harder to identify. While the world was still operating on the hub-and-spoke topology inherited from the Industrial Revolution, the artificial creation of scarcity by licensing copyright restrictively worked well as a payment gateway. But in today’s meshed society, where the ability to connect direct means mediation is now artificial interference, trying to charge for the right-to-use software appears to the Internet as damage and is routed around. It also creates an insurmountable barrier for communities.
I can understand why a long-established corporation trying to come to terms with open source in the early stages of the road to freedom might think they need a contributor agreement. But it’s churlish and contrarian to start a new business today that relies for its revenue on the artificial scarcity of yesterday. There are plenty of scarcities to monetise — cloud infrastructure, operations skill, stack integration, jurisdictional differences and many more — without the need to try to apply a gateway to open source software. The requirement for a copyright accumulation in order to create an artificial scarcity is the genetic marker for a desire for control, and in the meshed society that the Internet is creating, that’s a sign of damage that needs working around.
Participation agreements
Just to be completely clear, this warning against copyright assignment is not a prohibition of having participant agreements that confirm the community norms and ensure every participant has recorded their agreement in a consistent way. Participant agreements can have a variety of uses. For example, they may set default licensing terms when none are stated, and may indicate a commitment to originality in all contributions. These sorts of agreements are common enough.
Even they impose a barrier to participation for some potential community members; any developer who has to get permission to proceed from his employer’s general counsel will need to be highly motivated in order to do so. You need to make sure you’ve done the cost-benefit analysis in a way that includes an allowance for the extra community-building effort that will be needed to overcome each barrier to participation you’ve deemed essential.
One of the needs that drives some communities to copyright accumulation is the desire to protect against a future need for license change. If the copyrights for contributions are left in the hands of their original contributors, getting their permission to change the license at a later date could be a nightmare. But copyright accumulation isn’t the only tool available. You could use a license like the Apache License version 2, which grants rights so broad that the addition of another license with different but complementary terms is very easy.
Alternatively, you could select a “plus license” for the project, which includes language permitting relicensing under a later revision of the same license. This “license upgrade” capability covers most valid cases where a community might want to relicense. For projects wanting file-level copyleft (“weak copyleft”) the Mozilla Public License version 2 is the best choice at present. Projects wanting a strong copyleft license may want to use the GNU General Public License version 3, or may prefer to license under version 2 using the .”.. or any later version” language.
Whose freedom?
In designing a new business, the ultimate diagnostic is who is left with the benefits of software freedom; you or you and your customers? The “bubble” of new companies starting and gaining funding based on business models that subvert open source by “dual licensing” and “open core” are effectively over. The branding of hot startups can no longer rely on smoke-and-mirrors tricks of terminology relating to open source because too many people are familiar with the every-day reality of software freedom. And communities are wising up to the hazards of copyright accumulation.
Conclusion: Trade control for influence
In each of these examples of how enterprises collaborate across communities, there’s a common thread running through all the best practices. In communities, when we seek greater control, unless it’s control that’s for the overall good of the community and granted with the full consent of the community, there is a great risk it will backfire. The controversies around the Hudson/Jenkins projects and the OpenOffice.org/LibreOffice projects show the damage that can result.
Instead, a wiser strategy is in each case to seek greater influence over the direction each community chooses for itself. Just as a design principle of the Internet was to route around damage, so open source communities do the same. The open source licenses under which they operate always allow anyone to take the code elsewhere and work on it without you — a “fork.” If they’re justified in doing so, one or more layers of the community will go with them.
Maybe you’re from a rich, powerful corporation that can use its relationships with partners to simulate an open source community in spite of the fork. But why do that? Instead, live and work as a supporter of transparency and privacy. Avoid private agreements that make other community members behave in ways that subvert that transparency. Develop code in the open. Trade with your customers on the value you can deliver to them rather than on the control you are able to gain over them.
As you do this, your influence in the community will grow strong. Influence allows you to steer community decisions because other participants trust and respect you. It makes other community members support and defend you against challengers. It is the basis for successful business in the open source age. Ultimately, your best community collaboration strategy is to trade control for influence.
No comments:
Post a Comment