Whether you want to learn new technology or provide stable versions of self-made tools to the open source community, most side-projects are either small enough to be the result of a weekend or codeathon or will eventually die.
But what if they don't?
In 2014 I developed a simple framework that was targeted at teaching PHP concepts. It was used at the company I worked for and it didn't take long until it snug it's way into code meant for production. And of course, this meant that it needed to be evaluated for security, performance and stability by experienced peers. Over the course of the next years, a complete rewrite was done on the side, and eventually another one. Since it was never an official product or framework to be used, it remained a side project I worked on once in a while. In order to better organize development, components of it moved out of the core and became their own repositories.
Production ready?
This was before GitHub offered private repositories for free, so naturally all sources were public and licensed as open source. And just as expected, nobody cloned, forked or reached out. In order to facilitate file creation, I developed a cli-tool based on node as I liked the comfort it provides (like e.g. Laravel users are familiar with).
However, by then I found myself having a tool-set that was perfectly suitable for collaboration. The way components are their own repositories and can be used really made sense. Team members could use distinct versions of components while others worked on them, leading to projects that have a completely different view on continuous integration as ultimately versions of single components could have dependencies for particular versions of other components. In other words: you directly work within a project on a component (or even components) that is treated the same way as any external composer package would be treated.
But the complete code-base was still tailored to our production needs and had no public documentation.
Switching jobs
Eventually, I switched my job and quickly noticed that existing methods of production didn't account for most of the challenges developers face every day. Additionally, the team was distributed throughout the world (making even simple SCRUM meetings a nightmare, but that is another story) and technologies and methodologies had to be found in order to account for around the clock development. Long story short, we adopted said framework. This also meant that availability of e.g. the cli tool had to be ensured, which meant providing it as an npm package. After a first panic I noticed how frequent updates produce wrong download-statistics on npmjs.com and verified by monitoring the GitHub repos that nearly nobody forked repositories, reached out or cloned. The couple of hundred downloads via composer could easily be explained by frequent use throughout the team.
Enter the community
I can't remember why, but a few months ago I decided to add a call to the cli whenever a complete new projects is initiated. This call simply sends the name of the project and captures no other information (I value privacy). Now, unless a team member buys a new device or plays around with own side projects, there is no reason to execute that specific command. So I expected to receive maybe 5 such requests per month.
Well, I was wrong. The actual number is currently in the hundreds, totaling over 5000 new applications as I write this.
Panic strikes
So what did that mean? Did people use it (or at least try it out considering the amount of apps called "test", "my-app" and alike) without having a documentation and without reaching out through GitHub or StackOverflow for help? Either way, documentation needs to be established, the open source community included and tutorials created. Not exactly an easy task for a complete ecosystem that is still changing sometimes fundamentally. So a couple of hasty YouTube videos and a started documentation later I am still far out of providing a solid product or support.
At this point I considered to simply pull back and regroup. I could remove all public access and republish in peace when the time comes?
Well, too late. Am I going to simply revoke access or updates to the about 15 daily new users who start using it? If only a hundred of them are actually working on a project they care about for weeks or months, don't they deserve not to be let down?
They do
So here I am dedicating the little spare time I have to work on solid documentation, best practices, tutorials and demos at least for the foreseeable future. And yes, the skeptic reader will surely question my intend. Am I asking for help? Is this why I am writing this article? Well, since you asked:
Docs:
Repos:
Top comments (0)