Open Source
Software in which source code is publicly available, that can be used, enhanced, modified and shared under specific conditions.
What
A mindset
A development methodology
What's useful to me might be useful to others.
Unless something has to be private, it ought to be public.
User-centric: put efforts where users are, build what is most needed.
A rule of thumb
Who
Maintainers
Contributors
Users
investment
Building the right software right is a complicated endeavor, so it's better done together.
Why
- A proven collaborative methodology to build better software.
- A requirement of auditability and transparency.
- A fertile ground for innovation in the software industry.
- An assurance for longevity and immortality of software .
- A driving marketing factor to attract talents.
- An alignment of ethos and values.
How
Solve (useful) problems, and listen.
Rinse and repeat
Identify a problem
Find or build
a (good) solution
Help others
finding and using it
Listen to and
incorporate feedback
Myths & legends
Myths
If we go Open Source, people will maintain the project for us through contributions.
Myths
Open Source isn't suitable for enterprise businesses because it lacks support and code quality is too low.
Myths
Because it's free, Open Source only costs money and cannot generate revenue.
Myths
Open Source means open governance: anyone can contribute and all ideas are always accepted.
Myths
If I use an Open Source projects, I am at the mercy of the maintainers and have to wait after them constantly.
Case Study
Make sources public
All source code is publicly available under open source licenses. Not only for the compiler, but for the entire ecosystem of projects.
Develop in the open
Feature changes are brought to life on public forums. Reviews, feedback and next steps are openly discussed.
Foster inclusive processes
There's no private component to our development process. Anyone can follow what is happening, how and when.
Document everything
We strive to keep the entire project documented, from installation instructions to API reference, including details about maintainers and processes.
Practice
Theory
Understand
Use
TUTORIALS
HOW-TO GUIDES
EXPLANATIONS
REFERENCE
discovery-oriented
understanding-oriented
goal-oriented
information-oriented
WHERE
HOW
WHY
WHAT
( about documentation ... )
Talk to people
We keep communication with our community frequent and transparent. Announcing changes, seeking feedback, etc..
Provide support
Documentation only gets you so far. People often needs assistance and it's also a great way to identify gaps in documentation.
Release frequently
Avoid 'big-bang' releases as much as possible, ship code often and in small chunks. Keep expectations low.
Provide clear governance
How decisions are taken should be clearly specified. Dictatorship and do-ocracy often rules in Open Source lands.
Axioms
There's no such thing as a free lunch.
Comprehension is measured by the lack of questions.
It’s okay to be disappointed but never okay to be surprised.
Constructive discussion is about mutual understanding, rather than mutual agreement.
If it's not documented, it doesn't exist.
Yet another introduction to Open Source
By Matthias Benkort
