Selecting Open Source Software Libraries (2)

Dependencies: most software is dependant on other libraries for certain basic functions. This can pose a problem if these libraries are not available on the system being developed for. This might be for cost, licensing, hardware or other restrictions. Note that often the dependencies also need to be available in the correct version – possibly libraries have conflicting requirements!


Documentation is often scarce in the open source world; in particular developer documents such as API descriptions, configuration documentation, build instructions. You should also check the documents are up to date. If you need help you may also want to check whether there are any mailing lists or discussion forums associated with the software. This is often the case when the software is a product of a community effort.


Authors – it’s usually helpful to find out some background on how many authors are working on the source. Are you relying on a sole software developer or binding yourself to a single company? If the library is implementing a standard API this is not as critical as it’s easier to change the implementation w/o affecting your own software. In other cases you should always abstract from the implementation via your own API! Good places to find out about the authors are bug tracking systems and/or history of change documents, in addition to the website hosting the open source library.


Known bugs – check bug tracking systems (bugzilla[3], or whatever tracking system the open source website mentions) to find out about known bugs, get an idea of the stability of the software, frequency of updates, date of the last update (is anyone working on the software lately?), missing features, community feedback etc. The version of the software also provides an indication of stability, so beware of 0.1 versions!


Check how to build the software: the build system may require new tools and/or scripts. Possibly the build system uses a language (e.g. python) you are not familiar with. Is it configurable, do you need cross-compile support?


Take a look at the sources! Check for inline commenting, readability, structure, unit tests, all factors indicating the code quality. You may want to have a code checker (e.g. findbugs) analyse the code. Also check the warnings your compiler logs during the build process. Example applications are also useful if they are included.

Agile Bewares (1)
More and more teams and organisations are moving to agile. Interestingly I keep hearing similar statements that ring alarm bells in my mind. I thought I'd mention a couple of statements to beware about. This will probably become a growing list, so I'll call this part 1.

• we're agile inside development but still run the traditional process toward the rest of the organisation

That probably means budget, milestones and feature are fixed. In my experience, that leaves little room for agile, except for what I call "agile in the small", e.g. pair programming, test-driven development in the scope of unit testing (assuming internal milestones such as code-ready accomodate this). Probably, customer/product management won't (want to) be involved, so requirements won't be prioritized and thus the most important things might not get done first. You'd probably want to query why they want to run an agile process, what benefits they are expecting and make sure everyone has the same understanding of the process.

• scrum teams are component-teams

Compared to cross-functional teams that means you lose the advantage of direct communication between those implementing a user story (feature?) and also the better resource usage of cross-functional teams. Why is the resource usage better for the latter? Because component team members only work on their own components and thus can't help put in other areas. Cross-functional teams work on features or user stories and thus learn about all the layers and components necessary to complete their user story. On a similar line that's why you need to ensure user stories or features are customer centric and not defined like this "the database access layer needs to support CRUD operations for xyz data". Otherwise your feature team will again be working on a single component. Having cross-functional teams also enables the interfaces between the components to be defined, implemented and tested within one team, avoiding the frequent communication gap across interfaces.

• we adapted this recommendation because it won't work for us

While being agile also means adapting your development process, there is the risk that teams new to the agile process adapt recomendations because they don't understand them or because they think they don't work or maybe just because it sounds like too much work. There is a real danger to leave out all the bits people don't like to do (like regression testing, documentation) which is not necessarily being agile. Another reason why recommendations are not followed is because agile is used first time in critical projects (and that itself goes against recommendations!). And then people are afraid of anything that sounds unfamiliar and afraid of failure.

My recommendation is to try out those best practises on an uncritical project first before deciding what will work for you and what will not.

• With agile development can relax from all that planning and administrative stuff and focus on the important bits

Well, in my experience XP and also scrum require more discipline. Its just the responsibility is on the teams. For example, agile places a lot of emphasis on automation, e.g. automatic testing and also on metrics, e.g. code coverage, iteration and release plans (sprint backlogs), burn down charts, velocity tracking. Or look at planning: the product owner needs to prioritize all the user stories, stories need to be estimated based on velocity, they need to be broken down into small stories and even smaller tasks. Each needs to be tracked. Remember all those charts? Then there's all that CM stuff to sort out. CM is more complicated with everyone being able to change anyones code!