Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 9 hours 55 min ago

Dries Buytaert: Balancing Makers and Takers to scale and sustain Open Source

Thu, 2019/09/19 - 2:51pm

In many ways, Open Source has won. Most people know that Open Source provides better quality software, at a lower cost, without vendor lock-in. But despite Open Source being widely adopted and more than 30 years old, scaling and sustaining Open Source projects remains challenging.

Not a week goes by that I don't get asked a question about Open Source sustainability. How do you get others to contribute? How do you get funding for Open Source work? But also, how do you protect against others monetizing your Open Source work without contributing back? And what do you think of MongoDB, Cockroach Labs or Elastic changing their license away from Open Source?

This blog post talks about how we can make it easier to scale and sustain Open Source projects, Open Source companies and Open Source ecosystems. I will show that:

  • Small Open Source communities can rely on volunteers and self-governance, but as Open Source communities grow, their governance model most likely needs to be reformed so the project can be maintained more easily.
  • There are three models for scaling and sustaining Open Source projects: self-governance, privatization, and centralization. All three models aim to reduce coordination failures, but require Open Source communities to embrace forms of monitoring, rewards and sanctions. While this thinking is controversial, it is supported by decades of research in adjacent fields.
  • Open Source communities would benefit from experimenting with new governance models, coordination systems, license innovation, and incentive models.
Some personal background

Scaling and sustaining Open Source projects and Open Source businesses has been the focus of most of my professional career.

Drupal, the Open Source project I founded 18 years ago, is used by more than one million websites and reaches pretty much everyone on the internet.

With over 8,500 individuals and about 1,100 organizations contributing to Drupal annually, Drupal is one of the healthiest and contributor-rich Open Source communities in the world.

For the past 12 years, I've also helped build Acquia, an Open Source company that heavily depends on Drupal. With almost 1,000 employees, Acquia is the largest contributor to Drupal, yet responsible for less than 5% of all contributions.

This article is not about Drupal or Acquia; it's about scaling Open Source projects more broadly.

I'm interested in how to make Open Source production more sustainable, more fair, more egalitarian, and more cooperative. I'm interested in doing so by redefining the relationship between end users, producers and monetizers of Open Source software through a combination of technology, market principles and behavioral science.

Why it must be easier to scale and sustain Open Source

We need to make it easier to scale and sustain both Open Source projects and Open Source businesses:

  1. Making it easier to scale and sustain Open Source projects might be the only way to solve some of the world's most important problems. For example, I believe Open Source to be the only way to build a pro-privacy, anti-monopoly, open web. It requires Open Source communities to be long-term sustainable — possibly for hundreds of years.
  2. Making it easier to grow and sustain Open Source businesses is the last hurdle that prevents Open Source from taking over the world. I'd like to see every technology company become an Open Source company. Today, Open Source companies are still extremely rare.

The alternative is that we are stuck in the world we live in today, where proprietary software dominates most facets of our lives.

Disclaimers

This article is focused on Open Source governance models, but there is more to growing and sustaining Open Source projects. Top of mind is the need for Open Source projects to become more diverse and inclusive of underrepresented groups.

Second, I understand that the idea of systematizing Open Source contributions won't appeal to everyone. Some may argue that the suggestions I'm making go against the altruistic nature of Open Source. I agree. However, I'm also looking at Open Source sustainability challenges from the vantage point of running both an Open Source project (Drupal) and an Open Source business (Acquia). I'm not implying that every community needs to change their governance model, but simply offering suggestions for communities that operate with some level of commercial sponsorship, or communities that struggle with issues of long-term sustainability.

Lastly, this post is long and dense. I'm 700 words in, and I haven't started yet. Given that this is a complicated topic, there is an important role for more considered writing and deeper thinking.

Defining Open Source Makers and Takers Makers

Some companies are born out of Open Source, and as a result believe deeply and invest significantly in their respective communities. With their help, Open Source has revolutionized software for the benefit of many. Let's call these types of companies Makers.

As the name implies, Makers help make Open Source projects; from investing in code, to helping with marketing, growing the community of contributors, and much more. There are usually one or more Makers behind the success of large Open Source projects. For example, MongoDB helps make MongoDB, Red Hat helps make Linux, and Acquia (along with many other companies) helps make Drupal.

Our definition of a Maker assumes intentional and meaningful contributions and excludes those whose only contributions are unintentional or sporadic. For example, a public cloud company like Amazon can provide a lot of credibility to an Open Source project by offering it as-a-service. The resulting value of this contribution can be substantial, however that doesn't make Amazon a Maker in our definition.

I use the term Makers to refer to anyone who purposely and meaningfully invests in the maintenance of Open Source software, i.e. by making engineering investments, writing documentation, fixing bugs, organizing events, and more.

Takers

Now that Open Source adoption is widespread, lots of companies, from technology startups to technology giants, monetize Open Source projects without contributing back to those projects. Let's call them Takers.

I understand and respect that some companies can give more than others, and that many might not be able to give back at all. Maybe one day, when they can, they'll contribute. We limit the label of Takers to companies that have the means to give back, but choose not to.

The difference between Makers and Takers is not always 100% clear, but as a rule of thumb, Makers directly invest in growing both their business and the Open Source project. Takers are solely focused on growing their business and let others take care of the Open Source project they rely on.

Organizations can be both Takers and Makers at the same time. For example, Acquia, my company, is a Maker of Drupal, but a Taker of Varnish Cache. We use Varnish Cache extensively but we don't contribute to its development.

Takers hurt Makers

To be financially successful, many Makers mix Open Source contributions with commercial offerings. Their commercial offerings usually take the form of proprietary or closed source IP, which may include a combination of premium features and hosted services that offer performance, scalability, availability, productivity, and security assurances. This is known as the Open Core business model. Some Makers offer professional services, including maintenance and support assurances.

When Makers start to grow and demonstrate financial success, the Open Source project that they are associated with begins to attract Takers. Takers will usually enter the ecosystem with a commercial offering comparable to the Makers', but without making a similar investment in Open Source contribution. Because Takers don't contribute back meaningfully to the Open Source project that they take from, they can focus disproportionately on their own commercial growth.

Let's look at a theoretical example.

When a Maker has $1 million to invest in R&D, they might choose to invest $500k in Open Source and $500k in the proprietary IP behind their commercial offering. The Maker intentionally balances growing the Open Source project they are connected to with making money. To be clear, the investment in Open Source is not charity; it helps make the Open Source project competitive in the market, and the Maker stands to benefit from that.

When a Taker has $1 million to invest in R&D, nearly all of their resources go to the development of proprietary IP behind their commercial offerings. They might invest $950k in their commercial offerings that compete with the Maker's, and $50k towards Open Source contribution. Furthermore, the $50k is usually focused on self-promotion rather than being directed at improving the Open Source project itself.

Effectively, the Taker has put itself at a competitive advantage compared to the Maker:

  • The Taker takes advantage of the Maker's $500k investment in Open Source contribution while only investing $50k themselves. Important improvements happen "for free" without the Taker's involvement.
  • The Taker can out-innovate the Maker in building proprietary offerings. When a Taker invests $950k in closed-source products compared to the Maker's $500k, the Taker can innovate 90% faster. The Taker can also use the delta to disrupt the Maker on price.

In other words, Takers reap the benefits of the Makers' Open Source contribution while simultaneously having a more aggressive monetization strategy. The Taker is likely to disrupt the Maker. On an equal playing field, the only way the Maker can defend itself is by investing more in its proprietary offering and less in the Open Source project. To survive, it has to behave like the Taker to the detriment of the larger Open Source community.

Takers harm Open Source projects. An aggressive Taker can induce Makers to behave in a more selfish manner and reduce or stop their contributions to Open Source altogether. Takers can turn Makers into Takers.

Open Source contribution and the Prisoner's Dilemma

The example above can be described as a Prisoner's Dilemma. The Prisoner's Dilemma is a standard example of game theory, which allows the study of strategic interaction and decision-making using mathematical models. I won't go into detail here, but for the purpose of this article, it helps me simplify the above problem statement. I'll use this simplified example throughout the article.

Imagine an Open Source project with only two companies supporting it. The rules of the game are as follows:

  • If both companies contribute to the Open Source project (both are Makers), the total reward is $100. The reward is split evenly and each company makes $50.
  • If one company contributes while the other company doesn't (one Maker, one Taker), the Open Source project won't be as competitive in the market, and the total reward will only be $80. The Taker gets $60 as they have the more aggressive monetization strategy, while the Maker gets $20.
  • If both players choose not to contribute (both are Takers), the Open Source project will eventually become irrelevant. Both walk away with just $10.

This can be summarized in a pay-off matrix:

Company A contributes Company A doesn't contribute Company B contributes A makes $50
B makes $50 A makes $60
B makes $20 Company B doesn't contribute A makes $20
B makes $60 A makes $10
B makes $10

In the game, each company needs to decide whether to contribute or not, but Company A doesn't know what company B decides; and vice versa.

The Prisoner's Dilemma states that each company will optimize its own profit and not contribute. Because both companies are rational, both will make that same decision. In other words, when both companies use their "best individual strategy" (be a Taker, not a Maker), they produce an equilibrium that yields the worst possible result for the group: the Open Source project will suffer and as a result they only make $10 each.

A real-life example of the Prisoner's Dilemma that many people can relate to is washing the dishes in a shared house. By not washing dishes, an individual can save time (individually rational), but if that behavior is adopted by every person in the house, there will be no clean plates for anyone (collectively irrational). How many of us have tried to get away with not washing the dishes? I know I have.

Fortunately, the problem of individually rational actions leading to collectively adverse outcomes is not new or unique to Open Source. Before I look at potential models to better sustain Open Source projects, I will take a step back and look at how this problem has been solved elsewhere.

Open Source: a public good or a common good?

In economics, the concepts of public goods and common goods are decades old, and have similarities to Open Source.

Public goods and common goods are what economists call non-excludable meaning it's hard to exclude people from using them. For example, everyone can benefit from fishing grounds, whether they contribute to their maintenance or not. Simply put, public goods and common goods have open access.

Common goods are rivalrous; if one individual catches a fish and eats it, the other individual can't. In contrast, public goods are non-rivalrous; someone listening to the radio doesn't prevent others from listening to the radio.

I've long believed that Open Source projects are public goods: everyone can use Open Source software (non-excludable) and someone using an Open Source project doesn't prevent someone else from using it (non-rivalrous).

However, through the lens of Open Source companies, Open Source projects are also common goods; everyone can use Open Source software (non-excludable), but when an Open Source end user becomes a customer of Company A, that same end user is unlikely to become a customer of Company B (rivalrous).

For end users, Open Source projects are public goods; the shared resource is the software. But for Open Source companies, Open Source projects are common goods; the shared resource is the (potential) customer.

Next, I'd like to extend the distinction between "Open Source software being a public good" and "Open Source customers being a common good" to the the free-rider problem: we define software free-riders as those who use the software without ever contributing back, and customer free-riders (or Takers) as those who sign up customers without giving back.

All Open Source communities should encourage software free-riders. Because the software is a public good (non-rivalrous), a software free-rider doesn't exclude others from using the software. Hence, it's better to have a user for your Open Source project, than having that person use your competitor's software. Furthermore, a software free-rider makes it more likely that other people will use your Open Source project (by word of mouth or otherwise). When some portion of those other users contribute back, the Open Source project benefits. Software free-riders can have positive network effects on a project.

However, when the success of an Open Source project depends largely on one or more corporate sponsors, the Open Source community should not forget or ignore that customers are a common good. Because a customer can't be shared among companies, it matters a great deal for the Open Source project where that customer ends up. When the customer signs up with a Maker, we know that a certain percentage of the revenue associated with that customer will be invested back into the Open Source project. When a customer signs up with a customer free-rider or Taker, the project doesn't stand to benefit. In other words, Open Source communities should find ways to route customers to Makers.

Both volunteer-driven and sponsorship-driven Open Source communities should encourage software free-riders, but sponsorship-driven Open Source communities should discourage customer free-riders.

Lessons from decades of Common Goods management

Hundreds of research papers and books have been written on public good and common good governance. Over the years, I have read many of them to figure out what Open Source communities can learn from successfully managed public goods and common goods.

Some of the most instrumental research was Garrett Hardin's Tragedy of the Commons and Mancur Olson's work on Collective Action. Both Hardin and Olson concluded that groups don't self-organize to maintain the common goods they depend on.

As Olson writes in the beginning of his book, The Logic of Collective Action: Unless the number of individuals is quite small, or unless there is coercion or some other special device to make individuals act in their common interest, rational, self-interested individuals will not act to achieve their common or group interest..

Consistent with the Prisoner's Dilemma, Hardin and Olson show that groups don't act on their shared interests. Members are disincentivized from contributing when other members can't be excluded from the benefits. It is individually rational for a group's members to free-ride on the contributions of others.

Dozens of academics, Hardin and Olson included, argued that an external agent is required to solve the free-rider problem. The two most common approaches are (1) centralization and (2) privatization:

  1. When a common good is centralized, the government takes over the maintenance of the common good. The government or state is the external agent.
  2. When a public good is privatized, one or more members of the group receive selective benefits or exclusive rights to harvest from the common good in exchange for the ongoing maintenance of the common good. In this case, one or more corporations act as the external agent.

The wide-spread advice to centralize and privatize common goods has been followed extensively in most countries; today, the management of natural resources is typically managed by either the government or by commercial companies, but no longer directly by its users. Examples include public transport, water utilities, fishing grounds, parks, and much more.

Overall, the privatization and centralization of common goods has been very successful; in many countries, public transport, water utilities and parks are maintained better than volunteer contributors would have on their own. I certainly value that I don't have to help maintain the train tracks before my daily commute to work, or that I don't have to help mow the lawn in our public park before I can play soccer with my kids.

For years, it was a long-held belief that centralization and privatization were the only way to solve the free-rider problem. It was Elinor Ostrom who observed that a third solution existed.

Ostrom found hundreds of cases where common goods are successfully managed by their communities, without the oversight of an external agent. From the management of irrigation systems in Spain to the maintenance of mountain forests in Japan — all have been successfully self-managed and self-governed by their users. Many have been long-enduring as well; the youngest examples she studied were more than 100 years old, and the oldest exceed 1,000 years.

Ostrom studied why some efforts to self-govern commons have failed and why others have succeeded. She summarized the conditions for success in the form of core design principles. Her work led her to win the Nobel Prize in Economics in 2009.

Interestingly, all successfully managed commons studied by Ostrom switched at some point from open access to closed access. As Ostrom writes in her book, Governing the Commons: For any appropriator to have a minimal interest in coordinating patterns of appropriation and provision, some set of appropriators must be able to exclude others from access and appropriation rights.. Ostrom uses the term appropriator to refer to those who use or withdraw from a resource. Examples would be fishers, irrigators, herders, etc — or companies trying to turn Open Source users into paying customers. In other words, the shared resource must be made exclusive (to some degree) in order to incentivize members to manage it. Put differently, Takers will be Takers until they have an incentive to become Makers.

Once access is closed, explicit rules need to be established to determine how resources are shared, who is responsible for maintenance, and how self-serving behaviors are suppressed. In all successfully managed commons, the regulations specify (1) who has access to the resource, (2) how the resource is shared, (3) how maintenance responsibilities are shared, (4) who inspects that rules are followed, (5) what fines are levied against anyone who breaks the rules, (6) how conflicts are resolved and (7) a process for collectively evolving these rules.

Three patterns for long-term sustainable Open Source

Studying the work of Garrett Hardin (Tragedy of the Commons), the Prisoner's Dilemma, Mancur Olson (Collective Action) and Elinor Ostrom's core design principles for self-governance, a number shared patterns emerge. When applied to Open Source, I'd summarize them as follows:

  1. Common goods fail because of a failure to coordinate collective action. To scale and sustain an Open Source project, Open Source communities need to transition from individual, uncoordinated action to cooperative, coordinated action.
  2. Cooperative, coordinated action can be accomplished through privatization, centralization, or self-governance. All three work — and can even be mixed.
  3. Successful privatization, centralization, and self-governance all require clear rules around membership, appropriation rights, and contribution duties. In turn, this requires monitoring and enforcement, either by an external agent (centralization + privatization), a private agent (self-governance), or members of the group itself (self-governance).

Next, let's see how these three concepts — centralization, privatization and self-governance — could apply to Open Source.

Model 1: Self-governance in Open Source

For small Open Source communities, self-governance is very common; it's easy for its members to communicate, learn who they can trust, share norms, agree on how to collaborate, etc.

As an Open Source project grows, contribution becomes more complex and cooperation more difficult: it becomes harder to communicate, build trust, agree on how to cooperate, and suppress self-serving behaviors. The incentive to free-ride grows.

You can scale successful cooperation by having strong norms that encourage other members to do their fair share and by having face-to-face events, but eventually, that becomes hard to scale as well.

As Ostrom writes in Governing the Commons: Even in repeated settings where reputation is important and where individuals share the norm of keeping agreements, reputation and shared norms are insufficient by themselves to produce stable cooperative behavior over the long run. and In all of the long-enduring cases, active investments in monitoring and sanctioning activities are quite apparent..

To the best of my knowledge, no Open Source project currently implements Ostrom's design principles for successful self-governance. To understand how Open Source communities might, let's go back to our running example.

Our two companies would negotiate rules for how to share the rewards of the Open Source project, and what level of contribution would be required in exchange. They would set up a contract where they both agree on how much each company can earn and how much each company has to invest. During the negotiations, various strategies can be proposed for how to cooperate. However, both parties need to agree on a strategy before they can proceed. Because they are negotiating this contract among themselves, no external agent is required.

These negotiations are non-trivial. As you can imagine, any proposal that does not involve splitting the $100 fifty-fifty is likely rejected. The most likely equilibrium is for both companies to contribute equally and to split the reward equally. Furthermore, to arrive at this equilibrium, one of the two companies would likely have to go backwards in revenue, which might not be agreeable.

Needless to say, this gets even more difficult in a scenario where there are more than two companies involved. Today, it's hard to fathom how such a self-governance system can successfully be established in an Open Source project. In the future, Blockchain-based coordination systems might offer technical solutions for this problem.

Large groups are less able to act in their common interest than small ones because (1) the complexity increases and (2) the benefits diminish. Until we have better community coordination systems, it's easier for large groups to transition from self-governance to privatization or centralization than to scale self-governance.

The concept of major projects growing out of self-governed volunteer communities is not new to the world. The first trade routes were ancient trackways which citizens later developed on their own into roads suited for wheeled vehicles. Privatization of roads improved transportation for all citizens. Today, we certainly appreciate that our governments maintain the roads.

Model 2: Privatization of Open Source governance

In this model, Makers are rewarded unique benefits not available to Takers. These exclusive rights provide Makers a commercial advantage over Takers, while simultaneously creating a positive social benefit for all the users of the Open Source project, Takers included.

For example, Mozilla has the exclusive right to use the Firefox trademark and to set up paid search deals with search engines like Google, Yandex and Baidu. In 2017 alone, Mozilla made $542 million from searches conducted using Firefox. As a result, Mozilla can make continued engineering investments in Firefox. Millions of people and organizations benefit from that every day.

Another example is Automattic, the company behind WordPress. Automattic is the only company that can use WordPress.com, and is in the unique position to make hundreds of millions of dollars from WordPress' official SaaS service. In exchange, Automattic invests millions of dollars in the Open Source WordPress each year.

Recently, there have been examples of Open Source companies like MongoDB, Redis, Cockroach Labs and others adopting stricter licenses because of perceived (and sometimes real) threats from public cloud companies that behave as Takers. The ability to change the license of an Open Source project is a form of privatization.

Model 3: Centralization of Open Source governance

Let's assume a government-like central authority can monitor Open Source companies A and B, with the goal to reward and penalize them for contribution or lack thereof. When a company follows a cooperative strategy (being a Maker), they are rewarded $25 and when they follow a defect strategy (being a Taker), they are charged a $25 penalty. We can update the pay-off matrix introduced above as follows:

Company A contributes Company A doesn't contribute Company B contributes A makes $75 ($50 + $25)
B makes $75 ($50 + $25) A makes $35 ($60 - $25)
B makes $45 ($20 + 25) Company B doesn't contribute A makes $45 ($20 + $25)
B makes $35 ($60 - $25) A makes $0 ($10 - $25)
B makes $0 ($10 - $25)

We took the values from the pay-off matrix above and applied the rewards and penalties. The result is that both companies are incentivized to contribute and the optimal equilibrium (both become Makers) can be achieved.

The money for rewards could come from various fundraising efforts, including membership programs or advertising (just as a few examples). However, more likely is the use of indirect monetary rewards.

One way to implement this is Drupal's credit system. Drupal's non-profit organization, the Drupal Association monitors who contributes what. Each contribution earns you credits and the credits are used to provide visibility to Makers. The more you contribute, the more visibility you get on Drupal.org (visited by 2 million people each month) or at Drupal conferences (called DrupalCons, visited by thousands of people each year).

A screenshot of an issue comment on Drupal.org. You can see that jamadar worked on this patch as a volunteer, but also as part of his day job working for TATA Consultancy Services on behalf of their customer, Pfizer.

While there is a lot more the Drupal Association could and should do to balance its Makers and Takers and achieve a more optimal equilibrium for the Drupal project, it's an emerging example of how an Open Source non-profit organization can act as a regulator that monitors and maintains the balance of Makers and Takers.

The big challenge with this approach is the accuracy of the monitoring and the reliability of the rewarding (and sanctioning). Because Open Source contribution comes in different forms, tracking and valuing Open Source contribution is a very difficult and expensive process, not to mention full of conflict. Running this centralized government-like organization also needs to be paid for, and that can be its own challenge.

Concrete suggestions for scaling and sustaining Open Source Suggestion 1: Don't just appeal to organizations' self-interest, but also to their fairness principles

If, like most economic theorists, you believe that organizations act in their own self-interest, we should appeal to that self-interest and better explain the benefits of contributing to Open Source.

Despite the fact that hundreds of articles have been written about the benefits of contributing to Open Source — highlighting speed of innovation, recruiting advantages, market credibility, and more — many organizations still miss these larger points.

It's important to keep sharing Open Source success stories. One thing that we have not done enough is appeal to organizations' fairness principles.

While a lot of economic theories correctly assume that most organizations are self-interested, I believe some organizations are also driven by fairness considerations.

Despite the term "Takers" having a negative connotation, it does not assume malice. For many organizations, it is not apparent if an Open Source project needs help with maintenance, or how one's actions, or lack thereof, might negatively affect an Open Source project.

As mentioned, Acquia is a heavy user of Varnish Cache. But as Acquia's Chief Technology Officer, I don't know if Varnish needs maintenance help, or how our lack of contribution negatively affects Makers in the Varnish community.

It can be difficult to understand the consequences of our own actions within Open Source. Open Source communities should help others understand where contribution is needed, what the impact of not contributing is, and why certain behaviors are not fair. Some organizations will resist unfair outcomes and behave more cooperatively if they understand the impact of their behaviors and the fairness of certain outcomes.

Make no mistake though: most organizations won't care about fairness principles; they will only contribute when they have to. For example, most people would not voluntarily redistribute 25-50% of their income to those who need it. However, most of us agree to redistribute money by paying taxes, but only so long as all others have to do so as well.

Suggestion 2: Encourage end users to offer selective benefits to Makers

We talked about Open Source projects giving selective benefits to Makers (e.g. Automattic, Mozilla, etc), but end users can give selective benefits as well. For example, end users can mandate Open Source contributions from their partners. We have some successful examples of this in the Drupal community:

If more end users of Open Source took this stance, it could have a very big impact on Open Source sustainability. For governments, in particular, this seems like a very logical thing to do. Why would a government not want to put every dollar of IT spending back in the public domain? For Drupal alone, the impact would be measured in tens of millions of dollars each year.

Suggestion 3: Experiment with new licenses

I believe we can create licenses that support the creation of Open Source projects with sustainable communities and sustainable businesses to support it.

For a directional example, look at what MariaDB did with their Business Source License (BSL). The BSL gives users complete access to the source code so users can modify, distribute and enhance it. Only when you use more than x of the software do you have to pay for a license. Furthermore, the BSL guarantees that the software becomes Open Source over time; after y years, the license automatically converts from BSL to General Public License (GPL), for example.

A second example is the Community Compact, a license proposed by Adam Jacob. It mixes together a modern understanding of social contracts, copyright licensing, software licensing, and distribution licensing to create a sustainable and harmonious Open Source project.

We can create licenses that better support the creation, growth and sustainability of Open Source projects and that are designed so that both users and the commercial ecosystem can co-exist and cooperate in harmony.

I'd love to see new licenses that encourage software free-riding (sharing and giving), but discourage customer free-riding (unfair competition). I'd also love to see these licenses support many Makers, with built-in inequity and fairness principles for smaller Makers or those not able to give back.

If, like me, you believe there could be future licenses that are more "Open Source"-friendly, not less, it would be smart to implement a contributor license agreement for your Open Source project; it allows Open Source projects to relicense if/when better licenses arrive. At some point, current Open Source licenses will be at a disadvantage compared to future Open Source licenses.

Conclusions

As Open Source communities grow, volunteer-driven, self-organized communities become harder to scale. Large Open Source projects should find ways to balance Makers and Takers or the Open Source project risks not innovating enough under the weight of Takers.

Fortunately, we don't have to accept that future. However, this means that Open Source communities potentially have to get comfortable experimenting with how to monitor, reward and penalize members in their communities, particularly if they rely on a commercial ecosystem for a large portion of their contributions. Today, that goes against the values of most Open Source communities, but I believe we need to keep an open mind about how we can grow and scale Open Source.

Making it easier to scale Open Source projects in a sustainable and fair way is one of the most important things we can work on. If we succeed, Open Source can truly take over the world — it will pave the path for every technology company to become an Open Source business, and also solve some of the world's most important problems in an open, transparent and cooperative way.

Categories:

Lullabot: Healthy Open Source Maintenance

Thu, 2019/09/19 - 6:49am

Open source has won! It powers software everywhere. From automated irrigation software, to supercomputer kernels. This has enabled the industry to evolve at a vertiginous pace that is changing the world. This has all been possible because developers around the globe can now use software for free, and learn from the source code. Developers are not rewriting the JPEG compression library; instead, they are solving more high-level problems because that problem has been solved and liberated.

Categories:

Tandem's Drupal Blog: Still on Drupal 6? Here are Your Options

Thu, 2019/09/19 - 2:00am
September 19, 2019 An informative guide for sites still on Drupal 6 Overview According to the usage statistics for Drupal core, there are still roughly 40,000 sites on Drupal 6. This number is most undoubtedly low, since this chart only shows sites that have the update status module enabled. There could still be well over 100,000 sites on Drup...
Categories:

BADCamp 2019: Register for Trainings at BADCamp!

Wed, 2019/09/18 - 8:37pm
Register for Trainings at BADCamp! Wed, 09/18/2019 - 12:00 volkswagenchick Wed, 09/18/2019 - 11:37

BADCamp is stoked to be offering two full days of trainings that can help advance your skills and career, led by some of the best teachers in the community.

Full-day trainings cost $50, and half-day trainings cost $25 to cover operating expenses. This year we are excited to be offering two free community workshops. 

Drupal Planet
Categories:

Tag1 Consulting: A Deep Dive Into Real Time Collaborative Editing Solutions - TagTeamTalk #001

Wed, 2019/09/18 - 8:34pm
What is real-time collaborative editing, and what are some of the most compelling technologies available in the space? In the inaugural TAG Team Talk, hosted by Preston So (Contributing Editor, Tag1 Consulting), we conduct a wide-ranging discussion about both the business prerogatives and technical ins-and-outs of real-time collaborative editing and its landscape today, with our guests Kevin Jahns (creator of Yjs and collaborative editing expert at Tag1 Consulting), Fabian Franz (Senior Technical Architect and Performance Lead, Tag1 Consulting), and Michael Meyers (Managing Director, Tag1 Consulting). In this talk, we explore collaborative editing, diving into how it works and some of the challenges borne by shared editing. Through the lens of Yjs, a real-time collaboration framework that supports not just text but also collaborating on drawings and 3-D models, we take a look at Operational Transformation (OT) and how implementing Conflict-free Replicated Data Types (CRDT) drives decentralized server approaches in collaborative editing and supports more robust distributed applications with true real-time support. Yjs: https://github.com/yjs/yjs ProseMirror: https://prosemirror.net Great Overview of CRDT https://conclave-team.github.io/conclave-site/#conflict-free-replicated-data-type-crdt Deep dive int CRDT by the author of Automerge: https://www.youtube.com/watch?v=yCcWpzY8dIA Yjs was inspired by: Sharedb https://github.com/share/sharedb DerbyJS https://derbyjs.com/ Text Transcript - Hello, good morning or good evening, wherever you are.... Read more michaelemeyers Wed, 09/18/2019 - 11:34
Categories:

Drupal Association blog: My first event: DrupalCamp Atlanta

Wed, 2019/09/18 - 7:17pm

Many thanks to Kaleem Clarkson (kclarkson) and his team for organizing a great DrupalCamp Atlanta. I had a time of learning, connecting and being inspired!

I started my day at DrupalCamp Atlanta by participating in the workshop “Introduction to Drupal,” led by longtime Drupal community member Doug Vann (dougvann). Joining me was Rudy Dodier, from Platform.sh. Doug covered everything from the history of Drupal, to setting up a basic website to how the word “system” in Content Management System can be an acronym for: Saves You Some Time Energy Money.

I took copious notes, as I continue to connect the dots to the power of the Drupal project - to how it is leading a digital transformation across industries. I absorbed it all, and was eager to learn more. I met other developers and individuals who contribute so much to the Drupal project and to the Drupal community. From my conversations with Ray Saltini (rgs) and Mike Anello (ultimike) to Suzanne Dergacheva (pixelite), I was struck by the level of commitment demonstrated by the community. You'll get a sense for this in Suzanne's slides for her Growing the Drupal Community talk.

Heather Rocker (hrocker) also attended and presented at the Career Fair. She spoke about the importance of the Association’s initiative on Diversity, Equity & Inclusion and the benefits that come from actively recruiting and welcoming new individuals (especially those from underrepresented communities) to lend their skills to the project.

I realize the extensive number of stories that are within this vast and passionate community, and I am excited to promote and talk about them. I am looking forward to being a communications and marketing advocate for the Drupal community, the Drupal project and the Drupal Association. From the specific needs of developers, to the importance of broadening our audience, to the necessity of career fairs to bring students on the Drupal train, and to the need for marketing to grow Drupal adoption, I heard and learned so much in a short visit to Atlanta. But, what impressed me as much as the day was the contagious enthusiasm for what the community is doing and for what it can accomplish!


The DrupalCamp Atlanta Leadership Team, without whom the event wouldn't have been possible!

Thanks to everyone who came out for #DCATL this year! We loved meeting y'all. Let's continue to grow and support the @drupal community! pic.twitter.com/q9IgHjVRkA

— DrupalCamp Atlanta (@DrupalCamp_ATL) September 14, 2019

Categories:

InternetDevels: Why update to Drupal 8.7.7 now: a small release with a big secret!

Wed, 2019/09/18 - 5:20pm

The Drupal world is looking forward to the “ninth edition” of the great drop. It’s going to continue Drupal’s chosen path with its API-first orientation, the latest versions of third-party libraries, advanced editor-friendliness, and much more.

The Drupal 9 release is scheduled to come on June 3, 2020. One more big step has just brought it closer — the Drupal 8.7.7 version.

Read more
Categories:

Drudesk: Easy content creation with Gatsby Live Preview Drupal module

Wed, 2019/09/18 - 4:31pm

It’s great to live in the times when a robust CMS can share its content with an ultrafast JavaScript front-end. One of the best examples of this is combining Drupal and GatsbyJS. We are happy to see a new tool for it that is fresh from the oven — Gatsby Live Preview module for Drupal 8. 

It provides Drupal editors with easy content creation workflows, making Drupal and Gatsby integration a more lucrative idea for developers and website owners.

Categories:

TEN7 Blog's Drupal Posts: Kubernetes: Our Next-Gen Site Hosting

Wed, 2019/09/18 - 3:35pm
Ivan and DevOps Engineer Tess Flynn discuss why we've gone all-in on Kubernetes for site hosting at TEN7, from the genesis of the idea to the nitty gritty of how all the pieces work together to create our next-generation hosting services.
Categories:

TEN7 Blog's Drupal Posts: Kubernetes: Next-Gen Site Hosting

Wed, 2019/09/18 - 3:35pm
Ivan and DevOps Tess Flynn discuss why we've gone all-in on Kubernetes for site hosting at TEN7, from the genesis of the idea to the nitty gritty of how all the pieces work together to create the next generation of hosting services.
Categories:

Agiledrop.com Blog: Let's talk about localization

Wed, 2019/09/18 - 8:34am

In this post, we'll take a look at localization and explain why translation by itself is not enough. We'll also briefly discuss one website trend that is the same in all cultures and as such doesn't need to be localized.

READ MORE
Categories:

Promet Source: Trends and Tips for Tapping Tech Talent

Wed, 2019/09/18 - 6:24am
These are interesting times for securing tech talent. With the current unemployment rate at 3.7 percent, the job market is highly competitive, and that’s particularly true for the technology sector.  Reaching out to agencies that can offer the right talent when and where it is needed is proving to be the solution among savvy organizations.  Key among the advantages that the right agency relationship offers: the opportunity to leverage specific expertise on an ongoing, ad-hoc, or one-off basis.
Categories:

DrupalCon News: Join us in Amsterdam to learn & network in person

Tue, 2019/09/17 - 6:53pm

DrupalCon Amsterdam is approaching — next month! Are you still deciding about going? With the robust program, each day will be full of exciting sessions, social activities and contribution sprints galore! Check out the breadth and scope of our offerings, with insight you won’t want to miss.

The event kicks off with Trainings on the morning of Monday, October 28. Choose from these seven options to further your learning:

Categories:

Bounteous.com: Audit Your Drupal Theme

Tue, 2019/09/17 - 6:28pm
Explore tools and methodologies that provide insights to keep your Drupal theme manageable over time as well as concepts to establish metrics within your theme.
Categories:

Srijan Technologies: Headless Drupal - What It Means For Marketers

Tue, 2019/09/17 - 5:30pm

If your website is on the right CMS, it becomes easy to create marketing campaigns, drive leads, and tell your brand’s story to the world. However, making content available on every new device in the market accessible to a user becomes a challenge for marketers.

Categories:

Redfin Solutions: Leveraging Custom and Third Party Libraries in React Native: Part 3

Tue, 2019/09/17 - 4:11pm
Leveraging Custom and Third Party Libraries in React Native: Part 3

This is the last in a series of blog posts about creating an app with React Native. To get started with React Native, read the Basics of React Native: Part 1. If you want to include content from a Drupal website in the app, read Integrating Content with React Native: Part 2.

Jacob September 17, 2019
Categories:

Specbee: Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!)

Tue, 2019/09/17 - 3:07pm
Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!) Shefali Shetty 17 Sep, 2019 Top 10 best practices for designing a perfect UX for your mobile app

“Should I upgrade or should I just wait?” This question has been constantly bothering business decision-makers when it comes to migrating their website from Drupal 7 to Drupal 8. Change can be hard and terrifying, especially at its inception. Yet, a change is what allows you to grow, evolve and progress. It can get painful to take a decision as big as a migration of your Drupal 7 (or 6) website – the one that you knew and have loved. But soon you will know you have made the most brilliant business decision, ever! 

Drupal 8 Migration - A Long-term vision

There has always been a perception that Drupal is a difficult CMS to get a hang of. Starting from end-users to developers, Drupal was considered as having a huge learning curve.  Yes, with the previous major versions (before Drupal 8), the process of upgrading and adjusting to the change was harder. It was also more expensive (needed more resource time), the release of contributed modules (and necessary features) were slower and the release cycles got longer.

But with Drupal 8, everything changed. 

Tom Wentworth, (SVP Product Marketing from Acquia), summed up accurately in his article that unlike a few other CMS’s, “Drupal 8 was a teardown all the way to the foundation”. Creating an upgrade based on the same old foundation would have been a much easier task for the Drupal community. But starting from Drupal 8, the Drupal community has focused on long-term sustainability and on getting people to adopt Drupal effortlessly. This called for a complete re-architecture of Drupal 8 with the adoption of Symphony for high performance, Twig for a more modern templating engine, object oriented programming for easier maintenance, modern user experience design creators and editors for rich content editing, and much more. 

Drupal 8’s continuous innovation approach propels an evolution with regular (and shorter) minor releases, semantic versioning (in a ‘major.minor.patch’ format) that helps in backwards-compatibility enhancements and faster stability in modules by releasing experimental modules in core.

Your Drupal 8 Questions, Answered. (To some extent)

Although it has been a while since Drupal 8 has been around and stable, we still get asked a ton of questions by our customers before a migration. 

1. Why should I upgrade to Drupal 8 (from Drupal 7) when Drupal 9 is just around the corner? (We get this nearly every time)

I have a whole blog dedicated to this question, but if you insist, here are your benefits of upgrading to Drupal 8 now -

  • Time crunch – So Drupal 9 does not release until June 2020 and Drupal 7 reaches its end-of-life by December 2021. Which means you have only a year and a half to upgrade to Drupal 9. If your website is considerably simple and needs less customizations, this is a viable option. Else, you’d better off start an upgrade to Drupal 8 now and migrating from Drupal 9 from Drupal 8 is as easy as upgrading to a next minor release.
  • Living with a FOMO – That’s a term I recently learnt about – Fear Of Missing Out. Why do you want to miss out on some powerful and modern enhancements when you can migrate to Drupal 8 now and boost your Drupal website’s performance and experience? Upgrading from Drupal 8 to Drupal 9 is a cakewalk anyway!
  • Just a better version – Drupal 9 is just Drupal 8 minus the deprecated code and modules. Migrate to Drupal 8 now, enjoy a better performing website and an easy upgrade to Drupal 9 (and any future versions of Drupal)
2. We’re still stuck on Drupal 6. Help!

If you’re still stuck on to Drupal 6, you must know that everyone else has moved on. Today, the web has changed and so has Drupal. The Drupal community no longer supports Drupal 6 since February 2016. Which means, there will be no new Drupal modules or features to look forward to, no more bug-fixes, security updates and patches. Thus putting your website’s security at high-risk and of course depriving it of some TLC from the community. If you still want the best for your website, migrate to Drupal 8 now! Yes, you can completely skip Drupal 7. Drupal Migrate module is now included in Drupal 8 core and makes the switch easy and fast.

3. What performance upgrades does Drupal 8 offer?

Drupal 8 comes packed with performance-enhancing features and modules that can turn your website into a speedy and high performing one. Here are a few to name -

  • The Symfony Framework – Drupal 8’s adoption of Symfony framework isn’t just a great move for developers but for website owners as well. Symfony offers a robust, flexible and high-performance framework that allows for easy scalability of a website.
  • BigPipe Caching - It lets you segregate your page into different sections (called Pagelets) which can be rendered as they get available (Cached first). This lets you drastically improve your page’s perceived performance and speed.

  • Caching for Authenticated Users – Drupal 8 uses Varnish to cache page content and serve them to authenticated users for better and faster performance.
  • PHP7 support – Did you know PHP 7 is now two times faster than PHP 5.6 because of its new Zend engine? With PHP 7 support in Drupal 8, your websites can see a performance rise up to about 110% and reduced memory usage.
4. What challenges will we encounter during a Drupal 8 migration? What can be done to alleviate those issues?

Challenges encountered during a website migration from say Drupal 7 to Drupal 8, completely depends upon the complexity of a website, if it includes a redesign, the amount of content needed to be migrated and many more other factors. The first and the most crucial step towards a Drupal 8 migration is to audit your existing website. Auditing and analysing your website could be the biggest challenge if not handled well and could lead to a successful (and quick) migration when done right. If not planned well, you might run into problems where you are unprepared to handle -

  • Module compatibility issues
  • Might migrate old and unused modules that will increase migration time
  • Unavailability of existing modules/features/themes/views/entities (in core or contrib) 
  • The need to rebuild and rewrite custom modules in Drupal 8. (Coz as discussed earlier, D8 has restructured itself to be able to be more future-ready)
  • A rebuild/repackage of features and views
  • A redevelopment of the theme – because of Drupal 8’s new and powerful templating engine Twig

How do we fix this? – Easy. Audit your website well. Get a Drupal technology partner to do a complete analysis and audit of your existing website and list out features, modules and other elements that need to be migrated. They will need to provide you with details on what needs a rebuild and what can just be easily ported. You can also use evaluation modules like the Upgrade checker which will give you a comprehensive list of migration components and an estimate of how long it might take.

5. Can we migrate to Drupal 8 and yet preserve our existing data whilst remaining GDPR compliant?

Absolutely! The reason why Drupal is so successful is because of its proactive and battle-ready Drupal community. The Drupal GDPR Compliance team project aims at providing websites with modules and features that can assist in making them GGDPR compliant. There are over 15 new modules in Drupal 8 for GDPR compliance to choose from with some modules that can be ported to Drupal 8 and some that may need a rewrite. Check here for a list of Drupal modules that help you build GDPR compliant websites.

6. What happens to my content? 

Drupal understands how important content is to every organisation. With efforts from more than 500 contributors, the release of Drupal 8.5.0 brought together a stable and robust Drupal Migrate architecture. Modules like Migrate API, Drupal Migrate module and Migrate Drupal UI allows for a flexible and easy content migration from the database or sources like JSON, CSV or XML.

7. If we migrate to Drupal 8, will it break any of our existing features/modules?

The answer to this question depends on your website structure, complexity and the way Drupal 7 (or Drupal 6) was implemented on your website. Many times, there is no direct path for a Drupal 8 upgrade. Custom modules will need a rebuild and will break if simply ported because Drupal 8 is now built on Symfony framework (and OOPS principles). Themes will need to be redeveloped as with the new template engine Twig, migrating your existing Drupal theme will not work.

8. Will our integrations with third-party software break when we migrate to Drupal 8?

Integrations with third-party software have just gotten better with Drupal 8. With web services in core in Drupal 8, creating RESTful APIs are easy and fast. This is invaluable in connecting with many third-party applications. Additionally, Drupal 8 has added many more integration modules to its list.

9. Will our core Drupal 7 modules still work?

Yes. Drupal 7 Core modules have made their way to Drupal 8 and some of them are even better in Drupal 8! While most of them are automatically upgraded, a few modules will need manual work if they don’t have an automatic upgrade path. Some Drupal 7 (or 6) modules are not mapped to the same Drupal 8 module. For example, the Block module in Drupal 7 is now divided into a Block and Custom Block module in Drupal 8. Nonetheless, many contributed modules in Drupal 7 are now in Drupal 8 core (like the Views module). 

10. What happens to our custom and contributed modules?

After Drupal 8’s adoption of the Symfony framework and Object Oriented Programming principles, Drupal has opened its doors to wider set of developers and programmers. This also helps in building code that is more robust and reusable. But this time-saving, future-ready concept brings along some bad news too. The bad news is that most of the existing custom modules and some contributed modules will need to be rebuilt from scratch to be able to support Drupal 8’s futuristic mission. But the great part about this is from Drupal 8 onwards, any major/minor upgrade will be easy as pie.

11. Will our Drupal theme break on migrating to Drupal 8?

Unfortunately, yes it will. Since Drupal 4.7 up until Drupal 7, PHPTemplate has been the default Drupal Theme engine. But with the adoption of the Twig (part of Symfony2) for a more powerful, secure and modern templating engine, themes will need to be redeveloped. However, parts of code can be replaced as is.

12. How can Drupal 8’s API-first approach benefit us?

By the year 2020, there are going to be more than 50 billion internet connected devices. Content is now consumed via a plethora of mediums – computers, mobiles, IoTs, wearables, conversational interfaces, smart TVs… and the list keeps growing. Which means, your brand needs to interact with a lot more devices and in many more formats than just a website. Content delivery has gotten a lot more challenging.

Just so we are on the same page, an API (Application Programing Interface) is a set of rules or routines (functions or programs) that specifies how applications can interact with each other. For example, if you want to display the current weather on your website, you can invoke an API with websites that offer this service.
To be able to handle the content delivery challenge efficiently, content needs to be treated like well-structured data. Drupal’s API-first approach, lets you create an API before you build your website or mobile app. This futuristic approach allows you to turn content into services which can then interact with diverse devices irrespective of the formats. While Drupal 7, also supports the API-first approach with the help of additional modules, Drupal 8 comes built-in with the content-as-a-service model.
This is what our in-house expert Drupal Practice Head, Malabya Tewari has to say about Drupal 8’s API first approach – “Drupal 8 has taken this approach to another level and here’s why- REST module is now in core, where you can create own custom web-services using Views (which is also added in core in D8). It is easier to create custom REST APIs using the core REST module. Adding basic authentication is in core as well. You can get APIs, including JSON API and GraphQL, for all entities - out of the box! 

13.What are the benefits of upgrading to Drupal 8?

One of the most stunning features of Drupal 8 is that you have (almost) everything you need, out-of-the-box. 

  • Responsive websites are not a luxury anymore, they are a necessity. All of Drupal 8’s themes are responsive off-the-rack – which not only works great with all devices also makes configuration and set up of your Drupal website a lot easier.
  • A built-in, well configured WYSIWYG editor CKEditor lets you preview and edit your content in a breeze. You also have an in-place editor that lets you edit blocks, content, menus, etc. right in the same page.
  • SEO gets you noticed and out-there. With some of Drupal’s built-in powerful SEO modules, you can take your website places! Modules like SEO Checklist, PathAuto, Redirect, MetaTag, etc. are killing it!
  • The newest and most powerful version of HTML, which is HTML5 is now built-into Drupal 8. It lets you embed complex input elements like audio, video, date, email, etc with ease and better functionality across all devices.
  • Take your business global with Drupal 8’s out-of-the-box multilingual support. You can not only create pages enabled with language-based views, even the admin interface allows you to select our preferred language. The built-in content translate modules enables you to translate any content entity into different languages.

 

It has been a while, more than three years now, since Drupal 8 has made its entry into the field. The best of the Drupal community worked hard for nearly 5 years to produce this masterpiece of a CMS and finally announced its arrival in November 2015. Since then, more than 150,000 Drupal websites have migrated to Drupal 8, only to find a higher performing, robust and a more flexible solution. Yes, the change is not very easy but once you migrate to Drupal 8, life surely gets easier. Reach out to an expert Drupal development company to help you take the best possible approach towards a successful Drupal 8 migration. 

Drupal Planet Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe Shefali ShettyApr 05, 2017 Recent Posts Image Top 13 questions you may STILL have about migrating to Drupal 8 (Answers included!) Image How to Manage your Media using the Drupal 8 Media module Image PHP Debugging - How to Debug your PHP Code (Drupal debugging techniques included!) Explore Our Drupal Services TAKE ME THERE Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

link

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

link

Develop an internal portal aimed at encouraging sellers at Flipkart to obtain latest insights with respect to a particular domain.

link
Categories:

Code Karate: Drupal 8 Publish Content Module

Tue, 2019/09/17 - 2:06pm
Episode Number: 233

The Drupal 8 Publish Content module is a simple module that provides you additional permissions to allow users to publish or unpublish content without having to give the user the ability to administer all the content on your site. This module is a lightweight solution to help you build out your content management workflow on your Drupal 8 site.

The module also adds some additional features such as:

Tags: DrupalDrupal 8Drupal Planet
Categories:

Aram Boyajyan: Rehash MD5 password in Drupal 8

Tue, 2019/09/17 - 12:59pm
Rehash MD5 password in Drupal 8

Below is a simple code snippet that allows you to convert a password hashed using MD5 into the format that can be used by Drupal 8. This can be useful if you are creating users programmatically and need to re-create their password from an MD5 source.

aram Tue, 17/09/2019 - 12:59
Categories: