The Open Source Community- The Great Spontaneous Distributed Collective Effort

How to use complete strangers for your own benefit while making their own life better and even contributing to humanity?

Vitali Zaidman
Welldone Software
Published in
5 min readJul 25, 2018


“What should I open source?” I often hear. “Well, you better ask yourself, what should you NOT open source”.

This is a weird answer for many. After all, you open a business; you invest a lot of time, money, and soul into the development of your product. Why would you open it for the general public? Why would you give them the privilege of enjoying your efforts for free?

On the other radical side of the argument you can find the “open source enthusiasts” who are ready to die for the community; “I have a responsibility for these people. This is my part in this world.”

I was very skeptical of both sides, but this topic really confused me until I read some articles about the topic. For example this brilliant one:
I thought I understood Open Source. I was wrong by Lorenzo Sciandra where you can find the following quotes:

“Hey, look, I did this — if you want to use it too, here’s how. I did it in a way that would fit my needs, but use it as you like.”

“If you use an open source project, you become one of its developers. Act that way.”

This helped me realize what a perfect software should usually look like in my vision:

The business logic- roughly speaking about 30–50% of your application should usually be private. This part contains your core business logic. It’s the part that makes your application “different from other applications”. There’s actually a good argument to scramble this part of the application with tools like Jscrambler to make it difficult to reverse engineer.

The generic part- The frameworks, tools, utilities, helpers, and what people usually miss, ideas - the parts of your application that can potentially be used by many different developers - these should probably be open source.

It’s not only code, by the way. Just look at Netflix Technology Blog culture paper, or this one from PayPal Engineering. It’s like open sourcing your company’s principles declaration.

So Why Would You Open Source These?

Open source these so other people will help you test, debug, and sometimes even fix or improve these generic parts of the application.

Look at Facebook, for example. Today they have developed React under the MIT license, which is the standard open source license. It was not obvious to them at first. They had some kind of patents restrictions on their original license. But later they decided to make it just MIT, or roughly speaking, they made it completely opened source so more people could use it.

Why You Shouldn’t be Afraid of People “Stealing” Your Ideas and Competition in This Area

Because the argument is not that it will not happen, but that you should want it to happen to a certain part of your project - your generic tools and ideas.

If someone “steals” your code and keep it private, this code will quickly fade into the fast progressing past of “The Great Spontaneous Distributed Collective Effort”.

Who cares?

If they “steal” it and make it open source- you still benefit in one of the following ways:

  • You get a new approach to the same problem that you can use or even just notice in your approach.
  • You migrate to their way because you understand that it’s superior.
  • You clone it and open a new version of your solution.

But That’s Not What Usually Happens

Usually, your code will be just “out there”. Sometimes, someone, will open a bug or ask a question. Sometimes, someone will fix something or add a feature to it. Most of the time it’s just there.

But It’s a win win situation for you because when someone opens a bug or comes up with an idea- decide what’s best for you:

  • Fix/Improve it.
  • Explain how to fix or improve it to the person who opened the issue or anyone who will see it in the future and decide to implement it.
  • Acknowledge the new idea and information and ignore the whole thing.

It’s your repository, your code, your time, your effort, and finally - your decision.

Open Sourced Ideas - The Next Step In Utilizing Open Source

Had a great meeting with your other five genius co workers? Are you full of ideas and excited about how much you have learned and innovated?

For me, these parts of the software architecture industry are the most inspiring and fulfilling- I really like thinking about and building something complex together with smart and ambitious people.

But why won’t you also take the advice of some other geniuses who struggled, or are willing to struggle theoretically with the same issue?

In his new book, The Square and the Tower: Networks and Power, from the Freemasons to Facebook, Niall Ferguson shows how the enlightenment network of the 18th Century came to life.

Brilliant thinkers like Voltaire were publishing books for an ever cheaper price, meaning that people from different social backgrounds could afford to buy and comment on his books and ideas by mail. Recent research shows that Voltaire had more than 1,400 correspondents.

Pen pals like these helped the enlightenment network shape people’s ideas, opinions and ideologies around the world to the point where revolutions throughout the world were inevitable.

Today you can achieve the same 10 times easier, with a 1,000 times bigger exposure - it’s time to utilize it.

There must be at least one person in the whole company who can put this idea nicely in a blog post to summarize, organize and publish your ideas to discuss them with the awesome community we are part of.

Two years ago I had to decide what testing tools to use in our project, I undertook a few days researching about the available tools and decided to try and see what would happen if I wrote about it and listened to the community’s opinion about it.

Today, if you search for “JavaScript Testing” in Google my article “An Overview of JavaScript Testing in 2018” is probably the first result. I not only presented an above-average summary about the topic to my managers, I also got to see what I missed in this field, where I was wrong and even found myself with new ideas in completely different fields.

And What if Someone Writes “An Overview of JavaScript Testing in 2019”?

First of all I’ll clap my hands for their hard work. 👏👏👏👏

It’s true that I wrote the 2017 and 2018 articles, but I’m neither entitled to, nor have a responsibility to write the 2019 edition.

I’ll look at it and decide whether I have anything to add and if I should write a similar article, or if I can just use their article as a point of reference for my future decisions.

Happy collective creating, everybody :)