Practice makes you less bad

My grandfather taught me how to play chess when I was around 7 years old. He started with the basics : allowed moves, win conditions and some strategy to improve board presence and pretty much stopped there. He was not an expert chess player, but he had great patience and let me win as much as needed so I don’t lose interest in the game and also seemed to really enjoy the time we spent during the summer holidays.

Casual chess players hit a wall at around 1200 elo rating and after that, just playing random games does not improve their skill any further, or does so at a very slow pace, so a more focused learning is required, such as reading a book or playing tournaments.

I believe there are similar obstacles in software development or other engineering practices and one can only get that far by circling the comfort zone. I was recently pushed out of one of my comfort zones when the company I work for decided to change its business model to an open source subscription based model and I was tasked to come up with a strategy for the development team to accommodate it.

One challenge was to allow and facilitate external contributions into our existing codebase. After some evaluation, we chose GitHub as a platform for managing the code and the associated artifacts (issues, documentation, releases…) and started to draft how this will work.

Managing code

First, the principles :

• Community is the bleeding edge of development and new features are mainly developed there.
• Some features may have to be developed on the enterprise version first, due to contractual obligations, but every change will eventually be pushed upstream.
• Merging from the community branch to enterprise will occur at regular intervals ( 4-6 months ) and merging from the enterprise to the community branch will follow as soon as possible after an enterprise release.

There are two main branches ( development and master ) with an infinite lifetime for both the community and enterprise repositories. In order to keep things simple, merges are done in one direction only : dev->master. Development is done on the dev branch and merged to master as soon as the build reaches a state that is stable enough for production.

Support branches ( hotfix, feature ) have a shorter lifetime and will be merged and deleted as soon as they served their purpose. Their role is to accommodate parallel developments for multiple teams.

Managing releases

Principles again :

• Every commit on master triggers an ( automated ) release.
• Nightly builds are fully automated.
• We’ll be using a form of semantic versioning : MAJOR.MINOR.PATCH
• Major releases occur at regular intervals ( 1-2 years ) and feature releases at shorter intervals ( 4-6 months ).

There will be two versions of FinTP : the community edition and the enterprise edition. The main reason to offer an enterprise version is that we need to be able to offer support to our paying customers and for that we need to keep releases stable and controlled.

I’m taking a page from Joel’s book here and plan to automate the built process as much as possible. We want to enable a community of developers/users as much as possible, so we’re releasing precompiled binaries for the community edition on fintp.org and at the same time keep costs down, so it will have to happen with no human supervision.

Mistakes will be made

There is saying in chess that “a bad plan is better than no plan at all” and this is our plan to open our development efforts.

This is how we start and I can’t wait to see where the road will take us.