Jeff talks about challenges faced by developers when using open source. One of them is the ability to cope up with Community based support structure. I would actually call this taking contributions from the users. Users can contribute in a variety of ways – giving feedback, providing support or suggesting usage-driven enhancements and features. Experienced users are the best candidates for providing support for usage. In fact, some can come up with innovative uses that the creators had not envisoned! This can lighten the burden of support. The biggest problem of a developer talking to a user is the mismatch in the language that is used. A user talks to another user in the same language and can easily identify with the problem. The easiest way of handling this is accepting it with an open mind.
I don’t agree entirely on the Extra functional requirements factor, they are in fact not a side-effect of using open source, but of using the wrong open source software. There are generally four types of requirements that we can consider:
- the core requirements (business/functional requirements)
- the supplementary requirements (performance, security, scalability)
- the usability requirements (user experience, overlaps with core and supplementary requirements)
- the business constraints (budget, deadlines)
All of them are equally critical, but they do have certain dependencies on each other. Lot of times, the core requirements factor into deciding the supplementary requirements. It is imperative to identify these before any software is selected for use. Otherwise, the pre-selected software capabilities and limitations drive these requirements causing failure of the venture. It is important to use requirements-driven approach for selecting software. This is true for any kind of software, open source or not. In case a fully matching software is not available, this can be addressed beforehand, discussed, brainstormed and decided upon. This can require a brief phase of research to identify the right software to use.
Open Source for Agile development
Agile development is about being dynamic, about moving with changing business requirements and demands. Software reuse, which is promoted by open source software, can help being dynamic by integrating with ready functionalities. However, this advantage can quickly turn into a upgrade/evolution/development hell if the application becomes to dependent on the open source software being used. Jeff says:
A well defined architectural framework supports the selected architectural style. An architectural framework can address the critical concerns for constructing applications that must exist within an enterprise-wide context. A good framework enables the selection, integration and deployment of best-of-breed ingredient technology (open source, commercial, etc.) required to meet changing business concerns without significantly impacting functional development.
Therefore, implementing an architectural framework allows the developer to retain architectural control of his application by remaining technology independent, address critical and strategic concerns, and free to swap open source ingredient technology ‘A’ with open source technology ‘B’ when needed without major rework or refactoring.
Spot on! The keyword here is technology independent. Architectural style can be used to define/specify the system without using any specific technology. The biggest advantage of this is that whenever any sub-system or component has to be changed/swapped, its impact can be easily identified.
In my opinion, to really leverage the open source field, it is important to research continuously. Like Jeff has mentioned, today’s developers have a wide array of open source softwares open to use. But these multiple options can be a nightmare because of lack of knowledge. What is required is a continuous probe into the domain to stay updated about the new developments and concerns.
Agile development is for flexibility and open source software can do a major contribution there. To be able to successfully integrate the two it is important to focus on requirements, technology independence via Architectural style and continuous research.
Copyright Abhijit Nadgouda.