#c9d9 Continuous Discussions, Open Source and DevOps

slide1During my vacations in August I participated on a Continuous Discussions (#c9d9) episode about Open Source and DevOps.

Continuous Discussions is a community initiative powered by Electric Cloud, and consists of a series of community panels about Agile, Continuous Delivery and Devops.

This formate, a discussion panel that debates different perspectives about a specific topic, surprised me with the interaction and fun that was to make part of this event. So, well done #c9d9, I really enjoyed.

Following, some insights from my contribution to the panel:

Open source – free as in beer or free as in puppy?

You always have a cost, independently if it’s open source ou closed source. The cost depends on the size of your team, the complexity of your tasks and the frequency of change. The good thing about open source is that you can contribute to the change and take it in your direction. That’s what I like the most in open source.

Where do you use open source?

Open source tools are used in some points of the development pipeline, like for example delivering changes to databases. If you are a startup company there is a high probability to use a lot of open source tools, and with the evolution and the complexity of your team/organization you will probably start to migrate to commercial tools. The rule is “try before you buy it”. You can combine open source and commercial tools like Jenkins, Team City, TFS Build, Octopus Deploy, etc. Even Microsoft is becoming more open.

Where would you not use an open source tool?

In big and complex systems. An important question is, what’s the common factor when you migrate to open source tool,  ot to an closed source tool, in both directions? In my opinion it’s the size aligned with complexity. So, use the right tool for the right job, open source or commercial tools.

Quality concerns?

First, if the open source tool role it’s to support your development pipeline, you have more flexibility to manage the exposure to errors. But, if the open source tool makes part of your product you have to take responsability for that integration, you have to assure that quality is there. Quality must be present everytime and everywhere, however if we are talking at develpoment pipeline level I have more flexibility, but if we are talking at costumer level I have to be more careful.

Security concerns?

Open source tools security concerns make part of the general security concerns. I try to make the development environment as closed as possible.

Legal concerns?

Both, open source and closed source has law concerns. Sometimes the decision is made at a higher level and you can not do anything, other times you can influence or even make the decision, at that time is better the read the license (you probably thinking “who does that?”).

You can see full episode here!

Leave a reply:

Your email address will not be published.

Site Footer