Lack of Consistency
Due to the individual nature of each project there is little consistency amongst open source projects when it comes to:
- Version numbering.
- Structure of web sites.
- Location, structure, and content of roadmap documents.
- Location, structure, and content of specification and design documentation.
- Frequency at which milestone builds are available.
- Description of what will be in upcoming milestones builds.
- Frequency and criteria for patch releases.
- Contribution processes.
- Description of criteria that define when 'it's ready'.
Many or all of these inconsistencies would be removed by the usage of a documented methodology. Some of these inconsistencies create barriers to the adoption of open source software.
Barriers to Adoption
Ray Lane, in a speech at the Open Source Business Conference 2004 in San Francisco (Farber), listed these barriers to the mainstream adoption of open source software:
- Lack of formal support
- Velocity of change. When combined with a lack of consistency this gets harder to manage.
- Lack of roadmap
- Functional gaps
- Licensing caveats
- Independent Software Vendor endorsements
The lack of consistency is a factor in the first three barriers listed.
Another significant downside for most open source projects is that the transparency is largely one way: the community has full visibility into the workings of the project but the core developers of the project have little visibility into the use cases and environments that the software is used in. This makes determining when the software is ready much harder.
Whilst the involvement of the community in the process of development is hugely beneficial to the creation of open source software it is not possible to schedule or get commitments from a community as would be possible with a traditional customer or stake-holder .
Lack of Positive Feedback
An open source community is typically very good at reporting problems that they find at any point. These problems include ones encountered during installation, reading documentation, using or integrating the software, upgrading to new versions.
Once a problem has been found community members are typically good at providing more details and helping to diagnose the problem: after all it is in their best interests to do so. Once a solution has been proposed community members are typically good at indicating that the issue has been resolved.
Open source communities are not so good, mainly because they are not typically encouraged to do so, at providing positive feedback when there are no problems. For example as part of my job I frequently download software from new open source projects, from open source projects that are new to me, and new versions of software from open source projects that I am a frequent user of. Frequently I download software from multiple projects that have similar functionality to see which best suits my needs. If I encounter issues with the software I engage with the project's community. If I do not encounter any problems with the software that prevented me from continuing I don't provide any feedback. Even if the software worked perfectly but I decided to use a different project's offering for some reason I don't contribute this knowledge. There is a lot of positive (or at least non-negative) feedback that would be useful to the administrators and core developers of open source projects including:
- It worked fine in my environment (hardware, operating system, RDBMS, browser etc).
- It worked fine for my use case, with my data.
- It's performance is satisfactory under my conditions (transaction throughput / concurrent users etc)
- I integrated it with these other open source or proprietary products ...
Perceived Lack of Methodology
Open source projects have no generally adopted methodology. That is not to say that each project does not have a methodology. Many projects use methodologies however their existence or details are not documented. Many open source projects describe how community members can participate or contribute but the principles and workflow of the methodology are seldom described.
The traditional Waterfall methodology does not work for open source projects. The heavily front-loaded require-ments phase locks the remainder of the release cycle to a pre-defined path that is only conducive (and even then barely) to in-phase contributions. Because each of the phases of the Waterfall model is distinct and rigid a new requirement suggested during the design phase or a new feature contributed during the implementation phase cause significant change management issues. There are other less well-known, but equally valid, development methodologies that are more suitable for open source projects. Scrum is one such methodology.