Open Source and the cloud are made to last Why You Shouldn't Miss Out On Open Source (And How To Get Started)

It is a virtue of leaders, being able to admit one’s mistakes.

In the words of Brad Smith, Microsoft admitted that the company was wrong on one crucial element – Open Source:

Microsoft was on the wrong side of history when open source exploded at the beginning of the century, and I can say that about me personally . . .

It is interesting how the wheel of history turns for companies and people. Once one of the great opponents of the Open Source movement, Microsoft is now officially embracing it and contributing to projects involving it.

Why does Open Source matter?

My own professional career started with Open Source; a big part of my work in the 90s and early 2000s involved FreeBSD and other Open Source OSs.

You too are benefiting from and using Open Source at the moment, even if you don’t pursue it actively. Most cloud providers include Open Source technology in their solutions. Your company and developers use solutions like containers, coming from the Open Source community.

You might write notes in an OSS application as I am right now (using VS Code, which is one of the best editors at the moment – it comes from Microsoft as Open Source).

Let’s talk about how not to be wrong about it in your organization. One way or another – moving to the cloud means starting to use Open Source.

1. Why start now, if you were not using OSS in the past?

What comes to your mind when I say Open Source? I don’t have a crystal ball or a thought monitor to look into your mind, but there is a pretty good chance that you thought about Linux.
Linux is the most successful Open Source project out there. It is also a central part of what was behind Microsoft’s approach to Open Source back then.

20 or even 15 years ago, we still had “the OS wars“. Things happened on a computer or a server. If it was a PC, laptop, or a big server machine – an OS was the ground for its operation, and IT was acting within the operating system environments. We are past that now.

Would you like a proof of that? I can write this post in Linux OS running as part of my Windows 10 setup, at the same time, on the same computer.

What has changed?

During the OS wars, it was all about winning the space of who controls the hardware, and Microsoft was betting on Windows. Now, it is different. We are in (or even past) the cloud wars. It is about the space in cloud computing, and the OS doesn’t matter that much when it comes to identifying the winner.

OSS has one main advantage here – you can’t beat the numbers. If one organization contributes to a project against multiple companies and individuals participating in and sharing it, over a long time, they are able to iterate faster.

Those are the big picture reasons, and your organization should start to adopt Open Source as well. In short, you can:

• Benefit from the collective work of many organizations and people (be ready to contribute to it, more on this further in this email)
• Iterate faster and accelerate the innovation in your projects.

Not convinced yet? Let’s look into the reasoning a little closer.

2. The three reasons why you should adopt OSS in your organization

There are many reasons why you may want to look into Open Source, but here are the three key ones which matter at a higher organization level. They are why you should invest in it right now:

Attract and retain talent

One of the main concerns regarding cloud adoption is the lack of skills and talent. Your chance of attracting the right people and keeping your existing team interested in what they do lies in letting them work on OSS projects.

If you move to the cloud, your team will want to use some Open Source projects or tools sooner or later. Having a policy that says “NO” will just lead them to look elsewhere. They will want to contribute back to the community, either in the form of code, documentation, or collaboration on OSS projects.

Again – saying “NO” is not a good way to convince people that this is the right place to stay.

Your team and company contribution to these projects also makes you visible to others in the same area. It might help you next time you seek to extend your team or simply look for help with some technical issues. People like to help other people who contribute to their success.

Be more agile and accelerate experimentation

I know. Everyone says, “be more agile”. Here is where it gets a very practical meaning. You can spend time on a project to write a piece of software of your own. You can use Open Source elements and experiment with the output to verify your experimental assumptions. Simple as that.

Let’s say that you want to try out a new business idea with IoT – maybe build some Smart Office sensors. You may want to develop your own devices or take a few off-the-shelf Raspberry Pi boards and build on them as we did in our smart office experiment. Guess what – Raspberry Pi is an OSS project, and there are plenty of designs and libraries for it.

It is just one example, and maybe not directly applicable in your case. Still, one thing is for sure: if you look around, there is a good chance that what you need for your solution is out there, built by others and shared as OSS components. Use them to develop and experiment faster.

Find out more about our Smart Office project from this video!

Focus on your core, not the heavy lifting around it

Lots of OSS projects are focused on general-purpose, reusable and heavy customizable components. Libraries, frameworks, and active components. Using it, let your team focus on the core of your business logic and the value component of the solution.

You can eliminate the heavy parts of your development by using ready-made solutions and adjusting them to your specific needs: using a configuration or modification of its code. It saves money, time, and lets you iterate faster.

3. How not to approach Open Source in your projects?

Those were the benefits; let’s look on the other side. What might go wrong with your organization’s approach to Open Source and how can it hurt you?

Saying a big “NOOOO!”

It happened in a couple of our projects, that an organization said a big “no, thank you” to using Open Source libraries. Why?

It wasn’t clearly articulated, but there was one main reason – the company didn’t have a policy on how to leverage OSS. Instead of creating one or looking into how it can be adopted, the answer was just “no, you can’t use it”.

Do you remember the point I made earlier about attracting and retaining talent? There is nothing more demotivating for developers than getting a “no” and a request to write something that is readily available. It makes people demotivated and puts them in a position where they feel their potential is lost.

If you go down this route (and there might be a good reason for it), be prepared to have your arguments and a solid plan to keep your people motivated. It will also carry additional costs in time and effort to produce the output replacing the components you will not use.

Saying a big “YES” with no policy behind it

The other extreme of the approach is to say “yes” to OSS with no strategy or plan behind it. I saw a project where clients were not aware of the various components thrown in by the development team. The team itself made a random choice of “what works”.

The result? A solution with dependency on components, which works at the moment but gives no insight into the quality of these projects, how to maintain them, or what are the sources. There is also a risk that these components might put your business at risk by:

• producing something in a way that is not compliant with a license of one of those projects
• additional obligations as a result of the license of one of the components (e.g. publishing your source code where you don’t want to or when you can’t do it)
• security risk, due to including elements that don’t have a supporting community, and for which you might lack the maintenance skills.

Those were two extremes, so what is between them? A conscious decision to leverage Open Source at your organization.

4. An Open Source policy – make it part of your governance approach

A key to successful and secure adoption and leverage of Open Source in your organization is to make it a part of your cloud governance and build policy around it. It will make it easier for your teams to decide:

• What type of projects they can leverage in their solutions
• Which license kind is acceptable and secure for your organization
• What type of contribution to OSS projects is allowed and how it happens.

What constitutes a good project?

One of the first things you want to codify in your policy is what constitutes a good or acceptable OSS project for you:

• What are the code quality metrics you will use to assess it?
• Is there a stable, active community of maintainers, and how big is it?
• How often is it updated, and are security fixes being built and applied to it?

Those are some of the questions (not all by any means), which will help you assess whether the OSS projects are acceptable according to your policy terms. They will help your team decide if this is something you want to use. They will also protect you from ending up with components with nobody but you working on them.

Know your license, its advantages, and obligations

Every OSS project is released with some kind of license. It might define the usage limits for this component or the responsibility of the company that is using it.

You don’t want to end up with a solution released to the market with a flaw in its licensing because of a component someone included in it without your knowledge. It is a considerable risk for organizations, and many are exposed to it and not aware of it at the moment.

Know the OSS licenses. Define which one is acceptable to be used at your organization, especially if you plan to release products including those components. Consult with your legal team if needed.

Click the image to learn more about cloud governance

Be ready to contribute or take control of a project

Once you start to leverage Open Source projects, be prepared to add to them. The contribution might be code to commit back, based on what your team has produced. It might be the time you will allow your team to spend on work around this project.

One way or another, this contribution will happen, so make sure that everyone understands its boundaries and the time allowed for it.

You can check the examples of Open Source Policy documents from large organizations in the Open Source Policy Examples and Templates repository.

The policy itself provides a guideline; you may support it with tools in your cloud environment. I’ve mentioned one of such elements previously when I wrote about the DevOps and SecOps approaches. WhiteSource Bolt is a free add-on to Azure DevOps, which scans all your projects and detects Open Source components, their licenses, and known vulnerabilities. Including it in your pipelines might be the first step to get visibility into what type of components you are using already. Visibility is a good starting point to get in control.

5. Open Source and the cloud are made to last

Open Source and the cloud are practically married. If you deliver projects on Microsoft Cloud, you will use Open Source, which is behind it. You will also see that many Microsoft projects are released as Open Source to build a community.

When you use it as part of cloud services, you don’t have to think a lot about it; it is provided. There will be a moment when you look further to include Open Source as part of your solution. There is a good chance it has already happened in your applications – consciously or based on a single developer’s decision.

This is a good thing.

Like everything at the organization level, it is even better if there are clear guidelines for your teams for including and leveraging it. Make Open Source a part of your cloud journey:

• Build an Open Source policy for your organization
• Define what a good Open Source project means for you
• Set up your DevOps pipelines to monitor and verify projects included in your solutions
• Monitor and apply security fixes to OSS projects as part of your SecOps process.

Where to learn more?

As usual, here is some further reading material for you – Open Source in the Enterprise (yes, it is an AWS book, but it applies to Microsoft cloud as well, and it is a good one).

If you have any questions about this topic or need a hand with setting up such policies in your organization, please get in touch.

Do you already have your Microsoft cloud and Open Source story to share? Then comment below and let’s talk about it!