77 lines
3.7 KiB
YAML
77 lines
3.7 KiB
YAML
uuid:
|
|
- value: 53ad5789-5fd6-41e8-b748-ce9e0bff280b
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:26+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: |
|
|
Open-source first doesn't mean you need to cover every use case
|
|
created:
|
|
- value: '2023-12-06T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:26+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/12/06/open-source-first-doesnt-mean-you-need-to-cover-every-use-case
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>An argument against the <a href="/daily/2023/12/01/the-contribution-first-workflow">contribution-first and open-source-first approach</a> is that it takes longer than writing custom code.</p>
|
|
|
|
<p>I think that this is due to thinking that you need to cover all use cases within the code if it's open-sourced, whereas, in custom code, you only write the code you need.</p>
|
|
|
|
<p>My approach is to write the same code, whether it's private and custom or open-sourced.</p>
|
|
|
|
<p>The code is based on the same set of requirements, and the only code that should be written should be enough to satisfy those requirements.</p>
|
|
|
|
<p>It doesn't get written if something isn't part of that objective.</p>
|
|
|
|
<p>It could be added to a public roadmap for the future if it doesn't need to be part of the initial minimal version.</p>
|
|
|
|
<p>If someone creates an issue to request new functionality or submits a pull request to contribute potential changes, you decide whether to accept or reject it or even add them as a maintainer to manage their own contributions as well as administrative tasks like managing the issue queues.</p>
|
|
|
|
<p>If you accept their code, you get the benefit of it (though you also need to maintain and own it) or, if you reject it, you can continue focusing on your minimum-viable version for its initial project.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>An argument against the <a href="http://default/daily/2023/12/01/the-contribution-first-workflow">contribution-first and open-source-first approach</a> is that it takes longer than writing custom code.</p>
|
|
|
|
<p>I think that this is due to thinking that you need to cover all use cases within the code if it's open-sourced, whereas, in custom code, you only write the code you need.</p>
|
|
|
|
<p>My approach is to write the same code, whether it's private and custom or open-sourced.</p>
|
|
|
|
<p>The code is based on the same set of requirements, and the only code that should be written should be enough to satisfy those requirements.</p>
|
|
|
|
<p>It doesn't get written if something isn't part of that objective.</p>
|
|
|
|
<p>It could be added to a public roadmap for the future if it doesn't need to be part of the initial minimal version.</p>
|
|
|
|
<p>If someone creates an issue to request new functionality or submits a pull request to contribute potential changes, you decide whether to accept or reject it or even add them as a maintainer to manage their own contributions as well as administrative tasks like managing the issue queues.</p>
|
|
|
|
<p>If you accept their code, you get the benefit of it (though you also need to maintain and own it) or, if you reject it, you can continue focusing on your minimum-viable version for its initial project.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|