I love Open Source software. I love the fact that people, for various reasons, share their work. Not because some 'boss' tells them to, but because they want to.
The absolute power of Open Source software is the fact that once shared, others can contribute to the software making it better and more functional. Because there is no ownership discussion, all energy spent can be for the good of the users of the software.
Servant mindset: plus-sum thinking
That is what Open Source for me is about. This is where the energy of several people and groups is combined into something that is more then the sum of the different parts.
Contributing to an already existing project requires a different mindset then the mindset we see nowadays with a lot of companies (and individuals). You contribute to Open Source software to make the experience for others better thereby automatically making it also better for you: instant Karma :)
Commercial mindset: zero-sum thinking
Unfortunately we to often experience the “what's in it for me” mindset blocking the contribution to existing projects. Energy spent is not synergetic but competing, and although competition can drive people to perform to their maximum, there will always be a loser and thus the sum of total energy spent will never add up to be more then the different parts.
DRY principle
In software engineering there is an important principle: DRY
DRY stands for: Don't Repeat Yourself.
It is aiming at reducing repetition of information of all kinds. When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync. (From Wikipedia, the free encyclopedia)
Knock-out principles
When selecting Open Source software there are a number of conditions for me that should be met:
- Community feedback: How responsive and open is the developer of the software when it comes to requesting new features and solving bugs?
- Vendor lock-in: How well is the code documented? if there is an API, is it documented and shared. Can the software be integrated into / with other software or are you 'limited' to the software of the vendor?
- Code review: How well is the code written: was the DRY principle embraced?
- Code(r) review: is the DROC principle embraced?
DROC?
One of the most important principles for me is DROC: Don't Repeat Others, Contribute!
DROC is the same as DRY but then not limited to a software solution but transcending (different) software solutions.
Let me explain by using a simplified example from the Joomla world.
Joomla has out-of-the-box blog functionality. This functionality provides the basics of blogging: you have an author who can write an article. This article can be displayed via the front-end via different build in components and modules (frontpage, featured, most read, etc.)
As a developer you can 'easily' add functionality by building upon the already built in blog functionality of Joomla. A good example of this is for example ochBlog. ochBlog adds functionality to Joomla that is following the DROC principle. When you use ochBlog to create a blog, what it actually does is create a Joomla article: it leverages the already present functionality in Joomla. It doesn't duplicate that functionality like other blog components do: they built duplicate functionality and offer the ability to 'import' already present Joomla articles into their solution. Do you feel the waste of energy? Do you feel the vendor lock-in?
Looking beyond offered functionality
What will happen when you want to implement a cool new module that displays Joomla articles in a fancy way that adds value to your users? With the DROC way of developing that ochBlog uses, you can use this fancy module: if it works on Joomla articles, it also works on ochBlog articles (because they are the same). But what with the other blog solutions? It just doesn't work, so if you want to use this fancy module you only have one option: redo the code (Repeat Others) so it will also work with the blog component. Can you do those changes? Can another developer do that? Or are you dependent on the goodwill of the developer of your blog component? How often do you hear “It's not a priority for us”...
I hope these criteria help you in having the best experience possible with Open Source software, not only for the short-term but also for the long-term.
Please contribute and share your selection criteria and thoughts below this blog.