Hitachi Vantara Pentaho Community Wiki
Child pages
  • 02. Open Source - Principles
Skip to end of metadata
Go to start of metadata


Open source software comes with certain freedoms. These freedoms should not be mistaken with 'free cost'. These freedoms include (with some variation between open source licenses) the right to use it for any endeavor, the right to distribute it and the right to modify it (Open Source Initiative).


Transparency entails letting anyone that wants to see all of the source code of the software, view all of the current and historical defects, view the plans for future development, and view design and architectural documents.


This principle is close in nature to some of the ground rules of academic research. Openness includes accepting (often direct and blunt) peer review. This has its earliest roots in the 'Request For Comments' process used at ARPANET in the 1960s. Openness also includes accepting the participation of, and contribution from, new members. These contributions come in many forms (see below). The combination of openness and transparency means that it is easy for a community to form and participate.

'Early and Often'

'Early and often' entails making things available as early as possible. This includes not only the software but also plans and designs. Applying this principle means putting an imperfect version out earlier (increasing transparency) rather than keeping something back until it is more polished.
Many open source projects achieve the 'early and often' using a couple of common methods.

  • Source code availability. The source code of the software is often made available either on a daily basis as a zip file or 'live' in a source code repository such as CVS or Subversion. Community members using these systems have to compile or build the software from its source code. This is typically used by a small percentage of the community that is actively working on, or interested in, the source code.
  • Milestones builds. On a periodic basis (often monthly) the administrators or core developers of the project compile the software and make the resulting binary / executables available for download. These downloads are typically used by the members of the community that are interested in the functionality of the software. Many open source projects release milestone builds and this practice can be considered to be a form of methodology.
  • Nightly builds. On a nightly basis the source code it compiled to generate the executable binaries. These builds are made available for community members that want to test the latest source code.


Modularity is the principle of maintaining well-defined boundaries between components. Adhering to open stan-dards where possible is a noticeable trait in open source software because it helps define these boundaries.

'It's Ready When It's Ready'

This is not typically listed as a principle of open source but it is very important from a methodology perspective. Many proponents of open source software state that the reason that quality is high because the lack of a deadline allows an 'it's ready when it's ready' attitude to be used. That is to say an almost infinite time is available for the software to mature before it is stamped as being complete. In reality, however, time pressure is vital to open source projects because it drives contribution.

Consider these two situations:

  1. I have a deadline. I need specific functionality for an internal IT project I am working on. My deadline is 4 weeks away. I find an open source project that includes some functionality I need. The open source software is currently at Milestone 4 stage. I attempt to integrate the components and apply them to my use case. I find two documentation issues and a bug that halt my progress and either manage to find fixes or get help from the community to solve them. I contribute my changes to the project. I test my creation and put it into the hands of my users. These users (as they do) find issues that I did not during my testing. Some of these issues are defects in my work but two further bugs with the open source software are found. I work to resolve these issues with the project's community and core developers. 7 weeks after starting my IT project it is stable, in daily use and I am on to another internal project. The open source project I am using is now at Milestone 5 stage but the features I need are working and stable in my use case. I found 5 defects and helped the open source project to resolve them. Using and contributing to the open source project was in my best interest.
  2. I have no deadline to speak of. I'm working on something but it is not due for 2 years. I find an open source project that includes some functionality I need. The open source software is currently at Milestone 4 stage. I don't need the software yet so I wait 6-9 months for the software to be 'ready'. I have no need to contribute and so I don't.
    If everyone was in the second situation the majority of contributions would be from interest-based participants and there would be very little participation from needs-based participants. It is significant to note that the participation in the first scenario above was for a short duration and only affected a single milestone release of the open source project.

There is nothing like putting software into in the hands of real users to find problems. Open source enables this much better than closed-source development. Once a community member has proven to their satisfaction that the software does what they need it to many of them can and do use the software before it is 'ready' (by the judgement of the projects core developers).

  • No labels