Gluster: Memories of Acquisition and Internal release naming choices
This weekend I was checking some good videos of a national forest near my native (< ~100kms), where I grew up. They give a glimpse of cultural and geographical idea of eco-system near where I grew up.
October 2011 : Red Hat acquires Gluster.
This news was very big for all of us. A company I joined in early 2006 (they didn’t yet had office in India, and it just had just 2 engineers other than the founders then), grew to big enough to be noticed, and get acquired for a decent valuation :-)
It was a natural fit for us, as we called ourselves ‘Red Hat of Storage’ (mainly giving credit to Red Hat for being a top open source company), as we were the ‘best’ open-source storage project then. The cake we cut that day said ‘Red Hat of Storage is now Storage of Red Hat’, which was very apt.
Many process changes after the acquisition happened smoothly as many tools we used were also similar to that of Red Hat. But only main change for many of us was the stricter hardening process Red Hat follows on the open source projects, and adds value through the testing teams and expertise of integrations with RHEL ecosystem, which ofcourse had good market share :-)
As part of this hardening process we had to make new releases of glusterfs as a Red Hat product, and we had to pick the version numbers. It was easy, because versions around that time was generally of form X.Y.Z and the first release had version 1.0.0 (not a hard job you see). If it was that easy, then there wouldn’t be any fun :-) So, we decided to have code names for the releases. Mainly because just after the acquisition, we had so many possible ideas around Gluster, we didn’t want to push every thing in one release. We surely dumped content of at least 3–4 releases to our new product management. We needed teams to focus on different releases at the same time, so that we can meet long term goals… It was full of activity then.
Now, the challenge was picking the code names for the releases. It was not an easy job. There were so many different type of names, names of people, scientists, mathematicians, philosophers. Names of rivers, countries, fruits, places, etc etc. It was not very simple. We (mostly me, Avati, Sac) had some conditions. The names should have relevance to India, Europe, Americas (because that was where most of the gluster developers were present). And we wanted order in things, (like 1,2,3 or A, B, C, D etc)… Finally after so much of discussions, we came to agreement on picking Names of the National Parks. It made a lot of sense. We named our first version as Anshi (read about it here). It is in India, starts with A, and more than that, it was in Karnataka, where our office was, and most of our team was from here.
Well, at the same time we could plan upto names of first 8 releases… :-) But we actually consumed and made releases upto E (5 of them).
- And it so happened that the external release version of Anshi was not, 1.0.0, but 2.0.0+
- I personally have visited 4 of these 5 national parks. (Had all the plans to visit Denali, but couldn’t. Twice).
- Internal Naming for Gluster releases were part of tradition we had before acquisition too. We named our versions based on developer’s IRC nickname, like ‘benki’, ‘bulde’, ‘DynWind’, ‘dtor’ etc.
- Making a release is hardest thing in software development (even today). It is not just tag, build, test, ship. I can easily understand why CI/CD is so popular, and makes sense.