The Internet was originally created by US military (ARPAnet1) to share information between geographically separated research computers. Since its creation, several developments occurred, e.g. sending and receiving huge amounts of data between various clients and storing data in the cloud. Open Access was a result of the dissatisfaction of researchers with the price models of scientific publishers, and scientific publishers making huge profits from research funded by public finance to benefit all. The Internet opened up a whole new world and made Open Access possible. The ability to not only download information but also to upload information lead – amongst other reasons - to the development of software to provide and manage Open Access services. Open source software is synonym with Open Access, because of the shared principle of ‘openness’ and the benefits thereof. Read more about open source software from the Open Source Initiative2.Within an Open Access environment, content (whether digitally born or after being digitised) is submitted by the content creator, owner of the content or a third party with the necessary permissions to do so. The content can take any form, with the only condition that it is already in some form of digital format, preferably an open format. The Open Access software architecture has been designed to manage both full text content and metadata3 (data about data). Basic services provided by this software include submission, retrieval, searching, and indexing. These systems usually also have an automated workflow, and an audit trail is kept of all actions during the various stages. Implementing an Open Access service usually follows a need to make research openly accessible for all, aligned with the strategy of an organisation. It is recommended that a thorough needs analysis/assessment be conducted before proceeding with the implementation of an Open Access service. This should be followed by a proposal and/or business plan (incl. capacity planning), before it is finally implemented. Policies and procedures should be compiled, and the service should be regularly evaluated to establish whether it still addresses the changing needs of the user community.