Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor fixes to Contrib First #1530

Merged
merged 1 commit into from
Feb 18, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions common-practices-tools/contribution/contrib-first.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,15 @@

## Rationale for contrib first

- **Fiscal responsibility** - Building it and contributing it means that other government agencies will never have to pay to build the same thing twice. This helps agencies comply with Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software [OMB Memorandum M-16-21](https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf) and the newer federal [SHARE IT law](https://www.congress.gov/bill/118th-congress/house-bill/9566).
- **Reusability** - CivicActions other clients and the public at large can benefit from work that was already done.
- **Fiscal responsibility** - Building it and contributing it means that other government agencies will never have to pay to build the same thing. This helps agencies comply with Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software [OMB Memorandum M-16-21](https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf) and the newer federal [SHARE IT law](https://www.congress.gov/bill/118th-congress/house-bill/9566).

Check warning on line 11 in common-practices-tools/contribution/contrib-first.md

View workflow job for this annotation

GitHub Actions / remark-lint-suggestions

[remark-lint-suggestions] common-practices-tools/contribution/contrib-first.md#L11

Unexpected hard to read sentence, according to 5 out of 7 algorithms readability retext-readability
Raw output
11:150-11:516 warning Unexpected hard to read sentence, according to 5 out of 7 algorithms  readability retext-readability
- **Reusability** - CivicActions' other clients and the public at large can benefit from work that was already done.
- **Security** - Contributing our work to an open source project like Drupal means it may receive security coverage by the Drupal security team and the public. It is made more secure by getting more eyes on the code and more users surfacing any issues.
- **Avoiding the gift that never happens** - Clients are not typically supportive of taking working local software that was already built for them and in use by them, and then paying to move or refactor that software to become open source. The benefit is too small for the cost. By building it as contributed code first, there is no extra cost.
- **Development happens in the open** - The issues are public. The commits are public. Everyone can contribute improvements.
- **Reliability** - A solution built for contribution is often better designed, and better documented than a local solution meant to "just get it done". By putting our company and personal names on it publicly we commit to a quality product. Releasing a FOSS solution also increases the number of testers and edge cases that can surface and reduce bugs in the code.
- **Scalability** - Contributed FOSS is more scalable than one-off solutions and can grow with the power of the FOSS community.
- **Visibility** - CivicActions, our developers and clients earn positive representation as technology leaders and contributors.
- **Economy of tests** - Unit, Kernel and Functional tests for the module are run on the pipeline on Drupal.org. This translates into savings because they don't slow down custom tests running on client servers (human time savings). They run when the module is updated, not every time custom tests run (server cost savings).
- **Economy of tests** - Unit, Kernel and Functional tests for the module are run on the pipeline on Drupal.org. This translates into savings because they don't slow down custom tests running on client servers (human time savings). They run when the module is updated, not every time custom client tests run (server cost savings).
- **Digital Public Goods** - We know that contributing to the digital commons helps everyone. We know that we need to contribute to [digital public goods](https://en.wikipedia.org/wiki/Digital_public_goods) and not simply use them.

## Examples of FOSS CivicActions built as Contrib First
Expand Down Expand Up @@ -47,16 +47,16 @@
Not typically. There are three significant offsets that make Contrib First the more affordable option:

1. Having Open Source community members also work on "feature requests" that are defined during the build process can take advantage of cost free work.
2. Custom code required custom tests that run on the project's infrastructure, while contributed code has tests that run on the contributed framework hosting.
2. Custom code required custom tests that run on the client project's infrastructure, while contributed code has tests that run on the contributed framework hosting.
3. If one agency has built it, other agencies don't have pay to build it.

### Does contributed code cost more to maintain?

Generally speaking, no it does not cost more. In total cost of ownership, contributed code is less expensive to maintain than custom code. Contributed code usually gets updated by update bots when there are changes needed. They make issues and merge requests automatically. The same code existing as custom code has to be updated by project personnel when the need for a change is discovered. In addition, with a broader user base, Open Source community members are more likely to uncover bugs or inefficiencies and provide improvements.
Generally speaking, no it does not cost more. In total cost of ownership, contributed code is less expensive to maintain than custom code. Contributed code usually gets updated by update bots when there are changes needed. The bots make issues and merge requests automatically. The same code existing as custom code has to be updated by project personnel when the need for a change is discovered. In addition, with a broader user base, Open Source community members are more likely to uncover bugs or inefficiencies and provide improvements.

### How de we decide between what is worth contributing and what is too specific to a project to have more general appeal?

Our engineers are pretty good at recognizing opportunities to re-use their work across multiple projects. This is especially true in the Government sector where agencies often have similar requirements. If we have even a hint that multiple agencies could benefit, we build it as contributed code first. If it starts out as something so specific to a given project that it can no be generalized, the we build it as custom code for that project. However we continually re-evaluate our custom code to see if, over time, it has become something that is worth contributing.
Our engineers are pretty good at recognizing opportunities to re-use their work across multiple projects. This is especially true in the Government sector where agencies often have similar requirements. If we have even a hint that multiple agencies could benefit, we build it as contributed code first. If it starts out as something so specific to a given project that it can not be generalized, the we build it as custom code for that project. However we continually re-evaluate our custom code to see if, over time, it has become something that is worth contributing.

### Does developing by Contrib First take longer?

Expand Down
Loading