Several days ago I posted the slides I used at the Open Source Business Conference in PDF form and also provided the SlideShare version. For those who want to see the contents of the slides directly, I’ve included most of it below.
What I do not have here is one slide that I used to say that I was going to focus on the technical, community, and business aspects of open source and that I would try to stay away from ideological or philosophical issues. I knew some people would not be happy about that and, to read some of the Twitter tweets during my talk, that was indeed the case. So be it.
The second preliminary slide not included here was a partial history of some of IBM’s involvement in open source projects within Linux, Eclipse, Apache, and other projects.
Is software good software, just because it is open source?
- It depends of your definition of “good,” but by most definitions, the answer is “no.”
- As of three days ago, a popular code repository listed 164,297 open source projects.
- Statistically, you might imagine that some are better than others.
- Your definition of “good” is critical.
Is the code well architected and implemented?
- Great code may start with the germ of a fantastic idea, but it eventually gets rewritten one or more times to be faster, more reliable, more secure, and more extendable.
- If you are not an expert yourself, seek independent assessments of the quality of the code.
- The quality of the documentation and user interface are important considerations in their own rights, but may also give you an idea of how well designed the core of the software is.
Who are the founders, contributors, and users?
- People write code and drive software projects and products.
- Unreliable people may place the future of the software in jeopardy, and thus also your investment.
- Work out “what if” scenarios for what you will do if the code gets abandoned, forked, or acquired.
- Learn what other users have done with the code and about the quality of their experiences with the software and those who created it.
What is the form and governance of the community?
- Find out if the open source code you are considering is being developed by a healthy, democratic, and meritocratic community or if it is really just a controlling company “coding in public.”
- Learn if the community also includes documenters, graphic designers, and evangelists in addition to coders.
- Look at the project forums, Facebook, Twitter, and other social networking tools to get a sense of the health of the community.
- Don’t ignore warning signs of trouble in the community and things that may make you uneasy about it.
Are there intellectual property issues involving copyrights or code provenance?
- Ignoring legal issues with software can be one of your most expensive mistakes and can literally put you out of business.
- Learn about open source licenses and consider hiring an intellectual property attorney as a consultant when you are considering use of software or negotiating a contract.
- Don’t mix open source licenses unless it is legal.
- Make sure the developers of the software you want to adopt played by the legal rules.
- Don’t pretend to be an attorney if you are not.
Does the license suit all your future plans for the code?
- Some open source licenses can be combined and others cannot.
- Some open source licenses allow for free use in commercial, “closed source” applications and others do not.
- Some open source licenses specify some restrictions when you host software-as-a-service.
- Be especially careful if you want to use open source code libraries.
- Understand if the software you plan to use can be hosted on either a private or public cloud.
Do you have proper legal controls and business processes in place to deal with open source software?
- That is, what is your open source governance strategy?
- Five years ago, it was not uncommon for that strategy to be defined as “you shall use no open source software.”
- You need to understand the legal risks and responsibilities for any software you use, and weigh those against the business value.
- Work out a plan that specifies what business and legal controls are in place to approve use of open source in your organization or in your products, and make sure you have a well defined escalation path.
Is the software enterprise-ready?
- There’s been a lot of discussion about whether open source software is more secure than proprietary software.
- Which open source software and which proprietary software?
- In addition to security, you need to look at reliability, availability, scalability, interoperability, and performance.
- Make sure the software is available on the right hardware platform so you can optimize the environment for your workload.
Who will maintain your installation of the software?
- If you are planning for your IT staff to install and maintain your software, make sure it doesn’t get orphaned when you have personnel turnover.
- When software updates come along, you will need a plan to decide which ones to install and when, especially if major releases come along every six months or so.
- If you customize open source code for your organization, are you prepared to propagate those changes into newer versions of the code?
How easy is it to integrate the software with your data or other software you already use?
- Does your software use recognized industry standards or does it have its own way of formatting data?
- Are the developers of the software involved in creating the standards that will allow interoperability?
- If you adopt the software, who will do the integration tasks?
- Is the software certified for use on the operating system and hardware platform you plan to use?
Are benchmarks available to allow performance evaluations of the software with comparable products/projects?
- While benchmarks can be abused, they can be important in learning if particular software is really usable in your business.
- You might worry less about published benchmarks and more about proofs of technology and head-to-head comparisons among the software choices you are considering.
- Consider your software provider’s response to such requests for “bake offs” when making your adoption decision.
- First and foremost, open source software is software.
- When it comes to business and especially enterprise use, open source software should get no immediate free pass because it happens to be open source.
- Conversely, proprietary software should also be measured on a level playing field with open source, and get no special initial treatment.
- All those things that you worried about when choosing proprietary software—security, performance, reliability, availability, interoperability, support, maintenance—are also areas to investigate when considering open source software.
The Whole Series
- “Asking the hard questions about open source software”
- “10 elements of open source governance in your organization”
- “10 considerations for maintaining open source in your organization”
- “10 ideas about integrating open source into your IT infrastructure”
- “10 things traditional software customers want to know about open source”