This debate usually brings out an opinion for technologists; it contributes to that very opinionated overarching debate which is what is better open source or proprietary software?
I have a strongly held opinion that open source software is best as I am working for an open source software development company and have seen first hand the pros and cons of open source software development, however I have not had any experience working for a proprietary software development company so I have a definite bias which I would like to disclose now.
However as we are discussing software development methodologies in SYD701 at the moment, and I have been fortunate enough to attend several IT events and meet other developers in industry over the last few months I would like to share my views on the argument that open source software doesn’t meet user needs as well as proprietary software.
A while back I attended an ITP (Institute of IT Professionals) discussion at the Nelson Hospital conference center where they debated open source and proprietary software; one of the arguments that the proprietary side made was that open source software does not meet the requirements of users because it does not rigidly follow a software development methodology and so it does not effectively capture client requirements. This argument is based on the assumption that open source software development is very haphazard, i.e. a developer somewhere in the world comes up with an idea and develops a feature without ever talking to users.
Well I can say the vast majority of open source projects have a definite workflow you need to follow to develop and push an enhancement out for a open source product.
For a start you have to write up whats known as a RFC (Request For Comment). The open source product Koha ILMS (Integrated Library Management System) which I work on has a specific template that must be followed and can be seen here: https://wiki.koha-community.org/wiki/Category:RFCs
As of the 16th of May there are 88 RFC’s requesting feedback for proposed Koha enhancements (as you can see in the below screenshot) what this means is you really have to make an effort to get your RFC to stand out in order to get valuable feedback. How do you do this? Well you can use the #koha irc channel (which is where many developers and most importantly librarians chat about Koha, I’ll come to the importance of librarians in this project a bit later), Koha twitter page, Koha developer meetings (which are held once a month on the #koha irc channel), and emailing the release manager of the next Koha release.
It is important to add new information to the RFC as you make changes based on feedback so as to keep interest in the enhancement up, if other developers are interested in what you are working on then they are more likely to test your patches thereby helping you get your enhancement through the QA system faster.
After getting feedback from the RFC you can start designing the enhancement in more detail, Koha like many open source projects uses a agile methods approach. So rather than spending a large amount of time performing documentation you perform a more iterative, test based development by taking the initial user requirements captured in response to your RFC and developing a first prototype which you attach to a bug report in the Koha BugZilla bug tracker (https://bugs.koha-community.org/bugzilla3/) and then request feedback on that. Those users you hopefully got interested in response to your RFC will now be a great help because they are likely to want to help test your patches. To help them test your patch(es) you have to write a test plan which is a numbered plan describing how to perform an action using Koha before and after the patch is applied so that the changes can be easily observed. This test plan must be follow-able for people new to Koha, increasing the testing audience available to you as well as making testing more inclusive to newbies.
If starting out developing for an open source project, you will have a lot to learn and so the feedback and improvements you receive from testers is amazingly useful. Using that feedback you iterate over the enhancement again, and attach it to the bug report for testing again. This process continues over and over until it is signed off by another developer.
Does this mean it will get into the final product? No its doesn’t, mature open source software projects like Koha want to enforce the quality of their code and so one signoff isn’t enough. In general at least 2 signoffs are required; one by another developer and one by an member of the QA team.
There are several types of tests that are performed on your patch(es) to ensure they meet coding guidelines and work as intended.
Firstly the code is eyeballed to determine if there are any obvious mistakes, this is easy because BugZilla highlights the changes made in the patch (much the same way as Git does) and so you don’t have to try and work out what has changed. Then the tester follows your testing plan to functionally test if the patch(es) work as expected. The functionality testing is what I plan to work on for my work placement PRJ701 project so as to speed it up through the use of automated testing tools like Behat.
Finally a qa test is run which is another check if the code meets the coding guidelines.
If all these three testing types prove that your patch(es) are up to standard then you will be signed off by another developer and a member of the QA team and your patch will be set to ‘Passed QA’ and it is very likely to be pushed to the Koha master branch (the only reason it would not be is if the release manager finds an issue which no other tester has identified which is highly unlikely or if your patches conflict with another enhancement that has been pushed to the master branch).
So you can see the testing process for open source software, in this case the Koha ILMS is very thorough so as to make the product as stable, maintainable and well developed as possible.
Now why is having librarians involved in Koha is useful? Well Koha is an Integrated Library Management System which is used by thousands of librarians around the world on a daily basis so having librarians involved in giving feedback to RFCs, testing patches, and in several cases writing their own patches means that Koha is definitely hearing and meeting client requirements. There cannot be many software development projects in the world where end users not only specify their requirements, but also test patches and help develop the product they use!
This is not just specific to Koha, many open source software development projects try to make themselves as inclusive as possible so as to get a variety of people contributing for example Libre Office project is constantly trying to gain new developers through promoting the founding of Libre Office meetups, providing easier patches for beginners to test and signoff and through their website (https://www.libreoffice.org/community/get-involved/) they promote different ways people can contribute based on their experience, for example if you don’t know how to code you might like to contribute to the design of the Libre Office products.
So in conclusion open source software development very much meets the requirements of end users by making sure new enhancements have RFCs so you can gain feedback before you start designing and coding, adopting the agile methods paradigm to develop enhancements iteratively, and increasing the inclusiveness of the developer and tester base.
It is this inclusiveness in many of the mature open source projects (of course not all open source projects are inclusive) which means there is greater end user participation in the product development, and it means that open source software is not as affected by the lack of women and coloured developers as proprietary software development because people who don’t work in software development can still help contribute to the product making for a better performing end product. So I would argue that in many cases open source products more closely meet client requirements than proprietary products.