Managing outside contributions as an open source project

Raphaël 2024-09-19 opensource

Asfaload develops a solution to help secure and authenticate downloads from the internet, using blockchain technology, under an Open Source license.

Choosing an open source license is a first step, the next being to decide how to handle outside contributions.

Considerations

When deciding how to handle outside contributions, several considerations have to be taken into account.

Business

If you’re a company, you want to be able to generate revenue, which is usually difficult with Open Source software. Different approaches have been taken, such as

  • Selling services: build a business of selling services and specific development.
  • Open core: sell extensions or plugins for your open source solution under a commercial license
  • Dual licensing: in addition to publishing your software under and open source license, it is also available under the terms of a commercial license.

Each of those have pros and cons:

  • Selling services:
    • pro: revenue is generated more or less independently of the software development
    • pro: specific development can be merged in the software, increasing its features
    • con: it scales in limited ways
  • Open core:
    • pro: revenue is generated by selling licenses or subscriptions
    • pro: it scales well
    • con: you might want to artificially limit the usefulness of your open source offering to push people to your commercial offering (like ElasticSearch did, some report)
  • Dual licensing:
    • pro: no segregation between paid and open source features
    • pro: it scales well
    • con: outside contributors have to agree to the re-licensing of their contributions, usually by signing a CLA

Security

Accepting outside code also can raise security issues. Attack can be complex and run over a long time, often using social engineering in addition to technical prowess. A recent example is the XE Utils backdoor, where a backdoor was included by an attacker that managed to become a co-maintainer. The backdoor was included only after 3 years. As we were the target of a gross phishing attempt even before we release any significant code, we have to be cautious regarding outside contributions. The tools we release are meant to increase the security of our users, not bring backdoors with it….

Maintenance burdens

Maintaining a Free and Open Source software project is time consuming. Some projects decide to not accept outside contributions, the most notable of them being SQLite. Being a small team, we have to take this into account.

Conclusions

In regard of all these considerations, we have decided that:

  • we can only accept outside contributions if they are small. We are not able to manage outside-contributed big refactorings. We expect most external contributions would be small in the beginning, so the constraints this brings are limited for now.
  • we would like to keep the possibility to provide some tools under a proprietary license if a customer asks for it. It is thus possible that we ask outside contributors to allow us to relicense the contributed code as we wish, as long as we also provide it under the AGPL. A license change of a project can be done if contributors agree formally to the new license, we hope that such a simple procedure can be followed for our demand to allow relicensing.