The publication of this draft is important for every entity that will have duties under the CRA, namely “manufacturers” and “software stewards.” Conformance with the harmonized standards that emerge from this process will allow manufacturers to CE-mark their software on the presumption it complies with the requirements of the CRA, without taking further steps.

For those who depend on incorporating or creating Open Source software, there is an encouraging new development found here. For the first time in a European standards request, there is an express requirement to respect the needs of Open Source developers and users. Recital 10 tells each standards organization the following:

“where relevant, particular account should be given to the needs of the free and open source software community”

That is made concrete in Article 2 which specifies:

“The work programme shall also include the actions to be undertaken to ensure effective participation of relevant stakeholders, such as small and medium enterprises and civil society organizations, including specifically the open source community where relevant”

Article 3 requires proof that effective participation has been facilitated. The community is going to have to step up to help the ESOs satisfy these requirements—or corporations claiming to speak for the community will do it instead.

OSI applauds the Commission’s steps to include the Open Source community and will be pleased to work with the European standards organizations towards that initial goal of effective representation and consultation. Additionally, the OSI will:

• Work with our Affiliates to identify additional suitable participants with relevant skills and experience, and make connections between them and the ESOs.
• Assist the Commission in validating responses to Article 3.

Our goal is to ensure that the development and use of Open Source software is at best facilitated and at worst not obstructed by any aspect of the standards development process, the resulting harmonized standards, and the access and IPR terms of those standards.

“Free and open-source software is understood as software the source code of which is openly shared and the license of which provides for all rights to make it freely accessible, usable, modifiable and redistributable.”

The addition of “openly shared” was a considered and intentional addition by the co-legislators – they even checked with community members that it did not cause unintended effects before adding it. While Open Source communities all “openly share” the source code of their projects, the same is not true of some companies, especially those with “open core” business models.

For historical reasons, it is not a requirement either of the OSD or of the FSF’s Free Software Definition (FSD) and the most popular open source licenses do not require it. Notably, the GPL does not insist that source code be made public – only that those receiving the binaries must be able to request the corresponding source code and enjoy it however they wish (including making it public).

For most Open Source projects and their uses, the CRA’s extra requirement will make no difference. But it complicates matters for companies that either restrict source availability to paying customers (such as Red Hat) or make little distinction between available and non-available source (such as ForgeRock) or withhold source to certain premium elements.

A similar construct^{1} is used in the AI Act (recital 102) and I anticipate this trend will continue through other future legislation. Personally I welcome this additional impetus to openness.

{1} The mention in the AI Act has a different character to that in the CRA. In the AI Act it is more narrative, restricted to a recital and is a subset of attributes of the license. In this form it actually refers to virtually no OSI-approved licenses. In the CRA the wording part of the formal definition in an Article, so much more impactful, and adds an additional requirement over the basic requirements of licensing.

In the light of the EU’s own research showing the huge impact of Open Source on Europe’s economy, the authors of these legislative instruments sought to ensure that the lifecycle of Open Source software was impacted as little as possible. Indeed, at FOSDEM 2023 the authors of the CRA and PLD said as much in their first-of-a-kind main track appearance. But when we all looked at the details, community members found that was not as true as we hoped. As a range of organizations explained, the CRA was likely to be an existential threat to Open Source development, because instead of placing all the compliance requirements of the CRA on companies deploying Open Source software for profit, the obligations as written potentially fell on developers and Open Source foundations.

Reactions To The Final Text

Many OSI Affiliates engaged with the European Commission, European Parliament and European Council during 2023. With the welcome coordination of Open Forum Europe, a group met regularly to keep track of progress explaining the issues. Many of us also committed time and travel to meet in-person. As a result of all this effort from so many people, the final text of the CRA mitigated pretty much all the risks we had identified to individual developers and to Open Source foundations. As the Python Software Foundation said in their update:

…the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

And the Eclipse Foundation wrote:

The revised legislation has vastly improved its exclusion of open source projects, communities, foundations, and their development and package distribution platforms. It also creates a new form of economic actor, the “open source steward,” which acknowledges the role played by foundations and platforms in the open source ecosystem.

As the Apache Software Foundation said:

So, all in all, this is mostly good news for volunteers who run and innovate with open source software. Or, more accurately, much better than most of us could have imagined at the end of last summer.

This time last year OSI recommended that the CRA:

…exclude all activities prior to commercial deployment of the software and … clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

That recommendation has been accepted and implemented, and the OSI is very grateful to the various experts who took the time to listen.

OSI Observations

While it’s all much better, and while the burden placed on individuals and charities is minimal, there are still challenges ahead. For example, the concerns that the Debian project articulated give cause for thought. With Open Source projects exempted from the requirement to place a CE certification mark on their software, downstream users will need to pay careful attention to their responsibilities under the CRA as well as to their liabilities to consumers under the PLD.

In particular, “digital artisans” using Open Source software at small scale – the main concern of Debian – will need guidance from the European Commission. While the experts we have met have all said that using an Open Source software distribution as part of a commercial activity is unlikely to require CE marking of the distribution itself, the interpretation of the key phrase “making available on the market” will need careful clarification. OSI encourages the Commission to seek expert advice from the Open Source communities as they did last year, and not to rely on outsourced consultants alone in preparing this advice.

FOSDEM 2024

There is also the question of how future engagement by legislators should proceed. The effort made by developers and Open Source foundations in 2023 is not sustainable, and the Commission needs to accommodate the Fourth Sector in future deliberations. To get this started, a group of us who have engaged during 2023 got together to organize a unique set of workshops at FOSDEM 2024 on Sunday February 4. If you want your voice heard, come along to one of the workshops!

SEPs in context

Royalty-due SEPs are an artifact of a requirements-led standardization process. Not all standards are affected by SEPs, and not all SEPs require licensing on royalty-due terms. While some standards are encumbered by patents registered by contributors to the standards process, patents are not an essential or inherent aspect of standardization.

Patents are mechanisms that exist for a societal reason — in order to create a benefit to society by encouraging inventors to openly share their techniques — not because there is any inherent “property” to recognize. So it is incumbent on government administrations to regulate their use so that a societal benefit is preserved.

As I explained for Open Forum Europe, some standards are developed in a sequence of activities that starts from a statement of requirements aiming to create a new market (“requirements-led”) while others are developed as a harmonization of existing industry implementations in an existing market (“implementation-led”).

• The implementation-led approach (harmonizing existing markets) frequently arises in circumstances where recovery of R&D costs is already in hand and patent monetization is not a proportionate compromise. As a result, projects developed under an implementation-led approach (such as at OASIS and W3C) frequently opt for restriction-free (RF) terms that result in a negotiation-free usage since royalties are waived and do not need to be negotiated.
• The requirements-led approach (specifying the interoperability for a future market) leads some standards development organizations (SDOs) to tolerate restricted licensing of included patented technologies due to the long lead-times in research and development investment by standards contributors. While royalty-due and negotiation-required licensing of SEPs is desirable for the commercial entities benefiting from the tradition, the bilateral negotiation with NDA-enforced privacy that results gives the incumbents market power that could be easily interpreted as anti-competitive.

Despite the practice of accommodating royalty-due patents in standards leading to barriers to entry in the resulting markets, tolerating SEP monetization appears a compromise that its advocates assert can be a proportionate remedy to the delayed monetization opportunity for participants. As a result SDOs put in place safeguards during the standardization process to avoid triggering anti-trust regulations, such as ensuring equal terms of participation for all in the process, requiring disclosure by participants of patents that could prove standard-essential, and especially in requiring negotiated terms to be “Fair, Reasonable And Nondiscriminatory” (FRAND) — although not backing this up practically.

Bugs in the process

But these SDO safeguards only prevent the SDO itself from being regarded as anti-competitive, and do nothing to protect the markets that go on to be created by requirements-led standards.

1. What needs licensing is unclear. While the patents of those involved in the standardization process will have been declared, the resulting standard may not embody their claims, and others outside the SDO may make claims. Published standards are thus not accompanied by a list of patents that need to be licensed for implementation. The task of identifying exactly which patents need to be licensed for exactly which parts of the standard is therefore significant. That burden is only placed on smaller innovators and market entrants; the incumbents are likely to have cross-licensing agreements in place, making their market participation simpler and cheaper. 1 2
2. Power is with the incumbents. While the term “FRAND” (Fair, Reasonable And Nondiscriminatory patent licensing terms) is much used, the reality is that the negotiations for patent licenses are 1:1 and conducted in commercial secrecy under NDA. There is no way any party can know if the terms they are offered are like those offered to others, and the power is imbalanced heavily in favor of the patent owner who will use early legal proceedings to force a conclusion. Since the patent owners are frequently the dominant market players, small companies and new market entrants are at a significant disadvantage.
3. The cost of licensing is unknown. Since each patent is likely to need separate negotiation with large corporations, it’s hard to know what the cost of licensing a given standard will be, even after the list has been painstakingly built.
4. Patent pools can demand unwarranted licensing. Patent pools are held up as a partial remedy for this. They sometimes list all the patents they are licensing but don’t explain why they are essential. As a result, the lists they produce can be inaccurate, especially when the pool is not connected with the standardization process. 1 2 3 A

Better markets with SEP-R

The proposed Standard Essential Patent Regulation addresses many of these issues as part of its proposals, and that’s the reason OSI broadly welcomed the proposal. Where royalty-due patents in standards are present, they should at least function to create a fair market for both patent owners and licensees.

OSI’s concern relates to a potential loop-hole in the new arrangements. Knowing that some patent owners prefer not to participate in standardization activity, and that some owners prefer to be as non-specific about essentiality as possible, OSI was concerned that the otherwise excellent public registration system might be ignored by some patent owners in order to bias the market towards adoption without possessing the full costs, deeming them free to disregard the regulation’s collective pricing measures. OSI considers this a gap in the regulation.

The late registration gap

Because of the improvements in SEP-R, implementers will be able to know which entities will require negotiation and assess whether to use the standard based on the registrations made by patent owners as well as on the collectively-agreed total royalty. But there is a risk the improvements will be avoided intentionally by some patent owners.

• Late-registered patents are likely to be those not arising from the standards process. They are unlikely to be owned by participants in the collectively-agreed total royalty.
• Since implementors could not take these patents and their burden into account, their late registration is likely to require at best revised costings, probably new engineering, and at worst market withdrawal by some implementers.
• This represents market harm and needs to be discouraged and those in the market protected.
• But SEP-R does not do so, leaving predatory late disclosure as a viable control point for incumbents and NPEs (trolls) whose advantage has been impacted by SEP-R.
• The only major consequence of late-stage registration is the loss of royalties before the registration is valid; however, for a widely adopted standard this is likely to be of small consequence to the SEP owner over the long term. The market will already have formed and such a delay will significantly impact companies with products already in the market. Products with Open Source elements will be more significantly affected as they will likely need to remove affected capabilities.

Possible remedies

Recognizing that the existence of patents is for the enablement of a social good from an effective market, and recognizing that late registration of patents as essential to a standard after it has been promulgated harms those trusting the registry, it seems reasonable to apply a remedy both to ameliorate and discourage late registration. The best remedy to late registration would be to simply prevent any patents registered as essential to a standard from being able to claim any royalties in association with the implementation of the standard.

Realistically, this option would face huge opposition from SEP-dependent corporations and would be better considered a long term goal. 

Instead, OSI proposed that registering a patent as essential after the market has adopted a standard affected by it should result in a waiting period before royalties could be claimed. This would allow time for the adjustment of the allocation of the total estimated cost of licensing to accommodate the new patent, as well as allow the market to adjust to the new reality.

Given the pace at which these changes will be made, it seems reasonable to have a waiting period of at least two years from registration before patent royalties can become due.

Notes, Tags & Mentions

• OSI’s interest in this topic arises from the well-documented reluctance of Open Source developers to entertain patent-encumbered standards. Their presence can sometimes be accommodated but reduces the stochastic confidence level that leads to Open Source being an effective trigger for innovation.
• To read a similar discussion but from an Open Source perspective, see the OSI blog and my earlier article exploring the topic.
• OSI made an earlier submission to the consultation and also published a corresponding article.

Here’s a short list to help the co-legislators understand the engagement from the Open Source community.

• OSI and the experts with whom they engage are not trying to get all of Open Source out of scope as maximalist lobbyists do for other aspects of technology. An exclusion from the regulation for Open Source software per se would open a significant loophole for openwashing. But the development of Open Source software in the open needs to be excluded from scope just as the development of software in private is. Our goal in engaging is just to prevent unintentional breakage while largely embracing the new regulation.
• There is no one way to use Open Source. Many of the policymakers we’ve spoken to think of Open Source components in supply chains under the care of foundations like the Eclipse Foundation that are used essentially as-is. But the freedoms of Open Source are also used for stack building, consumer tools, enabling research, hobbyist tinkering, as the basis for European small businesses like XWiki, Open-Xchange, Abilian, and more. All these many other uses exist and are broken differently by the CRA. Software is primarily a cultural artifact and that aspect must be prioritized.
• There is no single Open Source business model. People make money from Open Source (by charging for it, running it as a service and supporting it) and with Open Source (by simplifying their businesses and reducing costs); they shape markets via Open Source by enabling adjacent businesses, commoditising competitors without then monetising their customers, and more – there are a significant number of business models made possible by software freedom. So any attempt to identify commerciality is sure to be model-specific and consequently have unintended consequences for other models.
• Even larger foundations like Linux Foundation do not actually employ the sort of staff who ensure code compliance – Open Source is conceptually disjoint from proprietary software. To comply with the CRA – if they find themselves in-scope – they will need them to hire a whole new operating unit. To them, the burden of compliance is not a cost of development funded by revenue as it would be for a manufactured physical good where staffing exists and just needs adapting.

As we did in January, OSI still recommends the Cyber Resilience Act should exclude all activities prior to commercial deployment of software and clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

It’s good news that the European Commission is now considering the value and needs of Open Source in its policy deliberations. What’s not as good is that it does so through the wrong lens. The Commission needs to extend its consultations, Expert Groups and other work to include and consider the fourth sector.

Post-industrial society comprises three sectors in the worldview undergirding the European Union:

• The commercial sector includes industrial, extractive, service, logistic and administrative companies. They are represented by industry and trade associations, by consulting and lobbying companies and more.
• The labor sector includes workers of all kinds – industrial, skilled, research, educational, managerial, entrepreneurial and more. They are represented by trade unions, professional bodies, guilds and more.
• The consumer sector comprises everyone spending their personal wealth at all scales. They are represented by consumer associations, civil society organizations, religious organizations and more.

Internet changed everything

But the internet has driven change over the last 50 years from which has arisen the World Wide Web and hence the Open Source movement, which in turn have catalyzed many open culture movements related to technologies. The wave of open has produced many phenomena – good, bad and pending judgment – including the gig economy, open knowledge communities like Wikipedia and the Internet Archive, technology giants like Facebook and Google, open software stacks and supply chains and much, much more. The roles people play in this open wave do not fit comfortably into the three post-industrial sectors. 

For example, an individual would be expected predominantly to fall within the consumer sector, with a section of their life represented in the labor sector. But an Open Source developer can be innovating and creating soft goods (commercial sector) which are assembled (commercial sector) or used (consumer sector) by others. A video streamer may be creating new copyrighted works of great value (commercial sector) that are widely viewed (consumer sector). An author or musician can now create their own compelling brand without becoming an employee of a publisher. 

The fourth sector lacks representation

This introduces a new fourth sector. It comprises individuals, often connected and facilitated by ad-hoc or charitable communities, playing the roles of the commercial, labor and consumer sectors in varying mixes all at the same time. The fourth sector is poorly represented by the entities and roles associated with all three of the other sectors. That’s inevitable; each fourth sector role will fuse together an aspect represented and an aspect confronted by any of the entities and roles dedicated to the three traditional sectors. 

This means that a consumer association won’t advocate well for Open Source developers because an aspect of their existence is classified as commercial. A streamer won’t be well represented by a trade union because they embody both consumer and commercial aspects. And so on. As a result, existing consultation mechanisms used by legislators are guaranteed to fail. When they try to deal with Open Source by expressing the understanding they have gained of proprietary software, they will keep causing collateral damage — as we have seen in the Cyber Resilience Act (CRA) and many times previously. The need will increase as regulation tries to control, account for or promote the activities of the fourth sector without consulting it. 

One significant reason this has been happening for such a long time already is the lack of a term to use to raise the issue. That’s why I am proposing to call this sector of European society the “fourth sector.” It extends well beyond Open Source, covering any new, citizen-centric economic activity which is hard to have represented with only the existing commercial, labor and consumer lenses. Let’s tell the Commission and other governments that it’s time to care about the fourth sector, which is the driving force for all the changes they want to embrace — or control.

This article first appeared on Webmink in draft.

Proprietary software and the company that places it on the market can usefully be seen as the same target for those creating legislation. The software is constructed in secret, under the control of a single party, and the controlling party is responsible for both funding the work and monetizing the result. However, the same cannot be said for Open Source software, which is created openly by a globally-distributed and unaffiliated community whose relationship with the larger work is “volunteer”. Using terminology associated with the worldview of proprietary software in legislation that affects Open Source is at best ambiguous and at worst extends consumer regulation to the domain of research and development.

Open Source software is an artifact arising from the interactions of a community of contributors with no contractual binding between them beyond the Open Source license itself, which disclaims all warranties and has no conduit for funds. If there is an Open Source charity or trade association hosting the community, there will also be only a limited binding to it and probably none that is a funding conduit. Many communities are unincorporated and don’t even have this level of interconnection.

Because of this, those who place the artifact with digital elements on the market must be assumed to have no financial, organizational or indeed morally relevant relationship with any other party involved in the artifact’s origination or use until proven otherwise. There may be links, but it’s best to start from the assumption there will be none because making them is an outside activity with no accommodation in Open Source licensing.

In many cases (sadly) those placing the artifact on the market have no connection at all with the community, not even at the level where it is appropriate to consider members of the community as suppliers. As one community member wrote:

I am not your supplier. So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.

The software and the community thus need to be considered separately when choosing language that applies regulation affecting Open Source. Some highlights to note:

• The software is made freely available under an OSI-approved license that ensures its consumer may do anything it wishes without needing any relationship with rights holders.

• The members of the community collaborate for many different reasons, and even when those reasons have commercial intent the commercial intents in play are likely to be unrelated both formally and informally.

• Many community members have a moral/ethical basis for their participation which can sometimes take priority over pragmatic convenience.

• Treating the software and the company placing it on the market as interchangeable is unsafe.

• As a consequence, it is unsafe to assume that because two parties are monetizing a piece of Open Source software, that there is a flow of funds or even a relationship between them. Regulation should only apply to the party triggering the clause in the legislation, unlike with proprietary software where it is reasonable to assume a link.

This article first appeared on Webmink in Draft.

Image of Fallen Head by Simon Phipps

But reciprocal patent licensing is very common in the software industry generally and Open Source in particular – it’s part of the terms of the Apache License for example – so the accusation seemed far more likely to be projection by the SEP-dependent legacy industries of Europe. One useful insight into the whispers to which DG COMP responded can be seen in the extra information AOM has added to its legal page in response to the matter. The questions they address have such obvious and innocuous answers that only express sophistry could have been behind such questions, given the sophistication of the actors involved.

This is all crucially important to Open Source software, and not just as an endorsement of reciprocal terms. While there are edge cases, generally Open Source projects avoid standards which embed royalty-due patents, not primarily because of the royalties but because of the need to submit to the control implied by privately negotiating terms with the patent holders – an obviously anti-competitive aspect for any market entrant, about which Europeans complain.

It only takes one patent aggressor to rob everyone of viable Open Source video, so it seems entirely reasonable to scrupulously maintain hygiene by requiring any beneficiary of AV1 to commit to waiving royalties (and thus their negotiation). AOM is creating standards expressly intended to allow implementation by Open Source projects, so their terms are both rational and reasonable … unless you want to keep Open Source out of your cozy market.

The clouds have not all dispersed. AOM’s licensing is unfortunately based on a non-OSI-approved license (for excellent reasons but still an issue). Hopefully this will become more and more unfashionable as Open Source expands its reach. Also, significantly, there are hostile patent pools which, unfathomably and without evidence that their mountain of claims are actually essential, assert that the AV1 standards infringe patents in the pools.

But this is good progress and underlines that the “reciprocal” mechanisms so common in Open Source licenses are generally pro-competitive.  Perhaps the Commission will now move on to ask why such an obviously anti-competitive arrangement as standards bodies permitting royalty-due patents in their specifications is still tolerated?

This article first appeared on Webmink in Draft.

Image it’s not thieving if it’s from the bin, right? by Simon Phipps.

There’s a crucial issue here for Open Source. EU policy experts say not to worry about CRA compliance because the EU standards bodies will streamline it. But the European Standardisation Organizations (ESO) are corporate-controlled, patent-loving and expensive to engage. Shouldn’t the EU address this if they want Open Source accommodated?

In Europe, standards requests from the European Commission are handled by bodies which have been designated an ESO under EU law. There are only three of these; CEN, CENELEC and ETSI. None of these standards development organizations are accessible to Open Source projects per se.

CEN and CENELEC are largely controlled by national standards bodies which in turn are dominated by national industries, while ETSI is a  member organization with high membership fees and largely secret proceedings (although laudable with free specifications) that is directly controlled by its members, predominantly from the telecoms industries but also including the European states. In addition, ETSI celebrates its role as a pioneer and proponent of FRAND licensing, which is fundamentally incompatible with Open Source communities. As with all de jure standards, participation in each of these standards bodies is expensive, both financially and in time, and engaging in their governance is beyond the scope of small players.

Given this context, when the European Commission requests standards that will be applied for conformity assessment, it’s not clear how they will take into account the development workflow that applies to Open Source software. Like the European Commission itself (as I commented recently), Europe’s standards bodies have no functional relationships with Open Source charities and do not consult them.

It is very important to find ways to give a voice to the true community and not just its corporate members. As things currently stand, Open Source will only be considered through the lens of its corporate uses. Since Open Source is a social movement with software artifacts for which the applications are diverse, paying heed only to the attributes of the software and the needs of the companies consuming it is an inadequate approach. You can’t even proxy through small business, let alone multinationals and their lobbyists – many of them are unaware of how communities work and without community understanding, fundamental errors can be made.

As a result, I believe whatever legislation arises from the CRA (and related instruments) needs to specify that standards bodies making related standards must include effective measures to consult and include the Open Source community. If this doesn’t happen, as NLnet Labs explained, “The only alternatives left available are the conformity assessment procedures that involve paying for third-party process auditors.”  And Open Source developers definitely can’t afford that.

This article first appeared on Webmink in Draft.

Image Walls Within Walls by Simon Phipps.

The CRA rightly addresses the need for commercial suppliers to protect their customers from exploits and cyber attacks. But legislators have exposed the open development of software itself to the regulations rather than just the for-profit use of Open Source artifacts in the marketplace. They are incorrectly assuming that Dirk Riehle’s terminology calling single-company projects “commercial Open Source” means it’s possible to use the “commerciality” of an application to distinguish single-company activity from community projects, and by using the concepts of proprietary software to then define boundaries.

There will be no escape from this for European projects like the Eclipse Foundation, but projects outside Europe — especially smaller projects — may just decide to erect geo-blocks and not deliver their work to European IP addresses. CRA-motivated geo-blocks start with needing to seek legal advice because it’s so confusing/unclear, only then to be told “maybe,” leaving you to make the decision on your own.

One response when I raised this was to say that the European Union is a massive and valuable market, and projects would not risk being excluded from it by geo-blocking. But this argument ignores the fact that just because Alice deploys some code profitably in Europe, it doesn’t mean Bob in Nebraska who wrote the code will share in the profit, whether he’s in business or not where he lives. Open Source licenses do not create a relationship in which financial reward is guaranteed.

Geo-blocks have happened before. Many small global publications block access from the EU rather than resolve legal uncertainties with GDPR. But the risk of CRA-related geo-blocks is much more consequential because reading those sites is optional whereas much Open Source software maintained internationally is woven into the fabric of Europe’s infrastructure.

In addition, those avoiding evaluating their GDPR responsibilities (or evading them after evaluating them) are likely to fear compliance will impact the benefit they gain from surveillance advertising, while for Open Source developers the perceived risk is of being the target of a punitive bureaucracy for failing to complete paperwork that adds nothing to their work.

If the confusion persists, Open Source projects will need to thoughtfully consider how to proceed. Disentangling dependencies that choose to pragmatically block Europe will be traumatic; should they be forked or substituted? Things could get very messy. Let’s hope the co-legislators see sense, finally talk to the Open Source community and address the issues.

This article first appeared on Webmink in Draft.

Image created by Simon Phipps featured on Webmink in Draft.