I’ve been using Linux/UNIX for about 20 years. I am also Assistant Director of the Boston Linux and UNIX Group, and have contributed to several open source products. In general, I find open source software more flexible, more transparent (no security through obscurity), and more focused on what’s needed instead of what marketing says would be cool. I like that open source software is usually developed modularly, with separate components each doing what they do well, each designed to be combined with other component, each with its inputs and outputs documented for fitting Tab A into Slot B. Open source’s community support model (with a sufficiently large community) is often far superior to calling tech support. All that said, I still believe very strongly in “the right tool for the job”. Sometimes open source is not the answer.
Just like commercial software, it’s important to evaluate not only how well the software suits your need, but the “health” of the product and its creators. Just because it’s still available doesn’t mean it’s still supported, updated, and in common use. That may not be a deal-breaker for you, but it does need to be factored in to the decision.
Choosing To Use Open Source Software
Community support in the form of email lists, forums, user groups, websites like Stack Overflow, and IRC channels are very good at getting you the right answer, because they are populated by people in your shoes, and most likely someone else has tried to do what you are trying to do, and have no problems blaming the product. They may not get you the answer quickly, and not every answer you get will be right. If timely support is critical, there are open source products with professional paid support, and that gives you the best of both worlds. This is much more important with unique vertical software with a smaller target audience. If you’re looking for support for something like Ubuntu or Apache or Java, you can usually get answers in minutes.
This is the area of most confusion, especially among higher-level decision makers. This is, in part, because there are many, many different and incompatible open source licenses, and in part because of the fear, uncertainty, and doubt spread by its opponents and their mindless followers. It is true that some open source licences (like the GPL) dictate that the covered products only be included in similarly-licensed software (this is what the derogatory term viral licensing refers to), but it’s more complicated than that. For instance, it’s perfectly fine for a commercial product to dynamically load GPL’ed libraries at runtime, because they don’t be come part of your product, but statically linking them in at compile time is a problem. Most open source licenses don’t have that aspect, though. The take-away here is do the research and know the facts, not corporate spin. When in doubt, just ask them!
Under most open source licenses, you can’t charge for the software, but you can charge for distribution, media, support, documentation, consulting and other services, etc. Many companies that distribute open source software have a free version and a commercial version (like Red Hat and MySQL), and that’s their business model. You will find plenty of studies showing the total cost of ownership being either higher or lower for open source software. Part of that is determined by how much it will cost to hire people to use it (which is mostly based on how popular it is). For instance, it takes a lot less manpower to administer a Sendmail- or Postfix-based mail server than a Microsoft Exchange server, and there are a lot of people out there who can do it, so that can be a big win. Cost is actually the least of open source’s benefits to me, so I have no problems paying for it, or even donating money to groups that offer free open source software. For instance with Postfix, you can use one of several separate authentication systems. IMAP/POP servers, storage systems, etc. It’s the flexibility that draws me to it the most.
Building on open source software may affect your distribution options. For instance, I worked on a project a few years ago that required a MySQL database. We couldn’t distribute the MySQL server with the product (though including the client libraries was OK), so our instructions had to include how to download and install it. That turned out not to be a problem for us. On the other hand, may commercial libraries and software components have per-seat or per-core costs that must somehow be passed on to your customers.
Choosing An Open Source Product
Some open source products are created by real companies, and some are created by communities. Neither is really better. Products created by companies tend to have actual funding, but that can change at any given board meeting. Community projects can outlive their creators, but only if they have enough buzz, usefulness, and leadership. Either way, it’s essential to find out how long the product has been in existence, when the last release was, how often they release, how they handle bug reports, and the size of the team. At a recent job, I had an assignment thrown in my lap to integrate an open source component developed by another company, and once I started running into trouble, I found out the product hadn’t been updated in almost three years! And not for lack of need.
There are several wonderful website that offer open source project hosting. Probably the best known ones are Sourceforge, Apache Software Foundation, and Tigris. This Wikipedia page lists several others. One promising one I have my eye on is BetterCodes. Most of these will have the release schedule of each project, as well as the number of people associated with it. Most also have a forum system you can poke through to see how quickly questions are answered and problems addressed. Other projects have their own website, email lists, and forums. Search engines and mailing lists are your friends here.
A word of caution on liveliness versus stability; Some projects are so actively developed that they change direction too often, leaving their users to adapt to ever-changing APIs and configuration files. The price of doing this might be worth it if the changes are to support improvements, but frequent API/binary changes can also be a sign of poor vision or leadership.
Fitness To Purpose
This is a fancy phrase for “Will it do what you need it to”. Remember that open source software is more often created because one or more people had a need, they were going to write it anyway, and wanted to share their work. But their needs might have been different than your needs. You shouldn’t commit to using a software product that doesn’t currently suit your needs any more than you should marry someone hoping to change them. The good news is for many problems, there are many different groups that had that need and created open source solutions with different features. Maybe another one will suit your needs better. Some open source opponents consider this duplication of effort as wasted energy. I think it spawns innovation and diversity. It also means if one project goes pear-shaped, there are often other options. The cost of switching from one implementation to another can be high, though, which is why it makes sends to do your research.
Yes, I’ve mentioned this already, but it’s very important. Even a project that’s not actively being developed can be OK if it’s old enough to be stable and has a large enough community to get questions answered. Besides getting help, though, a larger user community is a good sign you will be able to find other people that know it to work with you, and that the creators will be able to find people to work on it. Even if it’s developed by a group of friends, knowing that more people are using it can offer the incentive they need to continue the project.
Reputation is a strong driving force among geeks. For instance, I am an active contributor to Stack Overflow, a website where people can ask software development questions of each other, and gain reputation points and badges for doing so. Yes, that’s all we get out of it. But the idea is so popular that they implemented about 30 different sites on the same software, but different topics. The same goes for company-based open source products. When I co-founded my Agile coaching company Agile Rules, we released open source software to get our name out there, as well as to help the community.
Creating Your Own Open Source Product
I’m currently reading the book Cooking For Geeks, which tries to teach geeks how to transfer their geek skills to the kitchen (excellent read, BTW. Reading it as an eBook on my iPhone FTW). There’s a great (and relevant) quote early on in the book.
The Internet has given the computer geek a new challenge. For most of us techies, the largest obstacle in building something great has changed from a technical one to a social one. The question is no longer can you build it, but will people want it?
Why And What
How to proceed depends on why you want to create an open source product.
- If you’re doing it because you need to solve a problem anyway so you might as well share the work that isn’t based on trade secrets, and proprietary knowledge, then not much else matters. Just do it.
- If you’ve decided to do it because you see a gap that needs filling and you have the skills, that’s great. Make sure others agree with you that it’s worth doing, and your solution will be useful to them. You can accomplish this by asking people on mailing lists, forums, and even IRC before you start
- If you’re doing it just for the ego boost and reputation, make sure you can really follow through with it. You don’t want to develop a bad reputation by raising expectations then bailing on it. Also make sure what you want to do will have a wide enough audience.
Whatever your motivation, make sure you aren’t reinventing the wheel. I once came up with an incredible design for a modular ETL program, and was already writing up UML diagrams, when some friends I told about it pointed out a similar solution already out there.
I listed some open source project hosts/software repositories above. I’m sure you can find more locally, or one specific to the domain of your proposed product. If you’re looking to develop the product with a larger community, or one that is distributed, a solution like these can give your product exposure and a stable, feature-rich infrastructure.
If you’re planning on developing your product with a smaller group of trusted people, you might consider hosting it on a separate website. That gives you total control of what’s there, what services are offered, and what it all looks like, but it’s more more work.
The minimalist option would be to go with file hosting. Resist the temptation to use ftp or BitTorrent, though. No infrastructure component could possibly be more important to a software project than some kind of version control, like Subversion hosting or Git hosting.
I will end this post (one of my longest) with a sales pitch Agile software development methodologies. Which particular flavor is up to you. Agile methodologies lend themselves well to open source product development because it’s all about empowering people to work, open communication and collaboration, assurance of quality, and a focus on working on the right thing.
Open source projects often involve a lot of R&D and changing specifications as experiments show one path better than another. Agile doesn’t expect you to know where you’re going when you start, only to define what parts you know so far. I’ve used Agile methods on project involving constant exploration and reevaluation driven by a group of Scientists, and they were very pleased how the Agile process gave them exposure into the software process, control over the priorities, and the freedom to change directions without guilt (but with knowledge of the costs involved).
Open source development groups often suffer from members leaving, going MIA, or just plain not working on what they’re supposed to. Agile’s focus on tracking work, constant collaboration, and frequent integration and demonstration points make it known sooner when someone is not holding up their end.