Anyone Can Look Inside!

When we talk about 'open source,' we mean the free availability of the software involved. We assume that anyone can freely access, copy, share, and modify the OSS, including every line of its source code. The source code, which constitutes the software and to which many users do not pay attention, is what programmers or developers manipulate to generate changes in the way the software works. Unlike OSS, we have 'proprietary software' or 'closed source software,' which doesn’t have its full source code available to the public. Its modification or redistribution may be prohibited or highly restricted.

The free software movement began in the eighties through Richard Stallman, a programmer at MIT. It emerged as a response to the limitations (for example, in cooperation) generated by proprietary software. As shared in Statskontoret, Stallman took the cooking as an example and raised questions like: "How would we experience the world around us if recipes were not freely available or free to change and modify?" The fact is that some have been interested in just sharing their final dishes and keeping their recipes secret.

Now it’s important to get something straight, based on a post by Kelly & Van De Mark: 'free and open source software' doesn’t necessarily mean that the software is free of price. This is an allusion to the freedom of use of the software and the code. However, "most free open source software is indeed free in price." Therefore, it is often requested that the copyright be attributed to the creator(s) and that OSS quality be preserved when distributed.

In fact, many organizations have achieved success selling consulting, support, and training services related to the use of their OSS. Some companies have chosen to sell exemptions to the terms of their licenses. In other cases, some products recommend other complementary products or services. Other times, OSS creators rely only on donations.

On the legal side, licenses are not only provided for proprietary software; they also apply to OSS. The rights to examine, copy, alter, and distribute are stipulated in those licenses. Licenses determine the ways in which individuals inspect, modify, and distribute software and its code. For example, 'copyleft' licenses stipulate that if someone releases a modified open source program, he must also deliver the corresponding source code. That is, the terms of distribution or other requirements for all copies or alterations of all versions must be maintained. On the other hand, as Moffatt says: "If a program is free but not copylefted, some copies or modified versions may not be free at all."

On the security side, we must be clear that vulnerabilities and gaps are present in both open and closed source software. According to a post by Maryna & Vlad, regarding security, many times when we pay for software, we are left only with the confidence in the seller. However, when we have many eyes watching an OSS and the code, flaws, bugs, errors, or omissions in the program can be more easily detected and quickly fixed. Furthermore, the security of some companies using open source, without teams of cybersecurity experts or at least support communities, may be at risk from malicious hackers who can take advantage of it.

Many organizations, regardless of their size and field of action, are recommended to include OSS in their strategies. For a company using OSS, an online community discussing its software can be a huge benefit. As Bromhead pointed out: "The output tends to be extremely robust, tried, and tested code." Besides, organizations that make good use of open source will be able to discover work dynamics that are more oriented towards collaboration, creativity, and innovation.

Collaboration is helping each other to move a project forward. Blogs and forums serve as a means to share and exchange knowledge or ideas. In addition to the fact that codes and products are continually being reviewed and optimized, each participant and collaborator can also receive constructive criticism and feedback. Customizations made by sometimes thousands of hands on the job can lead to improvements, either by adding features or repairing others. Also, new apps can be developed that are more efficient, more complex, and better suited to specific needs and preferences. Additionally, the practices and results of top coders in one field or another become, through open source, valuable sources of learning and skill enhancement for new or experienced developers.

As far as creativity and innovation are concerned: we must not reinvent what others have already invented. What already exists is used to give rise to the new. As Whitehurst suggests, "innovation occurs only when people feel a certain freedom to manipulate, experiment, and tinker." Creative youth can be easily attracted through a business model that is separate from the traditional. "This culture is strikingly different from the secretive, hierarchical, management-driven cultures of most companies today" (Oram & Bhorat). Great talents can then become part of a company they worked with on an OSS and contribute to other projects.

The accessibility of the code is a valuable strategy to avoid giving the impression that something is being hidden. Then the concept of transparency appears, being a fundamental principle in open source. The one that Bryant Son, from Red Hat, recently pointed out as "critical to making any project successful." Transparency involves sharing as much information as possible with the members of the company and all users and collaborators. Being able to report problems, errors, and methods of solution is a primary characteristic of a transparent community, united in favor of security and technological and social advancement.

Following DB Hurley, transparency is not just about allowing access to code, products, and services. "It is a commitment to total clarity, in business practice, structure, finance, and design." A transparent company does not give the impression that there is some mystery behind what the code is doing. It achieves greater trust from customers and communities, exemplifying an immaculate business practice.

The code created and used by Fluid Attacks is public, and we believe that strengthens us and reflects transparency. In the words of Rafael Alvarez, our CTO: "Public repositories are a bet on transparency that all actors should make in the long term." Take a look at our repositories following this link: gitlab.com/fluidattacks

Do you have any questions or ideas to share? Don’t forget to contact us!