ImerjaMail utilises Open Source Software which enables us to deliver a high quality, reliable and robust service to you at minimal cost
ImerjaMail as a service is proprietary to Imerja Limited. It is significantly based on open source software which is integrated into functional and presentational services to deliver a high quality, reliable and robust email security product. The principle open source components that underpin this service include:
There are a number of advantages that Open Source code offers over closed source: In essence we share the view that:
"The promise of Open Source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in"
In developing ImerjaMail, we believe that these benefits are realised for our clients. Our emphasis is to garner the constant and rapid functional development and support benefits of open source software delivered by the world's experts on security detection and prevention, and deliver through ImerjaMail these benefits at a fraction of the costs and time associated with proprietary products.
The following extract from the Open Source Forum highlights the perceived and real benefits of adopting open source strategies:
[bug fixing | security | customisation | translation | avoid lock-in | mitigate vendor collapse | get involved]
Bug fixing
Almost all software releases contain bugs. Hopefully, the people developing the software will have spotted and dealt with anything obvious, but any development team has only so much time in which to test a piece of software before it is released.
When a bug is spotted in proprietary software, the only people who can fix it are the original developers, as only they have access to the source code. Open source software is different. As a large number of users can access and change the code, bugs tend to be more visible and more rapidly corrected. One of the slogans of the open source movement is that ‘given enough eyeballs, all bugs are shallow’ [Eric Raymond, The Cathedral and the Bazaar].
Security
Access to source code makes it easier to detect security flaws in software, whether you are looking to fix them or exploit them. Given that most users do not tend to seek out security gaps until they have a pressing reason to do so, this would seem to suggest that open source code is less secure than closed source.
In practice, however, the skills and time required to find security flaws, work out how they can be exploited, and then initiate an attack, are more specialized than the mundane debugging skills required to close exploits. Given the number of programmers who can access and edit open source code, compared with the few that are entitled to access closed source code, it should not come as a surprise that flaws in open source software tend to be fixed more rapidly, before serious damage can be done. Fixing holes in closed source software usually depends on the problem being of a high enough priority to command the immediate attention of the original development team.
Comparisons of patch times between the open source Firefox Web browser and Microsoft Explorer, and between Red Hat Enterprise Linux and Microsoft Windows, support this.
Customisation
Closed source applications can only be customised or adapted by the original vendor. Open source applications may be customised by anyone with the requisite skill. Thus, open source software can be readily adapted to meet specific user needs. Even if you cannot program yourself, it is easy to post a feature request on an open source software project's home page. If you would like something added or customised urgently, you can generally pay an appropriately skilled software developer to do it for you.
For businesses or educational institutions, the ability to customise source code may enable improvements to the ‘best practice’ provided by default installations, therefore improving efficiency and possibly providing a competitive advantage.
The Open University made a decision in 2005 to invest a substantial sum of money in developing the Moodle virtual learning environment to best suit their requirements. As the Moodle source code is open, they can do this for themselves rather than having to persuade a commercial vendor to do so on their behalf.
With access to the source code it is easy to translate the language of the software interface. Large closed source commercial software vendors are usually unwilling to translate their products into less widely spoken languages, as the market for them would be too small to guarantee profit.
An example of this is the regional government of the South Tyrol, who developed a version of OpenOffice in the local Ladin language, which has around 30,000 speakers. This is too small a number to be worth commercial investment, but culturally important in terms of the survival of the language.
Avoiding lock-in
Organisations are said to be ‘locked-in’ to software products when the costs of switching to alternatives are prohibitively high.
Proprietary software vendors can ‘lock’ users in to their products by ensuring that they are not readily compatible with potential rivals. Vendors may then increase the price of product upgrades or support without too great a risk of losing existing customers.
As open source software cannot be ‘sold’ in the conventional sense, there is little danger of being ‘locked-in’ by a vendor. There is also no incentive to use non-standard formats to inhibit compatibility, so many open source software products use accepted open standards that are clearly understood by developers and easily implemented in other programmes.
It should be admitted, of course, that open source software does not come without switching costs of its own. Some administrative and re-training costs must be borne by any organisation that opts to switch between different software. Furthermore, proprietary software may use open standards too. Not all vendors are guilty of trying to lock their customers in.
Mitigation of vendor collapse
Commercial software vendors go bust or get bought up from time to time. When this happens there is no guarantee that their software products will continue to be available, supported, or updated. This can result in users needing to switch products, which can be very expensive and difficult, especially if they were heavily 'locked-in' to their current product.
With open source software, this danger is greatly reduced. As the source code is not 'owned' in the same way that proprietary source code is, it may be picked up and developed by anyone with an interest in a product's survival. Unless you are part of an organization with very significant technical resources, you are unlikely to want to take on full responsibility for this, but, thanks to the way in which successful open source projects gather user communities about them, there will probably be other interested parties to share these responsibilities.
Getting involved
If you are interested in programming, open source code provides an excellent resource from which to learn, and open source projects provide a practical environment in which to test your skills. Just watching the development process can provide an education in itself. If you choose to submit code to an open source project, it will generally be checked and commented on by experienced programmers. Once you have convinced the project community that your code is of appropriate quality, you may be granted full committer rights yourself.
Ross Gardler of OSS Watch, and a member of The Apache Software Foundation, claims to ‘have learnt far more through open source than through any form of formal education or [software development] contract work.’
By adopting open source software you become part of a community of users and developers who have an interest in working together to support each other and improve the software. The extent to which you engage with this community is up to you, but you may obtain the intangible benefits of goodwill if you do. Programmers in particular can benefit from belonging to an Open Source community. It can help establish reputation and respect, as well as gaining valuable experience.
