Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update open-source.md #58

Merged
merged 1 commit into from
Jun 23, 2019
Merged

Update open-source.md #58

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions content/2.mvp-for-gen-z-dev/content/open-source.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,9 +42,9 @@ Open Source is an idea created 20 years ago (in a meeting on February 3rd, 1998)

This lead to the creation of the [Open Source Initiative](https://opensource.org/) who approves multiple community created [Open Source Licenses](https://en.wikipedia.org/wiki/Open-source_license).

One of the challenges that the Open Source license tried to address, was the more aggressive and viral nature of the [GPL](https://en.wikipedia.org/wiki/GNU_General_Public_License) (General Public License). GPL requires that the developer's release under the same GPL license, all code that uses or modifies the original GPL code.
One of the challenges that the Open Source license tried to address, was the more aggressive and viral nature of the [GPL](https://en.wikipedia.org/wiki/GNU_General_Public_License) (General Public License). GPL requires that the developers release all code that uses or modifies the original GPL code, under the same GPL license.

Basically, once you add some GPL code to you app, you also need to release that app under GPL. In practice this proved to be to restrictive to the adoption of lots of libraries and applications. Even worse, that limitation went against what most Open Source creators want, which is the wide and seamless use of their code
Basically, once you add some GPL code to your app, you also need to release that app under GPL. In practice this proved to be to restrictive to the adoption of lots of libraries and applications. Even worse, that limitation went against what most Open Source creators want, which is the wide and seamless use of their code

Here is an definition of [Open Source software](https://en.wikipedia.org/wiki/Open-source_software) from Wikipedia:

Expand All @@ -58,13 +58,13 @@ At least when code is open and available, we have the ability to check what is g

Note that this doesn't mean that Open Source software is auto-magically secure just by being Open Source (we still need an ecosystem that rewards or pays for security reviews and secure development practices)

Another major evolution in the history of open source was its effect on companies like Google and Facebook, where Open Source applications and code where a major contributor to their scalability and success.
Another major evolution in the history of open source was its effect on companies like Google and Facebook, where Open Source applications and code were a major contributor to their scalability and success.

### Open source business models

It is amazing to see the change in the industry and thinking around Open Source. In early days of Open Source, me and many others were called 'communists', just by defending that code and ideas should be shared and made free.

These days there are tons of business models that have been proven to work on top of an Open Source models. For example here are [12 examples](http://www.openhealthnews.com/articles/2012/open-source-business-models-more-depth-view) :
These days there are tons of business models that have been proven to work on top of an Open Source model. For example here are [12 examples](http://www.openhealthnews.com/articles/2012/open-source-business-models-more-depth-view) :

- Software Support Business Model, Software Services Business Model, Software as a Service (SaaS) Model
- AdWare Business Model
Expand All @@ -74,9 +74,9 @@ These days there are tons of business models that have been proven to work on to
- Non-Profit Business Models
- Defensive Business Model/Strategy

For Open Source to scale and be sustainable in the long term, it has to be supported by an viable economic model (one where there is a positive feedback loop of value for its creators and maintainers). These examples of Open Source business models (and the successful companies/services that use them) are behind a significant number of the open source contributions that we see today. Of course that there are other forms of receiving value form contributing to Open Source, namely learning something new, contributor brand enhancement or even just purely the joy we get from sharing knowledge.
For Open Source to scale and be sustainable in the long term, it has to be supported by a viable economic model (one where there is a positive feedback loop of value for its creators and maintainers). These examples of Open Source business models (and the successful companies/services that use them) are behind a significant number of the open source contributions that we see today. Of course that there are other forms of receiving value form contributing to Open Source, namely learning something new, contributor brand enhancement or even just purely the joy we get from sharing knowledge.

In a weird way, the Open Source revolution has happened, most of the key battles have been won, but a large number of Gen Z are not aware of it (and are not poised to benefit from these business models and strategies). The danger is that there is still a lot of to do in the Open Source world and we need the Gen Z to be a big driver and innovator.
In a weird way, the Open Source revolution has happened, most of the key battles have been won, but a large number of Gen Z are not aware of it (and are not poised to benefit from these business models and strategies). The danger is that there is still a lot to do in the Open Source world and we need the Gen Z to be a big driver and innovator.



Expand Down Expand Up @@ -106,20 +106,20 @@ And then, after you Open Sourced your app or code, what will happen next is: Not

The reality is that it is very hard to create a community around an open source project. Most open source projects have been created and are maintained by a very small number of developers.

What you will have done by adding the license file to your code, is to create future opportunities for that code and sent a strong message about your agenda (i.e. you are not going to lock in the future the users that are using your current code today):
What you will have done by adding the license file to your code, is to create future opportunities for that code and send a strong message about your agenda (i.e. you are not going to lock in the future the users that are using your current code today):

- you are allowing somebody, which could be you, in the future to use your code
- you are also protecting your research so that if you move companies you can still use that code. There is nothing worse for a programmer than to having to rewrite something that was working ok, especially when it is a framework that supports a particular workflow.

I believe that we have moral imperative to share our ideas. I don't want to be the one that close ideas and don't let other benefit and learn from them. These days everything you do is a variation of what somebody has done before (i.e. you are adding an incremental change), after all you are sitting in shoulders of the giants that come before you.
I believe that we have moral imperative to share our ideas. I don't want to be the one that shuts down ideas and don't let others benefit and learn from them. These days, everything you do is a variation of what somebody has done before (i.e. you are adding an incremental change), after all you are sitting in shoulders of the giants that come before you.

### Open Source as a way for companies to collaborate and find talent

There have been big success stories of companies collaborating internally externally (i.e. internal collaboration between different teams via open source code)

Ironically, although most developers have internal access to all code, the number of cross-team pull requests is very low. Publishing the same code under an Open Source license will help a lot in its internal reach, usage and collaboration.

This also means that by allowing others to use their code, cleaver companies are creating a great way to find programmers to hire, or companies to buy. As a developer you should take advantage of this and be an active contributor on the open source projects of the companies you want to work for. This is a great way to meet the key developers from those organizations, who may turn out to be key decision makers in your job application.
This also means that by allowing others to use their code, clever companies are creating a great way to find programmers to hire, or companies to buy. As a developer you should take advantage of this and be an active contributor on the open source projects of the companies you want to work for. This is a great way to meet the key developers from those organizations, who may turn out to be key decision makers in your job application.

### Open Source as a way to define the agenda

Expand All @@ -143,14 +143,14 @@ Here are some of the best ones:
- If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
- To solve an interesting problem, start by finding a problem that is interesting to you.

In the book Eric compares the creation of proprietary applications to an Cathedral and the development of open source to an Bazaar.
In the book, Eric compares the creation of proprietary applications to a Cathedral and the development of open source to an Bazaar.

In Eric's view, Cathedrals are: massive and expensive undertakings, take ages to create, don't have much innovation (apart from a couple major areas), have all sorts of top-down management problems, are super expensive, don't usually work very well (for the intended purposes) and don't usually turn up the way they were originally designed.

On the other hand the Bazaars behave like living organisms, always innovating and with always somebody somewhere trying something new.
On the other hand, the Bazaars behave like living organisms, always innovating and with always somebody somewhere trying something new.

I actually prefer to see the beauty in both Cathedrals and Bazaars. Each has it magic and situations when they are exactly what is required.
I actually prefer to see the beauty in both Cathedrals and Bazaars. Each has its magic and situations where they are exactly what is required.

This analogy is interesting because with the latest super-effective ways of developing software we can now build amazing cathedrals out of the Bazaar. Made possible by continuous refactoring and constant deployment of small/medium changes (which is what we get from effective TDD and DevOps environments). We create Cathedrals by continuously refactoring and improving what had started as a Bazaar.
This analogy is interesting because with the latest super-effective ways of developing software we can now build amazing cathedrals out of the Bazaar. Made possible by continuous refactoring and constant deployment of small/medium changes (which is what we get from effective test driven development (TDD) and DevOps environments). We create Cathedrals by continuously refactoring and improving what had started as a Bazaar.

This goes to the heart of what I have noticed in effective development environments with crazy-high code coverage. The more code and capabilities are added to the application, the faster changes can be made. The opposite of what happens in a lot of projects where the higher the quantity of code, the slower everything becomes.