Contribute




Corda is a collaborative effort and we welcome contributions. To start contributing you can fork our repo and begin making pull requests. Please use descriptive commit messages and follow our coding style guidelines. All contributions to this project are subject to the terms of the Developer Certificate of Origin, reproduced at the bottom of this page. We are honored to have a wide variety of contributors from various organizations which can be viewed on the contributors page of our Github repository.

Guidelines

Contributions from the community are welcomed and strongly encouraged. They will be accepted if they meet the following criteria:

  • Quality: Code quality meets the Corda coding guidelines, including sufficient test-cases, evidence that the contribution does not break any compatibility commitments or cause adverse feature interactions, and evidence of high-quality peer-review
  • Size: The Corda project's culture is one of small pull-requests, regularly submitted. The larger a pull-request, the more likely it is that you will be asked to resubmit as a series of sell-contained and individually reviewable smaller PRs
  • Scope: The feature's scope is within the definition specified in the Technical White Paper
  • Maintainability: If the feature will require ongoing maintenance (eg support for a particular brand of database), the contributor must accept responsibility for maintaining this feature
  • Non-duplicative: If the contribution duplicates features that already exist or are already in progress, you may be asked to work with the project maintainers to reconcile this. As the major contributor to Corda, many R3 employees will be working on features at any given time. To avoid surprises and foster transparency, our work tracking system, Jira, is public. In addition, the maintainers and developers on the project are available on the #design channel of our Slack and they would be delighted to discuss any work you plan to do

Project Leadership and Maintainers

The leader of this project is currently Mike Hearn, who is also the Lead Platform Engineer at R3. The project leader will appoint maintainers of the project, to whom responsibility is delegated for merging community contributions into the code base and acting as points of contact. There is currently one such community maintainer, Joel Dudley. We anticipate additional maintainers joining the project in the future from across the community. Transparency: In addition to the project lead and maintainer(s), developers employed by R3 who have passed our technical interview process have commit privileges to the repo. All R3 contributions undergo peer review, which is documented in public in GitHub, before they can be merged; they are held to the same standard as all other contributions. The community is encouraged both to observe and participate in this review process.


Mike Hearn

Joel Dudley


Contributing

You are encouraged to join our Slack, observe the Pull Request process in action, contribute to code reviews and start by submitting small changes. Transparency and Conflicts: At any given time, some R3 staff may be working on features for R3's commercial distribution of Corda and it is natural that some in the community may prefer such features to be available in the open source platform and decide to implement them themselves. We support this. It is our policy that should a community feature be contributed which meets the criteria above, we will accept it or work with the contributor to merge/reconcile it with the commercial feature. To be clear: the existence of the R3 commercial distribution does not preclude others from contributing equivalent features to the open source code base provided they meet the standard above.



Developer's Certificate of Origin

All contributions to this project are subject to the terms of the Developer Certificate of Origin, below:
Developer Certificate of Origin Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:

  • (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
  • (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
  • (c) The contribution was provided directly to me by some other person who certified (i), (ii) or (iii) and I have not modified it.
  • (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.



Transparency and Conflict Policy

The project is supported and maintained by R3, which consists of over two hundred firms working together to build and maintain this open source enterprise-grade blockchain platform. We develop in the open and publish our Jira to give everyone visibility. R3 also maintains and distributes a commercial distribution of Corda. Our vision is that distributions of Corda be compatible and interoperable, and our contribution and code review guidelines are designed in part to enable this.
As R3 is the maintainer of the project and also develops a commercial distribution of Corda, what happens if a member of the community contributes a feature which the R3 team have implemented only in their commercial product? How is this apparent conflict managed? Our approach is simple: if the contribution meets the standards for the project (see above), then the existence of a competing commercial implementation will not be used as a reason to reject it. In other words, it is our policy that should a community feature be contributed which meets the criteria above, we will accept it or work with the contributor to merge/reconcile it with the commercial feature.