33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
---
|
|
title: >
|
|
The contribution-first workflow
|
|
pubDate: 2023-12-01
|
|
permalink: >-
|
|
archive/2023/12/01/the-contribution-first-workflow
|
|
tags:
|
|
- software-development
|
|
- open-source
|
|
---
|
|
|
|
I've worked on many software projects with a lot of custom code.
|
|
|
|
Not all the code is specific to that client or project, and often, code is identified as it can be extracted from the project and open-sourced as a Drupal module, PHP or JavaScript library, or Tailwind CSS plugin.
|
|
|
|
Usually, the code is written as custom code initially, with the best intentions to revisit it once the project is complete and open-source it.
|
|
|
|
But this rarely happens, as there's always the next sprint or project waiting.
|
|
|
|
It takes too long to extract the code as it usually needs to be tidied or refactored beforehand.
|
|
|
|
It may have been written with the client or project name within the code, which needs changing.
|
|
|
|
My suggestion is to avoid this step.
|
|
|
|
## Here's the thing
|
|
|
|
Instead of writing it as custom code and hopefully extracting it later, start it as a separate module, library or plugin, and use Composer or npm to add it to your project as another dependency.
|
|
|
|
Whilst it's a slightly smaller overhead, it's better and less risky than rewriting or refactoring code later and it's already open-sourced.
|
|
|
|
Plus, you may get some issues, testing and improvements from others along the way.
|