Evolving your branching strategy

Recently I’ve been involved in two OSS projects, the first is ripple, a part of the Fubu family. The second is my own extension to Protobuf-net. Both are hosted on GitHub which brings a great opportunity to polish Git skills.

I started work on protobuf-linq on the master branch. It was the simplest and fastest way of getting this thing done. Throwing in a continuous built with TeamCity was simple: two steps of building and running tests. Then, I thought about stability of the master branch. Will it be always production ready? After a few conversations, rereading the great git book and going through the nvie’s post the idea was clear. Make the master branch always a production ready branch and add another dev branch. This would allow separate stable branch which latest version is always good to be built and publish from the development branch. The very same schema is used for instance by the Event Store public repository and many others.
This simple change, an evolutionary not revolutionary allows to separate production ready branch from dev branch malfunctions (history rewrites, errors and so on). Of course you can throw in tags, feature branches and hot-fix branches, but it isn’t needed from the beginning for an open source library. This always can be added as the ecosystem grows.

Open Source (almost) everything

Your software problems are not unique.
You don’t have time and money to maintain the whole toolkit you need.
You may be not smartest in the domain of the problem you’re trying to solve.

These are simple facts and you should accept it. What can you do about it? You can open source some parts of the solutions you deliver! Don’t think about a bank’s transactional system, or some high security fragments. Consider closed pieces, parts which deliver one thing (libraries). Put them on GitHub, or Codeplex or whatever. What you get is a chance of having your issues fixed by some other people. The another advantage of open sourcing some parts is paradigm shift. Now you have to combine, compose parts rather than getting your hands dirty in a ball of mud. What about your business, what about competition? At most they have a few of your tools, but the whole knowledge, how to assemble them stays in your company, and that in my opinion is the future of software development.


I had an idea about querying and projecting over big streams of messages serialized with Google Protocol Buffers. If one needs only a few fields to his/her projection, why don’t make it implicit and prepare an optimal way of deserializing only these fields? That’s the way Protobuf-linq has been born. It’s simple, fast and eager to help you iterate over big streams of data.
Check it out!