Zen of Open Source
By: Matteo Guadrini
Tags: Linux, Apache, Python, Gnu, Open Source

When can a project be defined as open-source? When, as the word says, you open the source code and make it available to other people.

Of course, this is the first concept behind the open-source philosophy. But there is more.

Open source license

To make a project open-source first, you need to release it with a certain license. In fact, there are a lot of them. They all share the main philosophy, but differ from each other in small points. Here are some examples:

Apache License 2.0 (Apache-2.0)

3-clause Berkeley Software Distribution (BSD) license (BSD-3-Clause)

2-clause Berkeley Software Distribution (BSD) license (BSD-2-Clause)

GNU Lesser General Public License (LGPL)

MIT license (MIT)

But which one to choose?

Choose license

First, you need to understand who your project is for. For example, do you want everyone to be able to take a cue from your project and redistribute an improved version under a different name? Then you need an MIT license. Do you want your project to be shared with others and others to contribute directly to your project? Then you will need a GPL license (v2/v3). If, on the other hand, your goal is to simply work in a team, then you will choose an Apache license.

There are many types of licenses and you can create your own. A good reference point to understand what to choose is choosealicense.com

What else?

If it seems all over and done with, well you’re wrong. You’ve made your project open-source via an open license, and that’s a good thing and right, but there’s more to it.

In 1998, some people like Linus Torvalds (author of the Linux kernel), Tim O’Reilly (founder and head of O’reilly Media), Bruce Perens (co-founder of the GNU / Debian project) and Eric S. Raymond (free blogger) coined the term open-source.

As I said before, open-source is a philosophy, a thought, something abstract applicable to something real. This is an excerpt from the Open Source Definition below:

Free redistribution. The license cannot prevent any party from selling or leasing the software. Anyone must be able to make as many copies as he wants, sell or give them away, and he doesn’t have to pay anyone to do that. Source code. The program must include the source code. Deliberately obfuscated code is not allowed. This is because the source code is needed to modify or repair a program. Derivative works. The license must allow modifications and derivative works and must allow their distribution under the same terms as the license of the original software, as the software is of little use if it cannot be modified for maintenance, for example for the correction of errors or porting. on other operating systems. Integrity of the author’s source code. The license may prohibit the source code from being distributed in modified form only if the license permits the distribution of “patch files” with the source code for the purpose of improving the program at the time of construction. No discrimination against individuals or groups. The license must be applicable to all, without any discrimination however noble the objective of the discrimination may be. For example, the license of use cannot be denied even to police forces of dictatorial regimes. No discrimination of sectors. Similarly to the previous condition, this prevents licensing of use in certain sectors from being denied, however deplorable these may be. Therefore, the use of such software to produce chemical weapons or other instruments of mass destruction cannot be prevented. License Distribution. The rights to the program must apply to everyone to whom the program is redistributed, without the need to run an additional license. The license does not have to be specific to a product. The rights to a program must not depend on the program being part of a particular software distribution. The license must not contaminate other software. The license must not place restrictions on other software that is distributed along with the licensed one. The license must be technologically neutral. No terms of the license need to be proclaimed on any single technology or interface style.

From this excerpt it is clear that everything concerning the freedom of oneself and of the others on something that is created (a software, but it can also be a project of a very complicated origami on paper), no longer has an individual property, designed on the single individual, but reflects the will of many people, without considering irrelevant human aspects, such as sex, religion, sexual orientation, economic prosperity and much more. When you decide to open source your own project, you’re not just sharing something, you’re creating a piece of the future for all of humanity.

The Zen

I am an open-source developer who develops his projects and thoughts in Python, a programming language that puts simplicity first and versatility second.

With every open source project I start, I reread this code:

>>> import this

The Zen of Python, by Tim Peters Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea-- let's do more of those!

>>>

This not only helps me to write a beautiful and readable code (for me and for others, since it will have to be open-source), but consistent with a philosophy, that of the Python Software Foundation.

From that list of (apparently random) advice and words, there is indeed an ethics; here, I have created one regarding the open-source philosophy.

Conclusion

The Zen of Open Source, by Matteo Guadrini Inclusive is better than exclusive

Abstract is better than specific

For many it is better than for himself

Modular is better than monolithic

Think twice about implementation

Explain well the reasons for your project

Be as specific as possible

Think like a child and write like an adult

Start with a simple project - if it's complex to explain, it's a bad idea

Life is one, don't be afraid to express yourself or make mistakes - a community is ready to correct you

Never say it's impossible - there's always a way

What you thought is not the only way - try them all

Be free to choose

I always start a project thinking about these phrases.