Patchwork is the name of a program I wrote. The basic problem in the software industry is that you want software that’s really easy to read and conceptually simple yet you also want that software to be feature rich, business specific and highly optimised. Rarely can you have easy to read code and highly optimised code. Rarely can it be feature rich and yet expose the simplest abstraction of a solution.

I tried to solve that by writing an automatic patching tool that allowed to you keep in your version control software the most basic, simplest version of the code which then allows you to recursively apply patches to it in order to get new features, rather than to do the status quo, which is to only maintain a configurable version of a single, optimised and complex codebase.

Version control systems have branches but their general use revolves around independent development of features that eventually go back into trunk/master, or to have two parallel versions of software. However they aren’t typically used to manage a piece of software at two different levels of abstractions.

It prevents new people picking up the fundamentals. It means people use bloated software if they don’t want all the features. Patchwork was my solution to this problem. This graphic shows how Patchwork could model your software

[ basecode. simple. easy. clean. ]
   |- Feature 1
   |- Feature 2
       |- Feature 3
           |- Feature 3 highly optimised

You choose the features you want and build an executable which gives you just what you want. If you don’t want feature 2 you don’t get it. Hopefully you’re saying to yourself.. ok, there are other solutions for this problem. If you use a plugin architecture or enable hooks into your application, you get that feature. Not only that, but you can add more features later.

True. But you have to write that framework into your code. That increases its complexity in my mind. It certainly increases the SLOC. Also there needs to be forethought into what exactly you make available to a given plugin. The problem of allowing people to work with the most basic version of the solution however still hasn’t been tackled.

I was going to use this feature on my Operating System called Farmix. This is how a tree of feature may look:

[ basecode. simple. easy. straight from the example OS I copied it from ]
|- better memory management
|- better process scheduler    -|
|- real time version of OS      |- together they form POSIX std.
|- better disk support         -|       |- Minix compatibility layer
|- filesystem A
|- filesystem B
|- Company X's optimised version for their user app

You could teach students the base level and they could switch features on and off to see them and understand those features in isolation. It may even be worth point out that as customisable and flexible as Linux is, it still contains a base level of Kernel features they chosen that perhaps you don’t want. They cater to the masses. In Linux you may need to cut features out. That takes an understanding of those features themselves and how to cut them out. With this system you don’t.

The code

I wanted to see this idea through to the end. So I did. I posted the application to my github account: The entire program is in one Python file. The benefit being is that you can distribute with your own application easy and use it in your build or configuration scripts to do some legwork for you. The workflow is like this:

patchwork init                    # create a patchwork managed directory tree
# do some work
patchwork create patch "feature1" # mark the diff since patchwork init as an isolated feature with the name "feature1"
# do some work
patchwork create patch "feature2" # mark feature 2 as a feature with the name. This is marked as dependent on feature1
patchwork off all                 # switch all features off. go to the simplest version of the code
patchwork on feature1             # look at the code base with feature 1 enabled.
patchwork status                  # see what patches are applied.

The Summary

I knew going into this application that there were going to drawbacks to my system. Firstly the fact that changes to the core meant changes or testing to all the patches and features of top. That hosting multiple versions of the software adds another flag of confusion on top of what you’re doing. That there is overhead in managing the tree of patches you are building, but fundamentally, maintaining the simplest version of the code and the complex, can be so far apart in terms of implementation that it’s not even worth doing. You are maintaining two separate applications. You would really really need to want those new developers to make it worth its while. It isn’t really worth it. It’s a failed idea but I’m glad I saw it through.