I started getting involved in the foodsharing software last October, I originally wrote: For now the task is breathe life into the development again.

It has been progressing at a pretty glacial pace since then (but progress is progress right?) but recently there has been more interest in finding a clearer way forward from here. I get the feeling people are thinking the software is a lost cause by now.

Personally, my frustration has increased as I see a ever growing list of issues in gitlab, not much clarity around switching to laravel, what to do with foodsharing light, how to progress open sourcing… etc.

For some reason unknown to me, I cannot bear to give up!

It’s been really motivating to me to have more people get in contact via the #foodsaving-dev yunity slack channel, I’ve been chit-chatting with Peter from Zürich and Kristijan from Mainz a lot, understanding a bit more how foodsharing works, and this last weekend near Münich chatting with Clara from the foodsharing board at our foodsaving worldwide hack week, and ongoing dev chats with Matthias, Tilmann, and Raphael.

Matthias also recently set up auto deployment, so that any changes to the git master branch are deployed to beta.foodsharing.de, and Tilmann added some useful tools to help us track php errors.

I recently bought a book titled Modernizing Legacy Applications In PHP and found that it provides a step-by-step guide to refactoring, it feels like a friend to hold my hand. Here is an excerpt about this incremental refactoring approach:

Given the risks associated with a complete rewrite, I recommend refactoring instead. “Refactoring” means that the quality of the program is improved in small steps, without changing the functionality of the program. A single, relatively small change is introduced across the entire system. The system is then tested to make sure it still works properly, and finally, the system is put into production. A second small change builds on the previous one, and so on. Over a period of time, the system becomes markedly easier to maintain and improve.

So, after talking with all these people and discussing and reading, I feel a plan is emerging (but not there yet), something along these lines:

  • get more clarity/process between tech/non-tech people to understand how all this stuff works
  • speed up the time it takes for a developer’s code changes to be deployed to the website
  • encourage developers to take responsibility for their changes (making sure they work as intended for the users)
  • support a group of interested developers to slowly work through the steps defined in the book
  • continue to support contributors to make small fixes and feature changes throughout

This does not directly address the bigger topics or further goals, but should be a step in the right direction. When you are lost in the forest, you should climb a hill to get a better view of the area.

I climbed that hill a couple of weeks ago :)