OpenSource and Golang — Project Manager’s delight!

Being an OSS Developer and Architect for the last couple of decades, I have been pretty content with Python, JavaScript and Java as the language tools to build scalable systems. I have been wary and weary with the euphoria around the new languages that seemed to sprout dime a dozen, that promise unicorns and rainbows for the developer and the production operations teams.

Language in itself has never been a daunting entity, if we understand the fundamental principles and the purpose behind the design of the language constructs. It is always fun to learn and play with a new language, and experience some ah-aha moments.

But, what if, you also need to wear the Project Lead/Maintainer/Manager’s hat, worrying about the code smell that is being generated by the team (usually a mix of entry level programmers to experienced). Add super-tight schedules to the project and you almost get nightmares with the technical debt that gets accumulated.

It almost makes practical sense to stick to the seasoned languages, processes and tools that we already know.

Or so I thought.. until 2016..

Some thing fundamentally changed in the ethos of the software engineering (I need not mention the D..word here). There was renewed focus on productivity at all levels and layers, status-quo was being challenged from all fronts and not just some groking geeks. From the future, we might as well look back and call this as a software engineering renaissance.

The success and the rise in popularity of the projects like docker, kubernetes, rancher, minio and the likes, provided required data points to reinforce the need to re-invent the way infrastructure products are being developed.

Do we really need to spend hours (in some cases) days resolving the issues found with the complicated stacks delivering the cloud infrastructures? Even if we sustain with additional man-power (man-months), taken to deliver patches and upgrades and spend endless weekends/nights pushing them into production.

Yes, sometimes you need a wake-up call to step out of the picture to see what is really missing. We (at CloudByte) had such an wake-up call (without getting into the details), where we needed to change things for good.

This for me, was an great opportunity to re-evaluate how we are going to really build the project — with the same seasoned tools or change them?

Interestingly, there were two common elements in the projects that I mentioned above — OpenSource and Go. (OK. And Containers too! But I guess this goes without saying these days. huh?)

This post from texlution.com, from couple of years back, pretty much sums up the reasons on why Golang (and OpenSource if I may add) is doomed to succeed as language of choice for opensource projects.

• Go projects tend to be overwhelmingly easy to follow. For OSS projects, being written in Go is a feature in itself. It invites to look under the hood
• Tools like go fmt, golint and go vet leave very little room for any personal coding standard. Go makes reviewing merge requests much less tedious. It makes accepting contributions easy!

Anything that you pick will have its own idiosyncrasies and challenges. So it is with OpenSource and Go. I will probably dwelve into the deliberations with a follow-up post, but it might suffice for now to mention a couple of things about Go.

If you are looking at Go for the first time, you are in for a few shockers. It is an stubbornly opinionated language, by design. Once you recover from that shock, you are in for a treat with the amount of tools that are available and can be easily built, which makes the life of a Project Lead/Maintainer/Manager delightfully painless.

I have recorded some of my journey with Golang in these commits.

Golang may not really show you unicorns. But Go-coupled with OpenSource will definitely show you the rainbows, in the form of the “free” badges that you can add to the project. A project that really looks engineered and not just put together!!

Some of the cool badges!

• github.com (source repository and binary release distribution server)
• travis(CI server)
• codecov (test coverage analysis )
• goreport (static analysis, linting on the source code)
• godoc (reference documentation)
• readthedocs (project documentation)
• dockerhub (containerized image hosting)

The best part (thanks to the genorous efforts from companies behind the above online services), all these tools can be integrated with each other seamlessly, almost with a few clicks from the browser!

Checkout openebs/maya projects to see how these tools are being used or join our slack channel to discuss about them!