After one of my sessions at IBM Connect I was approached by a developer whose company would not use open source. The comment made me despair more than a little and has festered for some time. I’ve used code and projects from OpenNTF for many, many years before subsequently contributing to OpenNTF. Obviously as a contributor to and now director of OpenNTF my personal opinion on whether or not open source should be used is clear. Not allowing your developers to use open source is like expecting a developer to write their code in NotePad. Or giving your users typewriters instead of PCs. It may have been a plausible demand when developing just for Notes Client, on a proprietary platform where the only open source that was of relevance was from OpenNTF. But the days of Domino developers only able – or more importantly only willing – to develop for Notes Client are numbered at best. The future is web or mobile and in that landscape the “no open source” argument is unsupportable. Here are ten reasons I think anyone who prohibits open source needs to think again.
1. Good Developers Write Good Code, Great Developers Steal Good Code
It’s long been a maxim in software development, but it’s true. Some of the best code I’ve used is at least based on the work of others. I would name projects like OpenLog which Matt White also converted to SSJS in TaskJam, Jesse Gallagher’s controller framework, a whole host of stuff by Tim Tripcony, Fredrik Norling’s Standby Custom Control which itself builds on work by Tim Tripcony, Serdar Basegmez and Tommy Valand. The OpenNTF Domino API contains some brilliant code, like database listeners and transactional processing for Domino. The auto-recycling code was developed and enhanced by developers who were not from the same company and not even from the same continent. I would assert that only a handful of companies world-wide have developed proprietary code to rival that assortment. And I’d go further to suggest that any who have use open source code.
And beyond code specifically coded for XPages, many Domino developers now typically take advantage of open source Java code – Apache Commons StringUtils, Apache POI, other Apache classes for JSON or REST service handling. To avoid using those back-end classes, a company would have to spend years writing alternatives.
2. Open Source Is Better Than Any Training Course
Let’s face it. How many “Hello World” apps have IT ever put live? How many applications that formed part of a training course have been used in production? Courses focus on how to use a framework, not best practices for building an application. Actual applications or snippets teach us more about best practice (or the opposite) than any training course. Developers also get to see a variety of methods and potentially how an application has been improved over time by refactoring. (It’s well worth looking at how XPages Help Application or XPages OpenLog Logger has changed over time as my expertise has increased.)
Contributing to open source teaches you even more. XPages Help Application allowed me to get to grips with Java in XPages and I’m sure that experts from the community were more willing to help me out because it was an open source project. I would not have known about ExpireDate if there had not been a request for me to add that functionality into XPages OpenLog Logger. And you could not buy a training course that would teach what I’ve learned working with the rest of the OpenNTF Domino API team.
3. Don’t Reinvent The Wheel
Unless your developers are very good, it’s unlikely to be as good as the wheel that was developed by experts and improved over a period of time. And if your developers are that good, they’re likely to leave for somewhere they can really flex their muscles.
4. Do You Employ Someone To Check The Originality Of All Your Code?
A large organisation like IBM may do. Most Domino customers don’t. Can you say with complete certainty that a function in your application hasn’t come from someone’s blog or a source like XSnippets? Can you say a developer hasn’t used a function they developed for a previous organisation? Unless a company inspects and checks the originality of developers code, there seems little point in telling developers they must not use open source code.
5. Improved User Experience
In this category I’m not just talking about Twitter Bootstrap for look and feel, but jQuery or Dojo for widgets and various web frameworks that handle cross-browser fidelity. If you do not allow developers to take advantage of those kinds of frameworks, you will increase development timescales to provide cross-browser functionality. Few companies now can develop only for internal staff. Externally-facing applications are expected now, in which case you cannot guarantee the browser being used.
It will also take more time to reproduce the kind of slick user experience, if indeed your developers are able to get close to the kinds of widgets that jQuery or Dojo provide.
And improved user experience is not restricted to front-end code. If you’re using using HTML tables to export to Excel, Internet Explorer has for some years thrown a security exception, prompting the user to confirm the content is from a trusted source, even if it’s from an intranet application. There is no way to work around this with HTML alone. However, Apache POI makes it easy to enhance the user experience and avoid that prompt. But it’s open source.
6. You’re Competitors Probably Use It
Unless you are a very large company, you cannot demand that your customers use specific software to interface with your business. Websites will be used on mobile devices. Web apps will be used on a variety of browsers and browser versions. And it’s unthinkable that none of your competitors build their websites and web applications without using open source.
7. You’re Developers Are Already Using Open Source
If they’re using XPages, they’re using Dojo. Dojo is an open source framework from the Dojo Foundation, an open source company. Without it, XPages would not exist. The Dojo controls in the Extension Library that consistute one and a half chapters of XPages Extension Library would not exist without Dojo. They’re there for a reason: they offer functionality the out-of-the-box controls do not.
8. Does Your Non-Notes Software Use It?
Is it excusable to ban internal developers from using open source while buying software that uses open source?
9. Domino Is Built On Open Source
The standard Notes Client is built on Eclipse 3.4.2. Who is responsible for Eclipse? Not IBM. The Eclipse Foundation, an open source company with which IBM works very closely.
Embedded Experiences cannot run without Apache Shindig. An open source piece of software from Apache, another open source company IBM works closely with. (Lotus Symphony was built on Apache OpenOffice at a time that it looked like Oracle might take OpenOffice in a proprietary direction, but when it was fully handed over to Apache, IBM also handed over its enhancements to Apache, and Symphony is now deprecated in favour of the OpenOffice, an open source suite.)
Mail Next will use Apache Solr. An open source indexing library from Apache.
I’ve already mentioned Dojo. But Connections and iNotes both use Dojo.
And if you want to take advantage of Connections integration, under your current rules you can’t. Social Business Toolkit is only available as open source and there’s no suggestion that’s going to change.
Notes and Domino both use a number of Apache libraries, all of which are open source. Apache StringUtils is part of the Notes Client install, but has to be added to an NSF to use in XPages. If you prevent the use of open source, they can’t use something the Notes Client uses.
So why would you prevent your developers from using the same libraries in their applications?
10. IBM Are Committed to Open Source
They contribute resources to OpenNTF. They are heavily involved in Apache. They contribute to Eclipse. They contribute to Dojo (look at the source code for dojox.charting.Legend, it was contributed by an IBMer).
Wake Up And Smell The Coffee
So why prevent developers using open source? The only argument that has any plausibility is that managers feel they are not capable of supporting the code it uses. If they do not yet have the skills, look for a support contract from a company that does have the skills (which is after all what you do for off-the-shelf software). Intec has supported companies in the past with an XPages mentoring contract that provided that kind of facility for the Extension Library.
Even better, empower your staff to gain the skills they need to at least investigate the code they’re using. They will become better developers as a result. To deny them those skills, to limit them to proprietary knowledge is to deny them adequate professional development. And unless you’re guaranteeing them a job for life (and in my opinion there is no such thing), you are failing your staff.
And I challenge any IT manager to justify the ROI of prohibiting open source. Calculate the cost of training new staff on your proprietary code. Calculate the cost of re-inventing wheels. Calculate the cost of mistakes that have already been overcome by similar open source code. Calculate the cost of staff leaving because they realise that to stay will affect their ongoing job security. I will confidently place against that the cost of any bugs or issues encountered when using open source.
If you want to limit what open source software is used, I would accept an argument to only use Apache-licensed open source software. OpenNTF projects are now encouraged to be Apache-licensed, for the very reason that it gives greater confidence over authenticity of code.
But in my mind, there is no valid justification in the modern IT world for refusing to allow the use of all open source software.