The Gist The Open Source process is full of ups and downs, but what makes a project a success can be determined by the structure of the team. This includes their approach at the problem, the project licence, their manner of collaboration and the distributions of roles and responsibilities of the project.
The Good 3 things that I enjoyed
"scratch an itch" as summarized in the following lines:
But what they love even more is a solution to a tangible problem that they face in their immediate environment. This is the“itch” that the developer feels, and scratching it is a reliable source of voluntary behavior.
It's hard getting on board a project but when one feels deeply connect they are more likely to spend their time working to resolve the problem.
"document what you do."
Source code is readable, but that does not mean it is easy to read.
Documentations on an open source project is a gem to contributors. It makes life easier when attempting to read the project and understanding the code. Often developers would have great ideas and implement them only to realize that the vast public has a hard time understanding their reasoning. But documentations facilitate this.
"release early and release often"
the evolutionary stability of open source software is something that needs to be explained at the macro level
Early releases allow others to test the code in time to find bugs and in turn submit a patch occasionally through pull requests while the project is moving along. Releases that wait much longer however tend to accumulate a lot of bug which could have been detected by the community had they been released much earlier. This is a big plus I think to open source projects and is an area in which I am working to get better at because I see it as a very critical aspect to any open source project. Following through with this, will most certainly create a healthy project and community.
The Bad 3 unhealthy things for open source projects from the chapter
"minimize how many times you have to reinvent the wheel" although I agree greatly with this point, I'd also like to point out that there are many broken wheels that need to be remade much stronger than initially made. In an area where the wheels do not need reivinting and or do not have any need for it, it makes perfect sense not to, but an open source project that seeks to "scratch the itch" would occasionally need to reinvent the wheel.
"the Internet just as readily enables conflict" the internet is great for collaboration but it can easily introduce harm to projects. Trolls can easily destabilize projects and ruin the community.
"major source of con-flict is the possibility of forking" though in the excerpt it mentions that forking can lead to some issues, I'd like to use the NodeJS vs io.js dilemna. Out of a need for progress the io.js fork of the NodeJS project eventually led to a major upgrade of the NodeJS project. The two projects eventually then joined back together and are now moving forward with the community. This is a positive example of how forks can be positive impacts rather than bad ones. You can read more about the NodeJS and io.js dilemma here.
The Questions My 3 Questions
Is there absolute or standardized path for open source communities to follow?
What are some general ground rules communities should establish around their communities and how should they go about modifying them to suit the community's needs.
Should a true FOSS project use a copyleft licence like GPL or a more permissive licence like MIT?
The Review The majority of the points resonated with me and I'd certainly recommend to anyone interested in FOSS to read it. Though somethings are a little bit more different now, it's still a pretty great write up on how understanding the healthy aspects of the Open Source process can produce a strong community and successful project.