Thoughts and opinions

A Guide to Learn Ruby in 2021 and 2022

2021-11-13T00:00:00+00:00

I will assume that you don’t know Ruby, and you are curious about this programming language.

Here is what you will find in this article:

What is Ruby?
Why learn Ruby programming language
- What other people are saying about why learn Ruby
What does it mean to write good Ruby code
Learning Ruby - where and how
- If Ruby will be your first programming language
- If you know how to code

What is Ruby?

Ruby is an interpreted, dynamic, dynamically typed, garbage-collected, high-level, objected-oriented, general-purpose, and open-source programming language.

Let me explain these by one:

1 Ruby is interpreted: that means that Ruby does not compile to a binary, but it uses an interpreter to translate the code into machine code on the fly (without any intermediary step like compiling).

2 Ruby is dynamic, meaning that all static analysis needed to execute a program will happen at runtime. In this way, the type of variables can be changed while the code is running, adding new code and functionalities to existing already instantiated objects, and many more.

3 Ruby is strongly typed, meaning that if an operation needs a specific type, then the type variables/objects involved are checked before running that operation. Yet Ruby does not use static type checking: the interpreter does not enforce type constraint rules while evaluating a program. So it seems that it is correct to refer to ruby as being dynamically typed.

Here is a short example:

var = 42
new_var = var + "string" 
# => TypeError (String can't be coerced into Integer)

The last line will throw a type error as Ruby will check the type of var and the type of "string" and see they are different and cannot be coerced.

4 Ruby is garbage collected, meaning there is no need for the programmer to manage memory. It has a garbage collector that knows when to free memory (when a variable/data is no longer needed and can be freed)

5 Ruby is a high-level programming language meaning that it is closer to the natural English language than to computer code, thus making the code easier to read and write. It also allows us to focus on high-level business logic and not on low-level tasks (like memory management, registers, call stacks).

6 Ruby is object-oriented, meaning that in Ruby, everything is an object. The most common way to program ruby is to do it in an Object-Oriented Programming (OOP) fashion by using classes, inheritance, compositions. Ruby also has some support for functional programming because it has its procs, and lambdas and allows passing functions as params to other functions, but doing it this way is less common in Ruby.

7 Ruby is general-purpose, meaning that you can write software in Ruby in many domains; there is no focus on supporting one domain over another.

8 Ruby is open-source, meaning that you can find the code for Ruby open and change it according to your own needs if you feel this way. Check the code for Ruby in one of the sources listed on the Ruby website: Ruby Core.

In case you want to read more about what type of programming language is Ruby go to the following resources:

Why learn Ruby programming language

First, let’s start with my reasons why I like this programming language:

It is expressive: you can write code that will be easy to read and understand, and the language will support you with this
It is easy to think in Ruby, as it has a lot of ways to solve the same problem thus, it can match the way you think about a problem
Eco-system: it has a mature eco-system of plugins, most of them battle-tested in production, so there is no need to re-invent the wheel every time you need a solution to a common problem
Community: it has a great, passionate and active community of developers, and finding an answer to a problem you might have it is very easy

What other people are saying about why learn Ruby

I don’t want to create a comprehensive list of why Ruby is a good programming language and why it might be an excellent decision to start using it. Still, in case you are looking for more, here is a list of articles and some concise summaries for each one of them:

Some People Say Ruby Is Too Complex for Beginners… - An article by Chris Castiglione about why having multiple ways of doing the same thing is a good thing: it offers flexibility, it creates space for the programmer to be creative, and it does not have too many specifics to keep in mind when using language features.

A question on Dev.to about “Why do people like Ruby” has many answers. Here are some main reasons why people are saying there that they love Ruby:

Flexibility and expressiveness makes it easy to write code with very little boilerplate
It “optimises for brain to code time” as it is easy to write the code almost as you think
The code can be read like talking, and it is easy to understand it
It is fun
Has a great community
You can be incredibly productive
Quick feedback and prototyping It will help if you read the answers there. You will also see the are some concerns and some arguments people have for those concerns.

Here are two quotes that Yukihiro Matsumoto¹ wrote in an essay called “Treating Code as an Essay” part of a book called “Beautiful Code”² which I think will describe how Ruby feels based on how its creator sees programming:

“…lines of code are meant—before all else—to be read and understood by human beings…“

“Programs share some attributes with essays.

For essays, the most important question readers ask is, “What is it about?”

For programs, the main question is, “What does it do?”

In fact, the purpose should be sufficiently clear that neither question ever needs to be uttered.

Still, for both essays and computer code, it’s always important to look at how each one is written. Even if the idea itself is good, it will be difficult to transmit to the desired audience if it is difficult to understand. The style in which they are written is just as important as their purpose. Both essays and lines of code are meant—before all else—to be read and understood by human beings.”

“…it is therefore more important by far for humans to be able to understand the program than it is for the computer…“

“Most programs are not write-once.

They are reworked and rewritten again and again in their lives. Bugs must be debugged. Changing requirements and the need for increased functionality mean the program itself may be modified on an ongoing basis.

During this process, human beings must be able to read and understand the original code; it is therefore more important by far for humans to be able to understand the program than it is for the computer.”

What does it mean to write good Ruby code

One thing sticks out from all these resources about why people like Ruby: it allows writing “beautiful code”.

Here are some definitions for beautiful code:

Yukihiro Matsumoto (creator of Ruby programming language) is defining beautiful code in the “Treating Code as an Essay” having the following attributes:
- Brevity: writing concise and brief code “because there is a definite cost involved in scanning code with the human eye, programs should ideally contain no unnecessary information.”
- Familiarity: Ruby uses traditional control structures and tries to be consistent and not surprise programmers in the way it works
- Simplicity: Ruby offers complex tools and shifts the complexity from the code written by the programmer to the programming language, thus allowing the creation of simple and beautiful code
- Freedom from enforcement from tools: Ruby does not force you to do to things in one specific way. It is flexible enough to allow you do to things your way, to serve your purpose
- Balance between the other attributes
Russ Olsen in “Eloquent Ruby” defines Ruby style of programming as:
- Crystal Clear: “good code tells the reader exactly what it is trying to do. Great code shouts its intent”
- Concise: “It’s much easier to understand what a method or a class is doing if you can take it all in at a glance”
- Self-descriptive: “Good Ruby code should speak for itself, and most of the time you should let it do its own talking.”
Hal Fulton in “The Ruby Way” defines the Ruby way as:
- Simplicity: even when doing complex things, the complexity should be pushed out of sight so that it appears simple
- Brevity: “don’t write 200 lines of code when ten will do”
- Readability: remember that “computers exist for humans, not humans for computers”
- Following the Principle of the Least Surprise: “the program should always respond to the user in the way that astonishes him least”
- Consistency and Regularity

Read more resources about what does idiomatic Ruby means here:

Idiomatic Ruby: writing beautiful code - an article with code example about writing intuitive ruby code
Beautiful Ruby Code - this is an example of a coding guideline for Ruby. Still, after learning a little bit of Ruby, I recommend installing one of these static analyzers: : Rubocop or Standard.

Learning Ruby - where and how

I think there are multiple approaches to learning a programming language. I will try to recommend resources based on this, but please go ahead and skim through them however you find it useful or exciting for you.

If Ruby is your first programming language?

If you never did programming before starting learning Ruby (or any other programming language), I recommend understanding the basics of thinking:

Learn To Program online book is a great tutorial to start learning to program. It is easy to follow, and it explains very well with simple examples of the programming concepts.
Ruby for Beginners a good tutorial for beginners, created so that at the end, “you’ll be able to read, understand, and write basic Ruby code yourself”.
Learning Ruby: From Zero to Hero it is a good Ruby tutorial that can one can follow even if they don’t know yet how to program.
Learning Ruby Tutorial this is again an excellent tutorial to start a learning program as it explains very good the basic programming concepts.

After going through the basic concepts of Ruby, the next step is to deepen your understanding of some of the core concepts:

Object-Oriented Programming, for this I recommend going through The Basics of OOP Ruby and then through this answer about how a class works on Stackoverflow
Understanding the Ruby Object Model: here are a couple of resources Understanding the Ruby object model (an old article but the main ideas are still valid), Everything is object in Ruby (an article building on the first one)
Singleton Class (Eigenclass): Explaining Ruby’s Singleton Class (Eigenclass) to confused beginners, A gist with examples explaining Eigenclass

After this, you should google Ruby meta-programming and read some of the resources you can find.

If you know how to code

Learning Ruby basics

First, start by looking around on the official website at their documentation section: https://www.ruby-lang.org/en/documentation/. There are many links for good tutorials for IDEs, Ruby’s documentation, and more helpful information.

If you already know to program in some other language, I think you can go through this short official Ruby tutorial: Ruby in Twenty Minutes (ruby-lang.org). It covers almost anything that you need to know about Ruby syntax.

If you already know one of the following programming languages: C/C++, Java, Perl, PHP, Python here you will find some short guides explaining similarities and differences between Ruby and each one of these languages: Ruby From Other Languages (ruby-lang.org).

Try Ruby in Browser (ruby-lang.org) - Learn Ruby by using this interactive play-ground. It is a very easy quick-start without the need to install anything on your own computer.

Learn Ruby (codecademy.com) - a simple course teaching ruby basic structures in a very interactive way, offering at each step an interactive terminal for practice.

Pragmatic Programmers - Learn to Program (pine.fm) - this is an online book which will teach you programming concepts in Ruby. It is also a very great start to understand Ruby even if you already know programming.

Why’s (Poignant) Guide to Ruby (poignant.guide) - a very unconventional introduction in Ruby. This book is a fresh and innovative take to teach someone Ruby and it also goes in its own way more into thinking like a Rubyist.

TutorialsPoint - Learn Ruby programming (tutorialspoint.com) - this is a good, concise text based tutorial to learn Ruby. While not being exactly creates as an interactive first learning experience, for each piece of code has a link for a live demo of the code where you can tinker with it as you like.

RubyLearning (rubylearning.com) - while not an interactive tutorial like others, it has good examples of the structure and syntax of Ruby.

Introduction to Programming with Ruby (launchschool.com) an online book about Ruby syntax and standard library

Video From freeCodeCamp.org about learning Ruby (youtube.com) - is a 4 hours Ruby introduction video while building some small learning programs (like building a calculator, a guessing game)

Ruby Tutorial with Code Samples (fincher.org) - a simple tutorial to learn Ruby.

This video course from Pragmatic Studio https://pragmaticstudio.com/ruby seems very well organised and touches the most important topics for learning Ruby.

Beginning Ruby 3 is an introductory book for Ruby teaching the latest Ruby idioms. It also goes through everything needed to be productive in Ruby.

The Well-Grounded Rubyist is a very good book with examples and clear explanation about when and why to use various Ruby language features.

Ruby: The Big Picture is an up to date guide to learn Ruby and it explores Ruby core features, objects, metaprogramming and Ruby ecosystem.

Other type of resources which offer a short introduction to Ruby:

Learning Ruby: From Zero to Hero - on freeCodeCamp, a long version article with a quick introduction to Ruby
Unlearn Programming to Learn Ruby - an article more about how to think when solving a problem with Ruby

Resources to deep understand Ruby

RUBY KOANS - it is a list of learning exercises where you need to fix a failed test to make it pass. While fixing it you will learn more about Ruby.

Ruby Specs - this is not an official documentation but I recommend you just go ahead and read some of the language specs here. It is very well written and can teach you a lot about how Ruby works.

An introduction to Object Oriented Programming in Ruby (freecodecamp.org) about OOP in Ruby. Check also this tutorial also on freeCodeCamp.org about Object Oriented Programming in Ruby (freecodecamp.org). In general freeCodeCamp.org is a very good place to learn more about Ruby.

Ruby Oneliners is a collection of practical one liners Ruby code to solve various day-to-day needs.

The Meta-programming Ruby book teaches you how to do meta-programming in Ruby https://pragprog.com/titles/ppmetr2/metaprogramming-ruby-2/

GoRails Ruby Lessons This is a great collection of many Ruby lessons exploring various pragmatic topics. I suggest to start with HTTP Server in Ruby from Scratch where you will not only learn more Ruby but also explore some topics about how other Ruby HTTP servers work.

Practical Object-Oriented Design, An Agile Primer Using Ruby (POODR) A book that goes deeply into object oriented design and can teach you a lot about how to organise your code, what goes where when thinking about classes and modules. It also goes deepling into explaining composition and inheritance.

Competitive Programming / Coding Challenges

The following list of app can be used mostly to learn or deepen your understanding of algorithms.

I recommend Codewars.com which has a very good collection of problems to be solved in Ruby with their own code editor and will run automatic test suites to check your code. Codewars has a very good gamification where you can earn points by solving katas.

Hackerrank.com has a section named “Skills Available for Practice” where you can choose Ruby and see a lot of problems that you can solve with Ruby. It has their own code editor and will check your solution by running a batch of tests on it. You can also have access to read other people solutions and see how you can make yours better.

Hackerearth.com is another competitive programming or coding challenge platform. Also here you might find a Practice section where there is a mix between tutorials and problems to be solved. They have their own code editor and can run tests to check your solution.

Coderbyte.com offers a course with all lessons free and some challenges (some of them are paid) to learn Ruby. Lessons are in video format and challenges have an in-browser code editor which can run a test suite to check your solution.

Go back to “Learn Ruby on Rails Guide”

Notes:

Yukihiro Matsumoto is the creator of the Ruby programming language ↩
Beautiful Code “In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes” ↩

Learning Ruby on Rails - a guide about the WHY and the HOW

2021-09-19T00:00:00+00:00

There are multiple ways to build web applications in 2021, more will probably spring in 2022. All have their pros and cons.

I will try to convince you - the reader - why I think you should choose Ruby on Rails by explaining what Ruby is and what is Ruby on Rails and then giving you some ideas about projects that you can build while learning to deepen your understanding.

I feel that we can do more as a Ruby community to help people experiement and embrace Ruby. There are a lot of resources available to learn Ruby, but I believe there are not enough up-to-date resources helping to transition to Ruby.

I don’t plan to create a new resource to teach Ruby itself or Rails, but more of a quide of existing resources available around.

Here are the reasons why I think Ruby on Rails is a good choice in 2022:

It has a mature/battle-tested eco-system of plugins (they are called “gems”). You can find gems for authentication, for testing, for integration with a wide range of third parties (from AWS to Mailchimp, Twillio …)
The Majority of IDEs are offering good support for developing in Ruby (RubyMine, Sublime Text, VIM, Visual Studio Code and many more). If you are searching for a good auto-completion I recommend TabNine, it has a great support for Ruby on Rails.
Ruby is a language that is evolving, sometimes at the forefront of programming language innovation, sometimes borrowing great concepts from other languages, and oriented toward developer happiness.
The community is welcoming, has great conversations, helpful responses, encouraging contribution, caring about new people joining in.
Rails is a web framework that is actively maintained, used by big websites like Basecamp, Github, Gitlab, Shopify and many more. It is a framework developed to solve practical problems and offer pragmatical solutions for everyday developer tasks. It inspires me to a calm rhythm of development that covers many needs for you.

There might be other reasons to learn Ruby and Rails (or other Ruby web framework) and I will write about them in deep in the next articles I will publish here.

This is somehow a guide I cobbled together with the following objectives:

The first part will be about “Understanding what Ruby is, why choose Ruby, and where to learn Ruby”
The second part will be about “Understanding what Rails is, why choose Rails, and how to start learning the Ruby on Rails web framework”
Then, I plan to give you some ideas of projects to build while learning Rails
At the end, I will have some recommendations of communities, developers, and blogs to follow.

Product Engineers - or how to balance speed and quality

2020-08-24T00:00:00+00:00

There are many writings about the struggle between the speed of feature development and quality of code, products, tests, or any other work product used in the development process.

A short answer is to not sacrifice one for the other.

Here I will focus more on the “how” to achieve this at the level of an organization, focusing on development.

Here are some of my thoughts on creating a product organization that can rapidly, iteratively, and simultaneously have the right level of quality.

Focus on creating Product Engineers

I think the base of creating a product organization is helping your colleagues become Product Engineers. If this is the first time, you hear about this role (The product-minded engineer) is a great article explaining what a product engineer is. I will write here the main points from that article:

Proactive with product ideas/opinions
Interest in the business, user behavior and data on this
Curiosity and a keen interest in “why?”
Strong communicators and excellent relationships with non-engineers
Offering product/engineering tradeoffs upfront
Pragmatic handling of edge cases
Quick product validation cycles
End-to-end product feature ownership

The article has some excellent advice for anyone who wants to become a product engineer.

Now let’s explore what the organization can do to help people transition in becoming product engineers.

1. Facilitate direct communication with the end-user

Without direct communication between your engineers and end-users, there is no possibility of having product engineers.

No persona or narrative will create the same connection and empathy as the direct interaction with the end-user. I am not saying that personas/avatars/narratives are bad. They are important to remember, to capture stories, facts … but they will not create a drive; they cannot sustain proactivity; it is hard to identify possible edge cases, which might be new products or new features. They also eliminate a human connection.

There are multiple ways to facilitate this communication. I will just remind you here of two: User Interviews and Design Thinking. User interviews are easy to start with, but I will suggest going into Design Thinking to engage your end-users truly.

Here is a little checking you can do to see where you are:

How many people from your team talked live or online directly with an end-user? If you are less than 50%, this is a bad sign that your team is disconnected from the end-user, and probably they don’t deeply understand the value they create for the end-user.

2. Delegate more product decisions to engineers

Only after making possible the first point, the organization should facilitate delegation of more product decisions to engineers.

It goes mostly toward transforming the role of the Product Manager to a mentor/coach of the team in helping the team understand the vision and support them in finding ways to achieve it. This will be a hard role for Product Manager, and she will play here a role of a tester, challenging team assumptions, asking for metrics, showing a mirror for the team from a product perspective and making sure feedback goes back to the team no matter if a feature was a success or not.

It might seem that in the short term, this might decrease the successful features released, but in the long term, this will truly create the best teams and will allow you to scale up as much as possible without losing the initial sync with the user and the product.

Reality check:

Who is writing the requirements? POs or the team? If only POs, then you score lower on this. POs should help the team define goals, vision, and objectives, but the team should manage their requirements. If they cannot write requirements, they don’t understand the end-user.
Does your team have access to business metrics? If not, they cannot handle product decisions because they cannot assess their decision-making process and cannot adapt.

3. Open feedback from users

How does your team handle open to feedback from end-users? When an end-user complains, what does your team do? Do they get upset? Do they blame the end-user? Are they indifferent?

Getting upset together with a lack of action is a bad smell for the product’s understanding of the team. The same goes for indifference or blaming the user.

The right mindset is a curiosity to find you what happened, to explain why.

Here the organization has a crucial role in how it handles failure.

If failure appears as something terrible and unrecoverable, then no curiosity is possible. People will try to hide it as quickly as possible.

4. Testers as representatives of end-users

The organization should support testers to become representative of end-users. They should be the ones who point out that this feature does not provide value for the end-user, or this flow is too long.

Testers should become the go-to for any team member who wants to validate/invalidate an assumption.

Also, testers should test assumptions made by product managers to validate that what is built is needed by the end-users. This is an essential point because the work of product managers should also have associated tests. Reviewing requirements is not testing product assumptions. It mostly tests how the requirements are written. To test product assumptions means to ask questions about what the end-user wants and how well our product can solve user problems.

5. Working in plain sight with assumptions

The team should acknowledge their product assumptions, detail them, and find ways to measure validity.

The market/end-users should finally make the validate step of an assumption. Any other validation should be looked at as being flawed and used only when there is time pressure or a limited budget.

6. Support ideas from anyone

Another way to support your developers and testers to be more involved in the product is to consider their ideas. Don’t just dismiss them because they are technical. A lot of innovation in IT comes at the crossroads between what is technically possible and how that can be used to solve in a new way user’s problem.

I know that the first thing that comes into mind is to form a kind of jury with people from business and technical and invite team members to pitch there. It is a good idea if and only if the team members are encouraged to understand what a product decision is.

Don’t just vote what ideas are okay and which not, but explain to the team members why and the idea is not suitable for the product or end-users. Have a debate about that and encourage them to get real feedback from users before pitching their ideas.

7. Be more narrative and explain decisions

Especially when working remotely, communication about why a decision was taken, and how the decision-maker got it is very important.

This is more important if you want to empower your engineers to become product engineers.

Here is an example of what should be shared when presenting a new feature:

Who are the users who will mostly use this?
What problems will solve for them? How are they solving their problem now, if any?
Why do we think the users will adopt this feature?
Why is this feature more important than others in our queue?
What are some assumptions that we took into consideration when deciding this?
What are some metrics that will show the success of the feature?
What are some metrics that will show the failure of the feature?

This could be a starting point to have a conversation about a proposed feature by a product manager, and the most important thing to focus on is the word conversation. It is not only about writing answers to these but having a conversation about the feature with the team and openly answer their questions.

Product Managers should explain their decisions

2020-08-09T00:00:00+00:00

One important thing when creating a customer-oriented organization or even a product organisation is facilitating an understanding of how to make product decisions for everyone in the company.

The Product Managers should explain how they arrived at a decision when they communicate with the development teams what feature to create.

This communication should include at least:

What is the data used to decide?
How was the data acquired?
Who is the target group that is mainly using the new feature?
What were assumptions about the target group made while deciding what features should be done?
What were the features they said NO, and what trade-offs were made when choosing what to do and what not to do?

I would add to this list one more:

“What data/information/logic would you need to make you change your mind?”

This approach is a data-driven one, and it is the one that facilitates the best cooperation in the organization.

It could also be that a Product Manager takes a decision based on a vision of the future, based on a “feeling” of the future, not only based on data. In this case, communicate what the vision of the future is and what makes it probable.

I know that some Product Managers are maybe afraid to talk with their teams about why they decided to say yes to a feature. They might be afraid that the team will not embrace the feature or, worse, debate the decision, which might seem like a time lost.

Hiding these things will either:

(a) Make the team more dependable on the Product Manager, and every time they have a lack of understanding, they will stop and ask guidance, creating a delayed delivery.

(b) Support a mindset of no questions asked, which then creates a culture with low creativity and innovation as the development teams are far away from the end-user and their needs. So they cannot generate useful ideas for the business.

One cannot be a customer-oriented organization if only a few people understand the customers. I think it is very important for Product Managers to present a narrative from the point of view of the customer for each product decision.

Management of open source licenses

2020-07-27T00:00:00+00:00

I usually not read a licenses of packages I am using. I just click on the License file of a package I want to install, but I don’t look further to its dependencies.

Now that I am starting an open-source project and learning about various open-source licenses, I am more aware of the implications of licenses included in a project.

This is how I discovered the fantastic gem named Licensed.

As my project is developed in Ruby on Rails this gem satisfies my needs as it has support for Rubygems and NPM packages.

Here is how Licensed can be used in a Ruby on Rails project to manage licenses

Choose allowed licenses

The first step is to choose what type of licenses do you want to have in your project. This decision should be made after you choose a license for your own project. Because not all licenses can be combined between them, their combination will sometimes impose some behaviors on your project.

In the end, you should have a list of licenses that you are ok with, including in your project.

Install the licensed gem

In case you have Ruby installed in your system, then this is as simple as:

gem install licensed

Here are the full instructions provided by Licensed gem to install it.

Create a .licensed.yml file

Next, you should create a .licensed.yml file in your root directory. The possible settings that can be set in this file are described here.

The most critical parts for now are:

Defining sources
Defining allowed licenses

Here is how the file looks for me:

sources:
 bundler: true
 npm: true

allowed:
 - mit
 - apache-2.0
 - bsd-2-clause
 - bsd-3-clause
 - isc
 - cc0-1.0

This is a standard configuration that I recommend for a standard Ruby on Rails project based on non-left copy licenses. All these licenses allows anyone to do almost anything with your project with the only restriction being that they must mention the creator. I wrote an extensive guide about MIT, Apache 2.0 and BSD here

You can check now what kind of dependencies your project has by using:

licensed list

This will list all your dependencies.

Cache dependencies and metadata

The next step is to cache all dependencies and their license metadata in a file. Licensed needs this, and you also need this to keep track when a package changes license.

To generate the cache simply execute:

licensed cache

This will create a directory .licenses/ and you will find there a tree structure of directory and files matching your source and dependencies.

I committed this entire directory to Git to have version control.

Verify licenses against an allowed list

To verify if licenses of dependencies are in the allowed list execute:

licensed status

This will check licenses and display a list of licenses which need review.

Review licenses

Next step, you should open each .yml files pointed by the status command and check the licenses there.

I found three cases:

Truly a package has a license that is not compatible with what I have in my allowed list. In this case, I tried to replace the package. This is the actual case why you should use this gem. To find this kind of package and then decide if you want to change your license (or allowed licenses) to include this package or find alternatives, maybe including implementing the functionality yourself.
A package has one of the allowed licenses by their license file has some non-significant diffs, like extra lines, or formatting. In this case, you should open the configuration file .licenses.yml and add a section names ```reviewed where you would put the path until the package in .yml format.

Here is an example:

reviewed:
    bundler: 
     - activerecord # MIT License
      - concurrent-ruby # MIT License
      - puma # BSD 3 clause
      - rexml # BSD 2 clause
      - sqlite3 # BSD 3 clause as specified here https://github.com/sparklemotion/sqlite3-ruby/blob/master/sqlite3.gemspec

As you can see here actually, the license of ActiveRecord is MIT License, but the gem was not able to identify it as such. If you look at SPDX MIT license and ActiveRecord license file you will see that AR license has an extra line about Arel originally copyright and this is why this gem was not able to identify it correctly.

Another case is that you will discover a new type of license that you did not think before. In this case, you should read it and then decide if you want to add it in the allowed list of not.

Rerun licensed status

Whenever you change something in the .licensed.yml config file or add/remove a package, you should rerun

licenses status

CI Github configuration

I wanted to make sure that the license check will happen every time someone will push something upstream, so I created a workflow on Github with the following content:

This will run the licenses status command and report if it will detect any license which is not allowed.

Final words

Here is the full .licensed.yml file:

Also, find the example of the Verify Licenses Github Actions workflow here.

Employee engagement starts with how your organisation reacts to failure

2020-07-20T00:00:00+00:00

Before going into creating a significant strategy for employee engagement or for building an innovation culture, the first start is to look around and answer the question: How do we react to failure?

A culture where no one wants to make mistakes shrinks creativity and innovation. No one will take any chances to do something wrong so no experimentation will happen.

This is a short path toward a place where everybody does the same and says the same. Feedback will become just a formality due to the fear of failure. Everybody will say things are ok even when they are not.

This part with feedback is a second wave of putting a company down because the leadership will become disconnected from the reality of the company. So changing things will become harder and harder thus making the adaptation to new realities heavy and costing a lot.

The cost is not only about the money, but it is a cost of time. People will try to hide failure, making learning take a lot of time. Thus the company will fail in the end to adapt to the market and remain behind.

A developer’s guide to the most common open-source licenses (MIT, Apache 2.0, BSD)

2020-07-04T00:00:00+00:00

Notice: Please be aware that I am not a lawyer, and what I write here is based on some other sources from the internet, among which very few are from lawyers.

Please note this is a long article covering the following topics:

Summary
Comparisons between MIT, Apache 2.0 License and BSD licenses:
- Permissions, conditions and limitations
- Protection for the author/contributors
  - Warranty
  - Limitation of Liability
MIT License
Apache 2.0 License
BSD License
More resources
- Combining licenses

Summary

As I embarked into doing an open-source project, among the first things to decide is what kind of open-source license should it have. After reading a lot of materials, I will write here my recommendations and also some reviews of the most used licenses in open-source projects.

I will start with what I would recommend:

I would choose Apache License 2 for a finite project which can be installed directly and used. Think about something like a full web app, or a desktop application. This is because it can create trust in installing the application and using it without any concern about patents.
I would choose the MIT License for plugins, gems, packages, libraries. Think about Nodejs packages or Ruby gems. I recommend this because MIT License is easier to understand (can be read in a minute), and thus more developers will use the creation, and it is used a lot in the community.
A good alternative is the BSD License, either 2-Clause or 3-Clause, in case there are concerns about using your name/brand to promote derivative work or by users of the software.

A strong indication for choosing Apache License 2.0 is the analysis of 75 open source projects across 35 companies where Apache License 2.0 is the most used one.

All three licenses analyzed here seems are recommended by well-known groups/foundations in the open-source community (FSF, OSI, Debian, Fedora):

Free Software Foundation - list of GPL compatible licenses
Open Source Initiative - list of OSI approved licenses
Debian Foundation - list of licenses which follow the Debian Free Software Guidelines
Fedora Foundation - list of right licenses that are OK for Fedora

Their main advantages:

All 3 of them allow derivative work, sub-licensing, commercial use, and distribution.
They can be combined with any other license - including copy-left licenses (of course, under the new license), so developers don’t need to restrict what to include in their open-source software.
They are supported by default by Github and Gitlab when creating a new repository, and they are acknowledged as compatible with Free Software and Open Source Software by FOSS, OSI, Debian, and Fedora (see links provided above).

Their main disadvantage:

There is a risk specifically for the developer that someone might take the code and use it in an unintended way (including making it part of a proprietary, non-open source software), and there is no legal ground to stop that.

Comparisons between MIT, Apache 2.0 License and BSD licenses

Permissions, conditions and limitations

Image source: snyk.io

Image source: wikipedia.org

Protection for the author/contributors

Two possible risks that might arise from putting something out as an open-source for the authors could be:

To be required to offer a warranty for the end-users.
To be liable in case some loss happens to end-users while using the software.

Warranty

Regarding warranty, all three licenses are pretty clear about what is not covered.

MIT License - Warranty Disclaimer	Apache License 2.0 - Warranty Disclaimer	BSD 2-Clause or 3-Clause - Warranty Disclaimer
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON INFRINGEMENT.	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON INFRINGEMENT. \| Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.	THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

Limitation of Liability

The same is right about Limitation of Liability:

MIT License	Apache License 2.0	BSD 2-Clause or 3-Clause
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.	Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.	IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Notice that MIT and BSD have writing in ALL CAPS, even if this might not make any difference (kemitchell.com):

Courts have criticized the Bar for pretending as much, and most everyone agrees all-caps does more to discourage reading than compel it.

MIT License

MIT License facts and figures

Type of license: PERMISSIVE

The full content of MIT License can is here: https://opensource.org/licenses or here https://spdx.org/licenses/MIT.html. There is one minor difference between these two versions regarding the explicit requirements to include the liability paragraph.

Left: SPDX License, Right: Opensource/Debian MIT License

Free Software Foundation, OSI, Debian, and Fedora include MIT License in their lists of free software or open-source software licenses.

It is recommended by https://choosealicense.com (created by Github) with the explanation:

The MIT License is short and to the point. It lets people do almost anything they want with your project, like making and distributing closed source versions.

According to this study, the MIT License is the most used license with 27% usage. A public search on Github for how many repositories are using MIT License found over 4 million results.

MIT License: permissions, conditions and limitations

tldrlegal.com does an excellent summary of what the OSI license allows:

A short, permissive software license. Basically, you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source.

A Wikipedia page describes a comparison between various licenses and looks at 7 possible permissions. Here is what is says about MIT License:

Actions	Permission
Linking of the licensed code with code licensed under a different licence (e.g. when the code is provided as a library)	YES
Distribution of the code to third parties	YES
Modification of the code by a licensee	YES
Protection of licensees from patent claims made by code contributors regarding their contribution, and protection of contributors from patent claims made by licensees	MANUALLY
May be used privately (e.g. internal use by a corporation)	YES
Whether modified code may be licensed under a different licence	YES
Use of trademarks associated with the licensed code or its contributors by a licensee	YES

From an open-source handbook created by FINOS, we have the following summary:

Binary or Source Code	Actions	Requirements
Binary Form	Distribution, unmodified	Provide copy of license and Provide copyright notice
Binary Form	Distribution, modified	Provide copy of license and Provide copyright notice
Source Code	Distribution, unmodified	Provide copy of license and Provide copyright notice
Source Code	Distribution, modified	Provide copy of license and Provide copyright notice

Also a good description of what this license allows or not can be read here writing.kemitchell.com and here opensource.com.

Some highlights from these two documents:

Because the language is broad and open-ended, then there is no restriction on what the licensee can do with the Software. Kyle Mitchell says about this:

“It gives licensees a strong argument against any claim by a licensor that they didn’t give permission for the licensee to do that specific thing with the software, even if the thought clearly didn’t occur to either side when the license was given.”
It does not cover the patent license explicitly. Mitchell says that there might be legal concerns for licensee about “getting sued for copyright infringement and getting sued for patent infringement”. His exact statement says:

“The general language “deal in” and some of the example verbs, especially “use”, point toward a patent license, albeit a very unclear one. The fact that the license comes from the copyright holder, who may or may not have patent rights in inventions in the software, as well as most of the example verbs and the definition of “the Software” itself, all point strongly toward a copyright license.”
A member of Red Hat Legal team thinks that:

“There is nothing that would lead one to believe that the licensor wanted to preserve their right to pursue patent infringement claims against the use of software”
The MIT License has some conditions for using the Software:

If you give someone a copy of the software, you need to include the license text and any copyright notice.

… You can’t pretend that the MIT code is your own proprietary code, or provided under some other license. Those receiving get to know their rights under the “public license”.

Risks for choosing MIT License

What is left out or unclear

Still there are a lot of concerns expresses (not exactly from lawyers) that:

The MIT License does not cover explicitely the patents rights
The MIT License does not cover explicitly the trademarks restrictions

Sources for rising these concerns: one, two, three.

Possible risks from difference versions

One important thing to consider when talking about “MIT License” is that there are many variants of this license, but it is not versioned. So it is tough to understand about what version of this license people are talking about.

It seems like a lot of projects use the MIT License - Expat as it is presented by Debian and is the same as the one recommended by Opensource.org. Gnu.org names this license “Expat License” and warns against naming it “MIT License” because MIT used many licenses for their software:

Some people call this license “the MIT License,” but that term is misleading since MIT has used many licenses for software. It is also ambiguous since the same people also call the X11 license “the MIT License,” failing to distinguish them. We recommend not using the term “MIT License.”

To see a long list of what people call MIT License can be found at this link: https://fedoraproject.org/wiki/Licensing:MIT.

Also, research from 2015 - “On the Variability of the BSD and MIT Licenses” by Trevor Maryka, Daniel M. German, and German Poo-Caamano - found 11 separate license versions. The study data are available here turingmachine.org/../mit-bsd, and for a summary of differences, you should look directly at this file turingmachine.org/../mitx11.txt.

Compatibilities with other open-source licenses

MIT is a permissive license allowing you to re-license the derivative work under any license (source). In general, when you combine the MIT License with any other open source license, the resulting derivative work will not be MIT License. When you combine Public Domain, or MIT Licensed components, the result derivative work can be MIT License.

A more detailed graph of what licenses can be used with what licenses were created avid A. Wheeler: dwheeler.com.

Open source policies recommending it as default

There are some companies which are suggesting MIT License as default one for new open-source projects:

Buffer is recommending the use of MIT License in their open-source guide.
Joyent is also recommending the use of the MIT License as the default choice.

Example of projects using MIT License

Apache License 2.0

Apache License 2.0 Facts and figures

Type of license: PERMISSIVE

Apache License 2.0 can be found on the Apache Foundation website or at OSI website or at Software Package Data Exchange website.

A search on Github on how many repositories are using this license found 1.284.000 projects under Apache License 2.0

Free Software Foundation, OSI, Debian and Fedora are all including Apache License 2.0 in their lists of free software or open source software licenses.

Apache License 2.0: permissions, conditions and limitations

Here is a brief summary as described by Choose a License:

A permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code.

Another short summary of this license from White Source Software could be:

You can freely use, modify, distribute and sell a software licensed under the Apache License without worrying about the use of software: personal, internal or commercial.

Summary of permissions, conditions and limitations:

Image source: choosealicense.com

A Wikipedia page describes a comparison between various licenses and looks at 7 possible permissions. Here is what is says about Apache License 2.0:

Actions	Permission
Linking of the licensed code with code licensed under a different licence (e.g. when the code is provided as a library)	YES
Distribution of the code to third parties	YES
Modification of the code by a licensee	YES
Protection of licensees from patent claims made by code contributors regarding their contribution, and protection of contributors from patent claims made by licensees	YES
May be used privately (e.g. internal use by a corporation)	YES
Whether modified code may be licensed under a different licence	YES
Use of trademarks associated with the licensed code or its contributors by a licensee	NO

From an open source handbook created by FINOS we have the following summary

Binary or Source Code	Actions	Requirements
Binary Form	Distribution, unmodified	Provide copy of license
Binary Form	Distribution, modified	Provide copy of license and Modified files must include “prominent notices” of the modifications
Source Code	Distribution, unmodified	Provide copy of license and Retain all notices
Source Code	Distribution, modified	Provide copy of license and Modified files must include “prominent notices” of the modifications and Retain all notices

Other important things to take into consideration about this License:

“If anyone intentionally sends a contribution for an Apache-licensed software to its authors, this contribution can automatically be used under the Apache License” - toptal.com
It explicitly asks for unmodified parts of the software to retain Apache License - whitesourcesoftware.com
“It requires you to explicitly list out all the modifications that you’ve done in the original software” - whitesourcesoftware.com
The patent grant should have a positive effect on Users who should not be afraid that any Contributor might pursue royalties from their contribution to the project - opensource.com
Finally, the patent licenses granted will be terminated immediately in case the Licensee decides to file a litigation against the Licensor.

Kem Mitchell includes indirectly in an article the Apache License 2.0 as a better license than MIT License of BSD:

The open licensing state-of-the-art has evolved, and releases under old licenses picked specifically for lack of clear patent permission won’t be greeted as good faith open source, but as legal traps, especially for organizations without access to savvy counsel.

Paul H. Arne from Morris, Manning & Martin, L.L.P published a whitepaper about “Open Source Software Licenses: Perspectives of the End User and the Software Developer“ where they state:

The Apache license is well-constructed, relatively easy to read, and provides a different approach to open source licensing from other open-source software licenses

Risks for choosing Apache License 2.0

One thing consider is that you cannot combine Apache License 2.0 with GPL v2 (oss-watch.ac.uk and gnu.org).

Another aspect to consider is that a “contributor can modify the code and then sell it as proprietary software” - mmmlaw.com.

Compatibilities with other open source licenses

As described here, Apache License 2.0 cannot be combined with GPL/LGPL v1 and v2. This means that code released under Apache License 2.0 cannot be used in GPL v1 and v2 software. So if this kind of compatibility is needed, then Apache License 2.0 should not be chosen.

If MIT Licensed code is combined with Apache License 2.0 code, then the derivative code might be Apache License 2.0.

Recommendations to use Apache 2.0 License

GNU recommends to use Apache License 2.0 over MIT/Expat license.

Google recommends to use Apache License 2.0 opensource.google

Example of projects using Apache 2.0 License

BSD License

BSD License Facts and Figures

Type of license: PERMISSIVE

Initially there was a 4 clause license, which usually now can be identified by the name BSD 4-Clause "Original" or "Old" License. This version was incompatible with GNU GPL and it included a clause to acknowledge the authors of any components under this license in any advertising material.

This clause - the advertising clause - was removed and thus BSD 3-Clause license was created. Then also the non-endorsement clause was removed so BSD 2-Clause license was born.

Among them, BSD 2-Clause is the most permissive license.

The commonly used BSD licenses are:

BSD 2 Clause: full content of license can be found here (opensource.org) or here (spdx.org). Github and Gitlab are using the SPDX version.

Differences between the OSI version and SPDX versions for BSD 2 Clause are the following:

BSD 3 Clause: full content of license can be found here (opensource.org) or here (spdx.org). Github and Gitlab are using the SPDX version.

Differences between OSI version and SPDX version for BSD 3-Clause are:

On Github there are almost 80.000 projects (data from July 2020) using BSD 2 clause and almost 180.000 projects (data from July 2020) using BSD 3 clause.

When creating a new project Github.com offers the option to choose between two types of BSD License (both of them are the SPDX versions and the naming convention is the same):

BSD 2-Clause “Simplified” License - which is the same as the SPDX BSD 2-Clause license
BSD 3-Clause “New” or “Revised” License - which is the same as the SPDX BSD 3-Clause License

The same goes for Gitlab.org, which offers the same 2 types of BSD Licenses that match the SPDX versions:

BSD License: Permissions, conditions and limitations

BSD 2 Clause License

From tldrlegal.com :

The BSD 2-clause license allows you almost unlimited freedom with the software so long as you include the BSD copyright notice in it (found in Fulltext). Many other licenses are influenced by this one.

From the open source handbook created by FINOS we have the following summary:

Binary or Source Code	Actions	Requirements
Binary Form	Distribution, unmodified	Provide copy of license and Provide copyright notice
Binary Form	Distribution, modified	Provide copy of license and Provide copyright notice
Source Code	Distribution, unmodified	Provide copy of license and Provide copyright notice
Source Code	Distribution, modified	Provide copy of license and Provide copyright notice

BSD 3-Clause License

From [tldrlegal.com](https://tldrlegal.com/license/bsd-3-clause-license-(revised):

The BSD 3-clause license allows you almost unlimited freedom with the software so long as you include the BSD copyright and license notice in it (found in Fulltext).

This Wikipedia page describes a comparison between various licenses and looks at 7 possible permissions. Here is what is says about BSD 3-Clause License:

Actions	Permission
Linking of the licensed code with code licensed under a different licence (e.g. when the code is provided as a library)	YES
Distribution of the code to third parties	YES
Modification of the code by a licensee	YES
Protection of licensees from patent claims made by code contributors regarding their contribution, and protection of contributors from patent claims made by licensees	MANUALLY
May be used privately (e.g. internal use by a corporation)	YES
Whether modified code may be licensed under a different licence	YES
Use of trademarks associated with the licensed code or its contributors by a licensee	MANUALLY "You may not use the names of the original company or its members to endorse derived products" source tldrlegal.com

Risks for choosing BSD License

BSD License (2-Clause and 3-Clause) does not grant any patent rights - whitesourcesoftware.com.

Among software creators, there might be concerns regarding how competition might be inspired by their open source and use the knowledge to gain dominance.

Here is a possible answer to this from a resource on the FreeBSD.org website:

Under a BSD license, if one company came to dominate a product niche that others considered strategic, the other companies can, with minimal effort, form a mini-consortium aimed at re-establishing parity by contributing to a competitive BSD variant that increases market competition and fairness. This permits each company to believe that it will be able to profit from some advantage it can provide, while also contributing to economic flexibility and efficiency. The more rapidly and easily the cooperating members can do this, the more successful they will be. A BSD license is essentially a minimally complicated license that enables such behavior.

BSD 2-Clause is almost similar to MIT License - according to this answer on Stackexchange - so for users of the created software under BSD 2 Clause, there might be concerns regarding possible patent risks.

BSD License compatibility with other open source licenses

BSD License is compatible with proprietary or open-source licenses. The only restriction is that 4-Clause BSD is not compatible with GNU GPL. The David A. Wheeler graph can be used to see what license goes with what license.

Examples of projects using BSD License

More resources

First, you should check the list of open-source licenses as it is defined by OSI.

Then here is a list of open-source licenses with various comments from the GNU perspective for each one of them:.

Another good place to read about what kind of permissions or restrictions open-source licenses have is this handbook created by FINOS.

Then you can also check choosealicense website friendly website created by Github.

A good study about open source licenses. I found interesting the shift from copyleft to permissive license published by WhiteSource.

Other articles talking about open source licenses:

Developer’s Guide to Open Source Licenses
A list of other possible open source licenses with different permissions
The Legal Side of Open Source section at Open Source Guides

Combining licenses

Important resources to read about combining licenses:

David Wheeler “license slide” figure
Janelia FlyEM Project page about Open Source Licenses and their Compatibility based on David Wheeler license slide article.

In case a project has multiple licenses, then the resulting derivative work should comply with requirements from all licenses, and most probably will need to include all licenses in its license file. This discussion on Open Source StackExchange is very clear about what needs to be done.

Final words

It might be that I got some things wrong or something is missing so if you have feedback please send it to ideas@ghinda.com.

In case you just want to comment on this, here is the Hacker News discussion.

Why I am starting an open-source project

2020-06-30T00:00:00+00:00

I contributed bits and pieces to various open-source software, but nothing in the long run, I might say. I also was never a maintainer.

I use a lot of open-source in my daily life, from programming languages to code editors. I am daily using daily Ruby gems, Nodejs packages, web frameworks (I am using Ruby on Rails mostly), CSS frameworks (I am using Bulma, TailwindCSS, Boostrap), Javascript frameworks (mostly Stimulus.js, recently started Vue.js).

It is hard for me to imagine the products I created or creating now without these open-source software. When I think about the creators or maintainers of various open-source packages, I am amazed to see their dedication, helpful responses, and the way they care for the community of users and contributors. For me, they are indeed the heroes of the modern web.

In a way, these open-source creators remind me of the late 90s when I had my first email address and started using Unix for the first time. I learned a lot from various mailing lists and IRC channels about computers, about how to install and reinstall my OSes, about how to create my first program, about changing config files for some games to make them work. It was a time when we helped each other when Google and StackOverflow did not exist. It was real communication supported by a genuine passion for assisting others in discovering the wonders of this new thing we called WWW.

I will start working for a couple of months to a new project: open-sourcing the IT Connect app that I developed while I was Innovation Product Owner / Innovation Master at METRO SYSTEMS Romania. The application is a web platform for innovation and idea management.

The open-source application will be developed with Elena Bogus as Product Owner, and I will be the developer and maintainer. It will actually be a rewritten from scratch because now we have a better and brighter vision about how such a platform should be. I will outline why I want to do an open-source project and hope that maybe I will inspire others to do the same.

Before going into that, let me give praise to METRO SYSTEMS Romania. I think accepting to open-source this application is an inspiring decision taken by them, and it is along an innovation road they took 6 years ago. It is a significant contribution to put there in the world for anyone who wants to use the knowledge that we created there while experimenting with innovation and entrepreneurship. Just in case you want to have a small taste of some learnings from this journey, Elena wrote an excellent article about 7 learnings out of building a corporate innovation culture.

Embarking in a journey to build an open-source project for me is mostly about:

A sense of contribution and giving back to the community
Deepening my knowledge and learning something new
Connecting to new people

But let’s start with WHY.

Why this product?

I am a person with a lot of ideas, I am always working on multiple projects simultaneously, so I understand the domain. In a way, I am scratching my own itch.

It also matches my experience in the last 5 years while being an Innovation Product Owner at METRO SYSTEMS. It is an excellent opportunity to find a way to code some of the learnings I had while supporting hundreds of people to transform their ideas into real products and launch them. I think an innovation management platform will help companies or teams to make their ideas happen faster with higher results. I often see people saying out loud ideas of products or services that they would like to create but remain just ideas—most of the time, there no step further than saying a phrase about them. Having a place where one can submit their ideas, where one can gather support or team members, where there are mentors and sponsorship, where feedback is given is creating more opportunities for anyone to advance their solutions.

I also firmly believe that innovation is driven by innovation. The more you do, the more you will do it. It is thus essential to have a place where you can see what is happening around in your organization. People will get inspired while reading other people’s ideas. Being transparent about what is happening is a big motivator for more people to contribute. And more people participating means more views and in the end, better ideas.

I think this process - of making an idea happen - has greater chances to sparkle real innovation if it is digital-first if an organization uses a web app to empower their innovation and to make it more appealing to anyone in the company. If there is no digital place to submit ideas, they are often shut down by immediate peers or direct managers. This killing of ideas is removing the most innovative ones in the first place. But publishing to a digital space allows a broader audience and thus more changes that an idea will live long enough to at least be validated.

Why now?

This year - 2020 - started not so good. We have an international crisis (the SARS-CoV-2 pandemic), which affects in ways no one can predict our lives. I am sure that it will affect business and personal areas, accelerating some trends, destroying others, and making space for new things to appear.

I am convinced this kind of transformation will be, in general, a painful process. So there will be a great need for solutions to this wide range of problems.

You might ask yourself if it is not too late to start doing this. I think the effects of this year’s pandemic will ripple through 2020 and possibly into 2021.

This is why open-sourcing a platform that helps people speed up finding innovative solutions is probably among the best things I can do to help as many people as possible.

Why open-source?

What is excellent about open-source is that it can be used by anyone, without any concern about privacy or any hidden interest from the creator. Anyone who will want will be able to take the platform, install it, and start helping their colleagues to make their ideas happen.

I genuinely hope the platform will be used by businesses and NGOs alike, as it will be a simple web-based app. I plan to use it myself for my own ideas.

I want to contribute back to the broad Internet community and get in the role of the creator of open-source software. I think it is a moral obligation to give back to the open-source community as much as possible. I am inspired by as many heroes I follow today on Twitter or Github or HackerNews, and I want to help others as they helped me being who I am from a technical perspective.

To make this project available to as many people as possible, the only logical decision is to make it open-source. This will also improve the innovative ability as it will allow more people to contribute with their own ideas on how to make the platform more helpful.

More personal reasons

Better programming skills

For me, this is a great occasion to shape my programming skills. There is no better incentive to expand my programming skills than to have my code open so that anyone can give feedback. I want to become a better programmer, I want my code to be elegant and simple to transmit better my ideas.

Get better at communication

Creating an open-source community means doing a lot of communication. I re-started this blog to improve my communication. Open-sourcing a product implies more communication.

It is about building communities

I like to work together with people working in IT. It was the most significant part of my work in the last 10-15 years. When I was not programming, I helped create all kinds of learning experiences for my colleagues. Open-sourcing IT Connect is an opportunity to create more communities and connect with more people.

Learning something new

Making an open-source application comes means to learn new things, new tools, new frameworks. For example, I plan to finally grow my Javascript skills to pick up the ability to Vue.js production-ready and to get full-on into the last CSS abilities with TailwindCSS.

Let the fun begin!

Momentum

2020-06-19T00:00:00+00:00

When thinking about quality vs. speed, it is essential to acknowledge that only in the short term, these two are somehow incompatible. In the long run, the quality helps a lot with speed and, specifically, with momentum. But it is also the other way around; momentum helps a lot with building default quality. The more I think about this, the more I realize that maybe momentum is the only thing that we should consider when thinking about the product, productivity, and teams.

What is momentum?

I found a couple of article talking about momentum in the productivity context: one, two, three, four. Probably there are many more, but this is what I found on a simple search. While some of them have good recommendations for personal use, I did not find yet one that deeply analyses this from a team perspective.

I propose momentum as one of the essential qualities to watch while thinking about team productivity over the long run.

Defining momentum for team and individuals

Momentum in the real world

In physics momentum is defined as:

Momentum, product of the mass of a particle and its velocity . Momentum is a vector quantity; i.e., it has both magnitude and direction.

Yet, for what I am trying to explain here, I like more this definition from Merriam-Webster:

strength or force gained by motion or by a series of events

Scalars and vectors

Before going into more details, let’s make one difference here between scalars and vector quantity:

A vector has magnitude and direction. Example of vectors in physics: acceleration, momentum
A scalar has the only size. Example of scalars in physics: volume, speed, mass, density

Velocity in physics vs. velocity in agile

Velocity is defined in physics as “how fast and in what direction a point is moving.” Velocity in physics is a vector, thus providing magnitude and direction.

Velocity in Agile is defined as:

the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

In Agile velocity is a scalar. It does not show direction. It is just a magnitude.

One could argue (in Scrum, for example) that the direction is given by the fact that people are working toward building a product increment. I don’t think this holds because people are adding effort associated with completed user stories, but there is no way to understand if that effort is required for a particular user story. So there is no way to assess if the current amount of work done is in a specific direction while in the sprint. Only at the end of the sprint, one can understand if how much from what was done was in the required direction.

Another argument could be that direction is given by early feedback. While this indeed provides an arrow, it is not part of velocity. It is part of some agile processes to guide a team toward a goal with early feedback.

But in practice, one can observe that people count velocity as the total amount of effort spent in a period.

There might be ways to add direction to velocity, but I will try to argue further than focusing on the velocity. It is not a sustainable purpose in the long run, with all the possible corrections for matching the desired outcome.

Momentum is a specific type of vector

A team having momentum is a team that:

keeps moving toward an outcome they desire
it is visible they are going into that direction
can keep this pacing without mental effort - seems effortless to continue.

In our case, momentum is a specific type of vector for productivity as it is not just a measure of where we are now and where we are going, but it is also a measure of the force that will continuously pull us into that direction.

I think you know this feeling of momentum:

it was that time when you said you are “on a roll.”
it was that time when you kept pushing code to production day after day
it was that series of sprints when you delivered the outcome and the customers where happy
it was that period when you had engaging conversations with your customers, and together you were building a great product without the hassle
it was those daily discussions which created the fantastic architecture/technical breakthrough
it was that time when in 5 minutes you finally wrote that function which took previous days hours to write and delete and then move on to write another one and another one

Why momentum is important

The case against agile velocity

As I explained above, velocity in agile implementations is a scalar, it is just a quantity, but this is not the only problem.

The big problem is that velocity is a subjective quantity while trying to appear objective. It does not help inside the team because it cannot be increased or decreased by themselves in any significant way and also cannot be compared with other teams as it is subjective. Change something about the team (structure, organization, technology). This metric will change. You will only see how significant the change is without having anything actionable from this number.

A second argument against measuring speed is that it creates the wrong incentive where any compromise is okay as long as it speeds up development. The wrong here is that people apply this only thinking about the present moment. So it sacrifices quality for speed. And in the future, when your app is bigger with more lines of code and more complex architecture, these compromises - actually technical debt - will act as a break.

There are many hidden forms of velocity

Try not to let yourself tricked by the fact that people use some other metrics. Most of them are a quantity, and most of them are different forms of measuring a kind of length or speed when time is taken into account.

Here are some examples:

Number of stories implemented
Number of merge requests successfully merged
Number of tests passed
Number of bugs fixed (per area, per classification, per severity, per impact)
Number of releases

Divide by a time quantity (like daily, weekly), and you will get a kind of speed.

I am not saying that these metrics are wrong. I am arguing first that they are not very useful when thinking about creating value for customers/users. And more important that most of the time, they can very quickly become the single focus, thus affecting the decision process. I was too many times in meetings and discussions when one of these metrics, which in the beginning was introduced just as a no-judgment plain number, was taken into consideration as the most important thing.

It is happening when times are hard: something happened with the product/in the market, and suddenly people need to look into what happened and how they can improve the current situation. They remember that they were gathering these metrics (number of X) and start looking at them to usually find data to confirm a decision. This is how developers are usually feeling pushed to do more user stories or testers to execute more tests.

The value of momentum

I think momentum is genuinely one of the best metrics to measure when thinking about productivity. True, it is hard to measure. Yet it is what makes the difference between a high-performing team and one that seems busy without producing a valuable outcome. For me, #momentum is precisely why the #agile #manifesto was created. To support teams/individuals to gain momentum and be able to make their creation happen.

How to measure momentum?

Real ways, hard to measure

Here is the most sincere way to measure momentum: ask the team. If you have a good relationship with the team, then you will know if they have momentum.

You can also watch how the team communicates blockers. If the blockers are inside team reach, then the team does not have momentum. If the blockers are outside team reach and they are a lot, then also the team does not have momentum.

You can also watch the team. Look at interactions, communication, communicating, how they are doing progress.

Other possibilities

First: I think momentum is best measured when thinking about a team, not about an individual. Because at the individual level is can be very easy to go into focusing on wrong things (time spent while doing X)

Second: I think there should be different metrics based on the team’s particularities. Some teams need more data and react to that very well. Other teams need more guidance about the outcome than about the quantity of x done.

Third: Measuring momentum works only if the work can be split into small chunks. If the work cannot be split into small chunks, then it is tough to track momentum. In general, it is very hard to measure any outcome because there is a long delay between the team starts working and the moment that an outcome or business objective can be asserted.

It is tough to measure momentum. So bear with me while I try to explain how I think about it.

Blockers for momentum

It is more comfortable to identify blockers for momentum. Here are some examples of blockers:

1. Meetings per day = how many meetings the team has per day. Add an extra weight when the meetings include participants from outside the team. Bigger is worse. I am here defining meeting as being asynchronous meeting where all attendees are required, and they need to be focused from start time to end time.

2. Decision queue = how many work items are waiting for decisions from people outside the team. Bigger is worse here. Having a lot of work items blocked by people outside the time is definitely one of the best ways to not have momentum.

3. The estimated dimension of work items = how long will probably take to implement a work item (requirement, user story, task). Momentum is not working when the progress is defined while taking into account periodicity bigger than days. It seems like splitting things into smaller pieces works wonders. See https://behavioralscientist.org/to-achieve-your-goals-lump-and-slice

4. Pressure to achieve quantities Whenever a team is pressured to achieve a number, they will focus on achieving the number, which creates a kind of mental pressure which kills the desired part of the momentum. One cannot have momentum while doing something they don’t agree with, or they find useless. Want to hear what most of developers or testers think when asked to count items of their work? They DO NOT LIKE this and usually are frustrated by this requirement.

Hints about momentum

Then let’s thing about signs that you can see in your team, and they hint that maybe your team has momentum:

The flow of ideas = while talking about a specific issue, implementation, architecture, bug work team members are building upon each other ideas.
Focus on delivering = you can see this in many moments when a discussion tends to get too philosophical or too long that the team will correct themselves and focus on “What should we do to deliver this feature?”
Quality is built-in = this is when you see that the team does not need guidance or reminders about quality. They are doing progress and embed quality within.
Delegating anything extra for the future = the team is not rejecting changes or extra things because they are very focused on what they are doing, so no energy can be spent on fighting change. They are just delegating extra things for the future.
High interest in defining work items = While discussing next work items team gives valuable feedback about how to transform it so that it is implemented with good quality and customer satisfaction

Possible there are many many more signs than these. Again teams can differ a lot on how they “look like” when they are high-performing.

Thanks to Ciprian Hodorogea for reading drafts of this and giving me valuable feedback.

Open Source Policy - Examples and best practices

2020-06-06T00:00:00+00:00

I am working with METRO SYSTEMS to open-source one of the applications we created for our innovation projects. Part of this process I started looking at what open source policies different companies have, and I am sharing my findings here.

This article is not a comprehensive review of open-source policies. I picked up companies based on a list from the TODO Group. This is a short review of some open-source policies where companies are encouraging their employees to open source their work or contribute to open source projects.

Here is what you will find in this article:

A summary of what to include in an open source policy
Buffer Open Source Policy
Open Source at Gitlab
Joyent - open source policy
Google Open Source Policy
How Dropbox uses CLA
Why Gitlab transitioned from CLA to DCO
More resources to read

Summary

It seems like a well-done open-source policy should address at least 3 areas:

Creating a new open-source software
Using open-source software in a proprietary software
Contributing to open-source as an employee of a company

When discussing creating open-source software (or releasing code as open-source) some points to take into consideration are:

What type of licenses to use?
Where will the code be released?
Usually, there is a flow of steps to be checked before releasing:
- Reviews (security, privacy)
- Legal approvals
- Communication
How to structure the code
- The best option here is to create a boilerplate/template for a project including Code of Conduct, Governance, Readme and How to contribute
A kind of support group/person who can guide and answer questions a developer has regarding their open source project
Who owns the IP for the created software

When talking about using open-source software inside projects, some points to take into consideration are:

What kind of licenses does the open-source have?
- Implications of using permissive vs. copyleft licenses for the copyright of the current projects
- Liability
Requirements implied by the open-source license
Management of third-party software (upgrade, patching, bug fixing)
Security reviews

When talking about contributing to open-source, some essential points to take into consideration are:

What kind of license the open-source project has?
How does the contribution involve the current company?
Attribution - make it clear who is the contributor to the employee of the company?
Who owns the IP of the contribution if there is any?

It is also essential to address three more things about creating an open-source:

Community - how would you take care of a community of users or contributors. Nobody is saying you should have a strategy for this, but it sure helps if you care about your community and help others use your creation
Tools - It is easier to have guidelines about what kind of tools to use when creating open-source. I don’t think this list should be prescriptive, but it should be a suggestion.
Public Common Repository - usually, companies have not only a handler on Github or Gitlab or any other version control repository but also a public page on their websites (sometimes a subdomain like opensource.companywebsite).

It is important to take into consideration that you are writing this policy as a guide for an employee of your company. In this case, then the policy can be written from the perspective of the developer and should address possible questions, blockages the individual has. It could be like answering “How to” questions.

The length of the policy could influence how easy people start creating or contributing to open source. A lengthy policy might be putting off people to start open source because it makes the process look hard. A concise one might not address big questions and thus creating uncertainty.

Below you can find simple reviews of some examples of open source policies. They are from companies part of TODO Group (Talk Openly, Develop Openly).

Example of open source policies from different companies

Buffer Open Source Policy

About Buffer

From their website https://buffer.com:

We’re a fully distributed team of 85 people living and working in 15 countries around the world. And we’re working to build the best products to help our customers build their brands and grow their businesses on social media.

The list of their open-source projects is https://buffer.com/open-source, the open-source policy is https://open.buffer.com/guide-open-source.

Talking about real questions or dilemmas

Possible reasons why employees are not thinking about open sourcing are around the following lines of thoughts:

I wasn’t sure if I could open-source that.
I wasn’t sure if it was even safe to open source.
I wasn’t clear if it was okay to spend time doing that.
I don’t know what our “process” is for open-sourcing code, do we even have one?

More effort should be made to educate colleagues on how to open source their code.

What should be in an open-source policy - FAQ

Buffer open source policy is mostly a list of FAQ containing answers to the following questions (click here to see it as an image):

What license do we release software under?
What can I open source?
What should I open source?
Can I spend time on open source? Is it part of our cycles? Can I spend time contributing back to other open-source projects?
How do I open source – what’s it all look like end to end?
- Check if it is secure and does not contain sensitive data
- Notice the team that you want to open source
- Add Readme
- Make the repo on Github
- Celebrate
- Add the project to the open-source page
- Promote it
Any general tips?

Open Source at Gitlab

Gitlab values and open-source

Gitlab is defining itself as a company dedicated to open source and encourage its employees to give back to the community, thus living their Collaboration and Transparency values.

Their public open source policy can be found in thier Handbook at https://about.gitlab.com/handbook/engineering/open-source.

Open sourcing a project

What should be taken into consideration when open sourcing a project:

Which license to use
Where to publish
Any approvals needed?
Readme:
- a. Code of conduct
- b. License
- c. How to contribute

Contributing to open source

Contributing to a third party project tries to address:

Contributor license agreement
Contributing to a project on Gitlab where they invite their employees to fork and then follow the project’s Merge Request process
Contributing to a project on Github where they invite their employees to fork and then follow the project’s Pull Request process

Using open source libraries

What are the acceptable licenses:

What are unacceptable licenses (which require legal approval for the use):

They also provide an email where an employee could write to ask about the license they want to use for their project or about the license of a component/project they want to use in their own work. There is two type of approvals: case by case or for universal use.

Gitlab also invites their employees not to use forked code but to contribute changes to upstream, also providing reasons for why this is a good decision: it might become hard to rebase the branch and also there might be other libraries from the same project depending on the original version.

Proprietary Information and Assignment Agreement

It is important to observe that on this page, Gitlab has a link to a PIAA Agreements section part of a section about how to create a contract for a new employee. There they explain that:

Our PIAA does not grant GitLab any rights in any creations that you may make that are not related to GitLab’s business or the work you do for GitLab. That is, you are free to develop those creations without requesting approval in advance from GitLab.

I think this is a very good thing because this addresses questions related to side projects employees do and want to open source.

Joyent open source policy

About Joyent

From their website https://www.joyent.com:

Since our inception, Joyent has lived on the leading edge of technical innovation. Our team pioneered public cloud computing (and hybrid cloud), nurtured and grew Node.js into a de facto standard for web, mobile and IoT architectures, and was among the first to embrace and industrialize containers, compute-centric object storage, and what is now coming to be known as serverless computing.

You can read their Open Source Policy at https://github.com/joyent/rfd/blob/master/rfd/0164/README.md and browse their Github Repositories at https://github.com/joyent.

Joyent open-sourced their entire software stack in 2014.

Open Source Counsel Office

First, they talk about creating a role named, Open Source Counsel Office (OSCO) that serves a central point for “consultation and approval with respect to open source policy”.

Licenses

Approved list of licenses that can be used without consulting OSCO:

Mozilla Public License, 1.0, 1.1 and 2.0 variants
MIT License
Berkeley Software Distribution (BSD), 3-clause, 2-clause, and 0-clause variants
Apache License, 1.0, 1.1 and 2.0 variants
Common Development and Distribution License (CDDL)
PostgreSQL License
Python Software Foundation License
Public Domain
Artistic License
zlib/libpng license
PHP License
ICU License
Eclipse Public License

Then they have a list of licenses that can be used for internal use but cannot be used for external use without consulting OSCO:

GNU Public License (GPL), v2 and v3
Lesser GNU Public License (LGPL)

And a list of licenses that can be used for internal-only with approval:

Affero General Public License (AGPL)
Server Side Public License (SSPL)
Confluent Community License
Redis Source Available License
Any license bearing a Commons Clause addendum

How to contribute

Further, their policy talks about how actively pushing changes upstream and setting some guidelines for contribution:

Personal attribution - where they make very clear that attribution should always be of the engineer who created the code
Copyright where they talk about how to write the copyright depending on the license and invite their employees to use company email addresses
Copyright notice where they indicate that they prefer to have the license included in the header of every file
Contributing source from third parties: where the guideline is to work with OSCO
De minimis change where they define that minimize changes does not need to have a copyright notice
Conduct which is referring responsibility to employees to report to OSCO or HR any misconduct
In case there is a need for Contributor License agreement that should be addressed with OSCO

Creating an open-source

The last part of this document outlines open-source creation:

A place for publishing repositories: Github Joyent account
License: the preferred License is Mozilla Public License Version 2.0
Security: inviting to careful inspection to make sure no secrets are divulged
They invite not to use Contributor license agreements as this might be an impediment to contributions
There is no formal code of conduct adopted, but they recommend in case it is needed (or advised by OSCO) to use a variant based on Contributor Covenant.

Google Open Source Policy

About Open-Source at Google

Google has a website dedicated for open-source: https://opensource.google/docs, where you can find their policy.

Google has so far one of the most comprehensive documented open source policies: it addresses a lot of knowhow about how to create an open-source project (or release code), how to use open-source, and what Google is doing to support open source communities.

They are part of the TODO Group.

You should go ahead and just read it. It is too big to summarise it. I will highlight some interesting things I found there that are worth considering when trying to create an open-source policy inside your company.

Releasing code as open-source

Google has a 5 step process:

Prepare (there is a Github repo with boilerplate for this https://github.com/google/new-project)
Stage
Get approval
Release
Patching

There is also a good section talking about differences between work-related project and personal project and a lot of good questions like:

I want to update a repository that’s already gone through the launch process. Do I have to do it again?
Do I really have to get approval from my manager? This is just a tiny project! What gives?
What about projects from before I worked at Google?
This process is a pain, can you automate any of it?
What happens to my personal projects after I leave Google?

They also talk about Github at Google and where the repositories and how to get access to them.

Contributing to open-source

Google encourages contributing to open source projects and, when possible, to use their Google.com email and Google LLC as project author. There is a list of situations when there is no need for review. They are a combination of what kind of license those projects have combined with requirements for CLA and a filtering list provided by Google.

Also, there is a clear list of forbidden patches for any project that has any of the following licenses:

No License
WTFPL
AGPL (except those with special exceptions)
Public domain dedications (including CC0 and Unlicense). Exceptions: United States government projects; BSD0.
CC BY-NC-*
Hippocratic License
Private repositories (unless under a written agreement between Google and a third party)

Personal projects

Here Google is very direct (https://opensource.google/docs/iarc/):

As part of your employment agreement, Google most likely owns the intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.

Participating to Hackathons

Here Google addresses multiple interesting aspects like:

Subjects which are off-limits
Terms of the hackathon
What happens when an employee wants to be a judge or organizer
Lists of approved and not approved coding sides
Bug bounty

In general, employees should not participate in hackathons where there is a request for any assignment of intellectual property rights. There are also there two templates of terms for the short-form and long-form hackathon.

Also, an important topic addresses are about moving a project into an open-source foundation.

Using Open Source

One clear statement here is that AGPL is not allowed to be used at Google. Google also requires to add all third_party code into a folder third_party where all non-Google code and data should live. I think this is a sane approach because it makes it easy to know what is the code created inside the company and what code is imported from outside, thus making review strategies more clear and easy to implement.

I also find very well written and good explanations about what to consider when someone wants to use code from outside Google. One of the clearest recommendations is to look for licenses of open-source code where there is no ambiguity about the following three rights:

“the right to make copies (also known as reproduction)”
“the right to modify and adapt (also known as the right to do derivative works)”
“the right to distribute the original and modifications.”

Open Source Initiative has a list of OSI-approved licenses which give clear rights to users: https://opensource.org/licenses.

Growing an open-source ecosystem

Google has a strong involvement in open-source. So in their policy is a big chapter about current initiatives they have to support open sources. In case you want to support open-source inside and outside your company, you should read this. It will give you good ideas about what to do and how.

Other important things to take into consideration

How Dropbox uses CLA

Dropbox requires individuals or companies to agree to their Dropbox Contributor License Agreements.

Here is the example for the Individual CLA: https://opensource.dropbox.com Here is the example for Company CLA: https://opensource.dropbox.com/cla/company/.

Why Gitlab transitioned from CLA to DCO

Gitlab switched from Contributor License Agreement to Developer’s Certificate of Origin to give developers greater flexibility and portability for their contributions. Read here their announcement about this transition here: https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-dco-license. They also share there why this decision was made.

Resources

A list of links/resources I think are important to read when you are thinking to create an open-source policy:

A list of open-source policies from companies part of TODO Group - https://github.com/todogroup/policies
Guides and studies from TODO Group - https://todogroup.org/guides
An article with a very good review of common open-source software licenses and great comparisons between them. It also has a lot of examples of software using various licenses - https://medium.com/@moqod_development/understanding-open-source-and-free-software-licensing-c0fa600106c9
A good document about things to take into consideration when starting an open-source program: https://www.linuxfoundation.org/resources/open-source-guides/creating-an-open-source-program
WIRED Guide about Open Source, which is not exactly about how to create an open-source policy but very informative about open source in general: https://www.wired.com/story/wired-guide-open-source-software
A good document about what to take into consideration when creating an open-source program in an enterprise company: https://www.ibrahimatlinux.com/uploads/6/3/9/7/6397792/compliancepractices_ebook_final.pdf
A summary of Gartner’s report, Technology Insight for Software Composition Analysis: https://blog.sonatype.com/gartner-the-crucial-role-of-oss-license-compliance