opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

docs(daily-email): add 2022-10-29

Browse source
This commit is contained in:
Oliver Davies 2022-11-04 01:02:27 +00:00
parent cdeb015148
commit cddb003b5b
1 changed files with 25 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
website/src/daily-emails/2022-10-29.md Normal file
View file

@ -0,0 +1,25 @@
---
title: >
The open-source-first development workflow
pubDate: 2022-10-29
permalink: >
archive/2022/10/29/the-open-source-first-development-workflow
tags:
- open-source
---
Yesterday's email talked about [writing reusable, framework-agnostic packages](https://www.oliverdavies.uk/archive/2022/10/28/why-write-framework-agnostic-packages) but didn't mention where those packages could be located.
They could be kept within a private repository and still have the same benefits, such as re-usability for internal projects, but I like to open-source code as often as I can and make it available publicly to see and use.
My preference is to follow an open-source-first workflow, identify which parts of a solution can be open-sourced and create them as open-source libraries or modules from the beginning rather than planning to extract them later. They can then be included within the main project using a dependency manager tool like Composer, npm or Yarn.
The eBook integration project that I mentioned was an example of this. I identified which pieces could be open-sourced, set up a public repository and put together an MVP based on that project's requirements. Issues were created for nice-to-have additions that could be added later, and the working version was installed with Composer.
There was no need to extract the code from the main project, no need to "clean it up" or check that it contained no client information, and I had the full Git history for the project - not just a new history from the point when the code was extracted and open-sourced.
I've worked on projects that contained a number of potential open-source components that would be released after project completion, but this didn't always happen - I assume due to time pressures to move on to the next project, a focus on adding new features or avoiding the risk of introducing breakages into the code. If the code had been open-sourced from the beginning, these things wouldn't have been an issue.
I've also worked on projects where I've followed an open-source-first approach and released a number of PHP libraries and Drupal modules, including [Private Message Queue](https://www.drupal.org/project/private_message_queue), [System User](https://www.drupal.org/project/system_user), and [Null User](https://www.drupal.org/project/null_user) modules. I've also been working on some legacy code recently and started to replace it with a library that I've already open-sourced, even though I'm in the early stages of developing it.
As someone who enjoys creating and working on open-source software, I would encourage you to open-source your code if you can and to do so sooner rather than later and not wait until the end of your project.