There are diverse viewpoints on open source and its usage as a service. I’ve attempted to give a synopsis of the issues and some background – but that’s only my viewpoint. I’m bringing in other people to give their diverse viewpoints to give a more well-rounded one. This is stemming from this Twitter thread.

The opinions stated here are those of the respondent and not necessarily those of their respective companies.

Our interviewees are:
Jesse Anderson (JA)
Peter Corless (PC)
Roman Shaposhnik (RS)
Karthik Ramasamy and Jon Bock (STR)

The Questions:

There obviously isn’t a legal obligation to give back to an Apache-2.0 project, but is there a moral duty or social contract to give back to open source?

JA – I think there is a moral obligation if you’re directly commercializing the project. If you’re just using the project as for internal purposes, I don’t think so. If you’re directly commercializing it as a service, you have the moral obligation to give back. Examples of directly commercializing would be running the technology itself as managed service. I think the reason that we’re having this discussion is because there is a social contract and when it’s broken only people can push back and not lawyers.

PC – in any social contract there are explicit and implicit agreements. In a legal contract, the explicit agreements are stipulated in writing. The implicit agreements are in social conventions, such as good faith, good will, ethics (i.e., avoiding tacit circumvention), and so on. Even in the conventions of “who is a party to a contract?”

This is where much of the debate is today. If you have a software producer (A), a cloud software hosting provider (B), a cloud software customer (C), and then that cloud customer’s end user (D), the issue of who-is-licensing-to-whom, and what conditions they can impose is critical.

The issue is that there is not a strong concept of “channels” in open source. Once you let the software free, you can’t ensure that others are also offering it for free.

In the example above, what if the cloud offering provider gives it away, but their cloud customer charges use of it to an end user? How does the original provider ensure that all rights of use pass for free to an end user? Well, they can’t under current conditions. The Internet is not smart enough to judge creator’s intent.

At the same time, maybe a software provider is totally fine with downstream parties to charge for hosting or sharing software. So long as, say, they give credit (copyleft, or other attribution statements). Again, while there are some stabs at this today, there are few standards on how. Do I need to share a wall-of-logos on my web site’s front page? Make a splash of logos when you first launch a product? Or can I put them all in a kind of “bag of credits”? There’s no industry standard around this.

And, even if we had a language that humans understand, you need to take these license agreements and bind them into computer-operable terns: networking stacks, tool chains, etc. Open a REST API, or some metadata files, and find out these legalities before you start connections or compiling code.

And for that, we need a common grammar of parties, use rights, license terms, transferability, scope, limits, and so on.

I have a lotta thoughts on this. So, glad you asked!

RS – I’d like to flip the script here a little bit and re-frame the question. And why not, after all, altruism does have evolutionary benefits. Besides, there’s no such thing as “giving back to the project” you always give back to the community that has grown around the project (consider that if you donate the most elaborate code to a codebase that has no community — are you really benefiting anyone?). With that in mind, I’d argue that ensuring the health and viability of open source community around a project is in the long-term business interest of any organization that is building products or services around said project. It is less a moral duty or a social contract but more of an act of self-preservation really. Now, how you help that community thrive becomes a very interesting question. Not all communities are created equal and where one may need a lot of your code contribution another one may desperately need you running software at scale than nobody else in the community can afford. You have to listen to the community and, of course, in order to be an effective listener you have to participate in the community. Long story short: give back? Don’t care that much. Participate? Yeah — you really should.

[STR] – We’re skeptical of any type of one size fits all expectation about giving back to open source, even a moral or social expectation. It’s very difficult to draw clear lines about when such an expectation should exist and easy to find examples that are contrary the intent of such expectations. If someone is using open source to work on a social good project in their spare time, are they obligated to contribute back to the open source core? Presumably not many people would have that expectation. If a life sciences researcher is paying a cloud provider for the use of the cloud provider’s service to help discover a new drug that cures a previously incurable disease, is the researcher or cloud provider performing an anti-social act by not contributing code back to the project if they are each adding value in different ways?

Deciding to release a project into open source is a commercial act–it has commercial implications that are well known. Provided that the person or people who make the decision on licensing are aware of those implications and freely choose to accept them, the expectation of a moral or social obligation on future users of the project, whomever they are, is simply hope and no more binding than a wish.

What is the reason that a company or organization should give back to open source?

JA – It depends on the company and how they’re using the technology. For a user of the technology, they could give back as a way to recruit. For an organization monetizing the project, they have to give back to show they can actually support their customers. End customers, especially enterprises, want committers than can fix their bugs in open source. For open source companies, giving back is the only way to make money.

PC – “tragedy of the commons” is often cited, but I’ll instead refer to the “Little Red Hen.” Everyone is totally willing to eat her bread. No one is willing to help grind the grain or knead the dough, etc. After a while, the Little Red Hen won’t be around to make you bread (open source inventors move on, or can literally pass from life). The Little Red Hen also needs to pay rent. (I keep thinking back to all the other creatives who are asked to work for free “for the exposure.”) While ideally some Open Source contributors are sponsored by employers who make money other ways — and these can die off quickly if that beneficent employer runs into financial hardship — for many people who have to put bread on the table, they have to move to an “open core”, where some base functionality is given away, while value-added functionality is commercialized.

Analogies aside, the specific reasons are “reciprocity, mutual benefit, or building communal goodwill ”commonweal.” Both based in the informal ethical concept of “equity”. If you received free software, and then make money off it through baking it into a proprietary offering, and you do not share those earnings with the original creator, some creators may find that fair” that was their intent, for you and others to be able to commercialize your efforts using their freely-provided software. Yet others may find this commercialization exploitative. They may have wished for the software to remain free down the entire chain of use. And, if you decided to introduce the concepts of capitalism and commercialization into this otherwise purely free and open source software world, they want you to share your proceeds with the creator who enabled that. Both of those choices ”to let you commercialize without any form of recompense, code contribution or other reciprocity, or to ask for a cut of the action” both should be permitted in the modern world.

RS – the reason is plain and simple: it is good for business. As Bill Joy (a founder of Sun microsystems and one of the smartest people alive) used to say “Innovation always happens elsewhere”. Do you want to be cut off from that innovation or do you want to be the first one to leverage it? And you know what, these days, most of the time elsewhere == open source communities. So again — stop thinking in terms of giving back and taking from — think in terms of directly participating vs. staying on the side lines. Once you assume that viewpoint the rest is easy.

[STR] – Giving back to open source makes sense for many reasons. Companies monetizing open source, big or small, benefit from continued improvements to open source which they can then make available and build on top of to the benefit of their customers. Those companies also benefit because many of their customers are increasingly looking to open source to help them avoid vendor lock-in, and as a result see those vendors contributing to open source as the best guarantors of the continued openness of the core technology and of the interfaces on which other applications need to rely.

The Apache Software Foundation focuses on community over code. Do you believe that a new user of a project is more valuable than a code contribution?

JA – That’s a tough call. I think early on you need users over code. The project needs more adoption and the project founders can keep the code moving. Later on, you need code. The founders get tired or pulled away and you need other people to step up and contribute.

PC – there is an interrelationship. What if you wrote code in the woods, and no one compiled or ran it? Creators, consumers/users, the code/product, and the benefit/output itself are all elements of an ecosystem. They all need each other to do some work to create that benefit or output. What you are talking about is a complex calculus, not a zero-sum ratio.

RS – this is like asking whether the front wheel of a bike is more valuable than the rear wheel. Without either — there’s no bike. I do, however, believe that in our “rock star developer” dominated culture we tend to put a significant premium on code contributions at the expense of encouraging other kinds of contributions. That’s just wrong. In fact, ASF has been engaged in a few productive discussion around what it would take us to bootstrap entirely non-coding open source communities (think graphic design, etc.). I’d love for more of these conversations to happen.

[STR] – – It’s a false choice to try to prioritize one over the other–the two are interdependent. The nature of open source makes it easier for different entities to focus on different aspects, but ultimately an open source project without contributors can’t survive, and without users the work of contributors is for nothing. Early in a project’s life cycle, users are more important than contributors in order to help guide the needs for the technology without the coordination complexity of having lots of contributors. When a project matures, contributors become more important to help fill in all of the pieces that are necessary for broad adoption, quality and stability of a project.

Some projects have changed their licenses to prevent running their technology as a cloud service. What do you think, if anything, should be done to change licenses to prevent companies from running their open source technology as a service?

JA – I don’t think the license should change. Can you imagine it if the Linux license said you can run Linux anywhere except on the cloud? The whole cloud movement would have never started or would be different.

PC – there needs to be a grammar of multiparty relationships and the intellectual property rights transferred between them.

I might want my mom to be able to use my software for free in perpetuity. I might want Jeff Bezos and crew themselves to pay me hourly, and directly charge their credit card. No money in the account? Service ends there and then. I might allow Jeff & crew to let others use it from his servers if he cuts me a monthly or annual check. What he charges those folks I might want to set, or might allow regulators to set, or might not care — let him charge the going rate.

We don’t even have a grammar to describe those intents.

RS – I have no problem with companies coming up with elaborate licensing terms for their products. That said, the more obstacles you put in place for users of your software the further from the ethos of open source you stand. Compelling your users to give something (of equal value) back is fair. Flatly rejecting certain use-cases simply via licensing terms is simply not open source.

[STR] – The creators of new projects have every right at the time they decide to open source their project to choose which type of license they use, balancing the broader adoption benefit of a more open license with the greater control of the product and its commercialization that is associated with less open licences. However, changing a license to something more restrictive once a project has gained adoption is at best a misguided attempt to reassert a form of control over a project that no longer makes sense. Trying to thread the needle of controlling who can and cannot use open source software and for what purpose is at best extremely difficult and at worst impossible. Further, changing a license for existing software antagonizes the users of that software with fears about whether other value might be kept locked up in the future and leading to restricted forks of the core software that hinder the success of the project overall. Instead of fiddling with licenses, vendors should be focused on how to deliver value add that does not rely on controlling software.

People have said that open source companies are trying to have their cake and eat it too. They’re open source, but they’re trying to be proprietary at the same time and only wanting their company to commercialize the project. Do you believe this is the case?

JA – Companies are really playing hardball with the ASF as a proxy for this fight. Some companies are preventing other companies from becoming committers to prevent the other company from being seen as viable competition. Still others are keeping their PMC (Project Management Committee) to a single company to prevent any outsider involvement. In essence, they’re making the feature roadmap proprietary by keeping their finger on the button of any commits. For most projects though, they want a fair playing field where everyone gives back.

PC – There is chaos because there are limited license vehicles, and yet a plethora of use cases before us.

For example, and being only semi-facetious, where’s the license for “open source, except Nazis?” There is no such way to make explicit cut outs. There is no “white listing” or “blacklisting” grammar. How you enforce that is even beyond the grammar, but we don’t even have licenses that describe such conditionals.

What open source providers are looking for is a way so that they are not being the Little Red Hen to the big cloud providers. Making all the bread, and watching others eat every bit of it.

They would gladly make bread for those who are hungry. But they don’t want to starve to death themselves, or be exploited by the gluttons of the world, who can clearly afford the bread.

How do we make this fair. That’s what’s at stake.

RS – first of all, there are clearly examples of great, honest open source companies doing impressive amounts of business with very classical definition of open source (there’s typically a correlation of how good their product or service is with how easy it is for them to be a great open source business). At the same time, with Silicon Valley valuations getting as ridiculous as they have gotten it was inevitable that at some point that boards and VCs started looking for pennies between proverbial cushions. This led to this desire to have your cake and eat it too and it is very much a real phenomenon. All I can say — when business start to optimize for every last drop of profitability (sometimes at an expense of longer term growth even) strange and weird things start to happen. This latest wave of “commercial open source” is not even the strangest one.

[STR] – For many years the interests of companies built around open source and the open source communities around associated projects were largely aligned–both wanted broadly adopted technology that fostered collaborative innovation while at the same time providing the maturity and support that enterprises needed to be comfortable in adopting it. Today, the success of open source projects and the success of companies built around open source have begun to diverge. The efforts by vendors to control the direction and use of open source technologies, largely for their own commercial benefit, are clear evidence of that–they restrict access and contributions in ways that risk splintering the software and hindering broader adoption. These efforts seem to be intensifying as the threat from cloud platform vendors becomes more widespread.

Much of this discussion stems from the open source business models and the difficulties of monetizing something that is free and open source. Do you think business models need to change or something else?

JA – Open source business models need to change in the face of the cloud. I think companies need to create managed services of their products sooner. Ideally, they’d innovate by adding more value rather than just creating a managed service. This way, a cloud provider can’t be at parity with an open source company by just standing up their own managed service. There needs to more innovation and value add.

PC – business models will change as technology advancements permit. It’s not even a matter of what I think. They are. And the world of software distribution, licensing, usage rights and intellectual property rights needs to adapt. Desperately.

RS – open source business model absolutely need to evolve to become “Cloud Native”. I will go as far as to say that you may even drop “open source” from that. Business models need to become “cloud native”. Period. With Cloud becoming the predominant software delivery model pretending that it is business as usual is as smart as pretending that Internet wasn’t happening back in the 90s. Open Source business models are just a recent victim of relentless march of “Cloud Native. Before that Cloud ate up very traditional business models like Borders, Blockbuster, your local taxi service, etc. Why do we expect open source business models to be any different?

[STR] – Companies built around commercializing open source are clearly facing a quandary when it comes to finding a sustainable business model. The early model of charging for support and services but keeping the software fully open source (of which RedHat and Hortonworks are clear examples) has been great for adoption, but with the rise of a small number of dominant cloud platform providers that model has left independent and especially smaller software providers feeling squeezed. To adapt to this reality, the business models for open source need to change. Basic support for mature, stable technology can be provided by any number of vendors (and at a lower cost in the case of cloud platform providers) and so is a difficult business model for most companies. However, innovative and differentiated cloud services based on those technologies are still important to customers and thus point to a more viable business model, particularly when they can provide solutions that can be used on multiple cloud providers’ platforms as well as in hybrid cloud environments.

Do you think a company’s obligation to give back grow relative to their size or revenue generated from the project?

JA – I think this growth of giving back happens more organically. By growing their market share, a company has to grow its developer footprint to keep up. The growth leads to more customer expectations of new features and service improvements. This requires that a company contribute these improvements back to the open source project. There’s a systemic risk when bigger companies don’t give back. Why should an open source company pay a developer to improve the product when a provider can just come along and use it? I’m worried that this will cause the open source companies to cut back on what they give to open source. We’re already seeing this in one major open source project. The open source company is keeping major features (that belong in the product and not value adds) back to keep their customers on their cloud product.

PC – Number of users, or income/market cap, are a few ways to consider value and fairness. Sweat equity (code committing) is another. But one good coder’s 30 line commit, say, of an algorithm, might be insanely powerful, while another party’s 3,000 line commit might break the product and be effectively worthless. Value of contribution needs to have a way to measure it that is also somewhat “fair” and right now, that’s all a black art too.

RS – if you look at it from “they have a moral right to give back” perspective — absolutely not! I have a big problem with people who think that if a company makes millions off of a project they don’t owe anything, but if the company starts making billions all of a sudden they are on a hook to give back. That’s just weird to me. However, if you look at it from the “participating in the community is a smart way to do business” perspective than of course — the bigger you grow the more you’ve got to lose and the bigger your forcing function for actually doing the right thing becomes.

Can a complex open source project survive without companies employing full-time software developers to work on it?

JA – You can’t get to the levels of complexity in projects like Hadoop, Spark, or Kafka without working on it full-time. It requires too much head space and context to make changes. It’s even more difficult to create cohesive roadmap. I don’t think our current expectations and project velocities can be maintained without full-time software developers working on them.

PC – for a while, in a way, sort of, kind of. But I wouldn’t want free crowdsourced dental surgery. I’d want a trained professional. After some time, there needs to be a way to pay people for their time, expertise and efforts. Non-profits, crowdfunding, etc., can help, and may be a viable model for some work. But existing conventions of software licensing should not be dictating nor precluding new and novel business models. Even non-profit models, or unincorporated “clubs/associations” can work to ensure their costs are covered, and some members may even earn a living off their activities.

RS – yes — compex project can’t survive without full time developers. No — being employed is not the only way to work full time on a project. Interestingly enough, in Europe (where a social safety net around things like health and dependent care is much stronger) you tend to have much more full time developers on a project who are not full-time employees. With US the situation is different, but it has little to do with mechanics of open source in my opinion.

PC (commenting on RS): Basic income guarantees would definitely allow some level of participations across economic strata, yet there is also an educational requirement to even approach some of these open source projects. And income disparity plays a critical part in educational disparity.
In the face of this what we see sometimes is, and would continue to see, are high-end “software dilettantes” people who can afford to code without drawing a salary. I don’t mean to denigrate their skills; they are often extremely talented. Only: they may be people who already made their fortune elsewhere and elsewise (ex: cashing out of a startup), or who have some other income stream, and don’t need to draw a salary in a conventional sense.

This goes beyond open source licensing into the very social cybernetics (as in structures, constraints and possibilities) of the information economy. Open source began as a way to fundamentally change the way software was produced and consumed, with an emphasis on equity and commonweal. As a species, we must continue to adapt to new systemic structures that are being enabled by technology. Open source is only one element of a successful information economy. At some point, people need to be able to be rewarded for their efforts, and others need to be able to use their efforts to achieve their own desired payoffs and accomplish their own goals.

But, again, this goes into a far larger, broader analysis of the information economy than a mere analysis of “licensing” can achieve. A license is just a reification of a right-of-use. There are a broad, sweeping series of assumptions to how licensing works in the early 21st Century, and I think we need to elevate the game and look at the basic information economy with this fundamental rule in mind, and its first corollary:

• Whatever you reward, you will get more of
• So be careful what you reward.

However, while such societal engineering to design an open source planetary Nirvana will be ongoing for decades, back to the Little Red Hen. We’re going to have to ensure, in the short and mid-term, that open source creators are not starved, while others gorge themselves off their creations.

[STR] – Complex software is difficult to maintain and innovate without people working full time on it. There are certainly places where smaller contributions made by occasional contributors are valuable, but to enable architectural and other innovations as well as to ensure robustness of any complex software, developers who have a deep understanding of how the software works are needed–something that is difficult to achieve without a significant focus on that software. As a result, complex projects that do not have people who are paid to spend a significant share of their time working on those projects can often struggle to evolve and mature as quickly as those that do. There are some contributors who have the financial stability and means to contribute to open source purely out of personal interest, but open source communities will be not only smaller but also weaker if it is only viable for people with such resources to contribute.