IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Ubuntu Linux Journal, Open Source Journal, Open Source and Cloud Computing

Blog Feed Post

Free as in Beer By @DMacVittie | @CloudExpo #Cloud #OpenSource

The things to look for in your open source project

(Note: This blog originally posted to the Stacki Open Source project website. It has cosmetic changes to account for presentation differences between the two sites)

Many years ago, I wrote a blog that aimed to help organizations evaluate open source projects in terms of enterprise suitability. That blog was lost when the employer took the publication off-line, and my Google-fu has been unable to recover a copy (if you happen to have it, ping me, I’d love a copy). At the time I wrote it, I considered blogs to be dispensable, with less need to keep a copy than articles – because they were largely opinion. Turns out that precisely because blogs are opinion+insight, you have to refer to them more to update or defend than most articles. I’ve been saving them since shortly after that particular blog was published, but that was no help here.

(Note that my interest at the time of the first article was as a writer and an open source contributor. My interest now is driven partially by open source contribution – though it’s been nearly a year since I submitted to any projects except for a minor change to Stacki – and partially because I work for an open source sponsor, thus am in the market-space a lot more)

That being said, I’ve decided to write another. I was looking for the original blog because we have gotten a bit complacent about Open Source evaluations. It seems that there is a cycle that has emerged in our industry that follows a basic trend. Evaluation of Open Source projects gets important because of spectacular failures or mergings of projects. Evaluators discover that, for the most part, the parameters being looked at are very similar to purchased software, and slowly complacency sets in. Then we do it again. The shriveling of investment money in Silicon Valley combined with the current model of Open Source sponsorship means that many projects tied to existing vendors will be struggling. The ramifications of significant sponsorship are broad, and that’s why we’re here.

But the topic is more broad than investors causing problems. Projects in the best of times lose sponsorship because the needs of sponsors change – think of Satellite and Spacewalk. Spacewalk – and by extension Cobbler and several other technologies – has seen downgraded RedHat support when Satellite moved to a new architecture. Oh, officially they’re still supported, but the investment that RedHat is willing to make is obviously reduced, as they focus on the new architecture.

And that doesn’t even touch internal project politics. How many projects are you aware of that fractured and became less relevant. The one that springs to mind for me – because I was a heavy user at the time that it happened – is the Mambo (since discontinued)/Joomla split. A whole raft of developers and designers left Mambo and forked to start Joomla, leaving us users with a tough choice – convert or hope Mambo could keep up the updates. OpenStack had a tiff that threatened to blow into similar proportions over AWS support, which thankfully sane heads found a compromise path for.

And finally, or rather what should have been considered before all of the above became an issue, is technical capability and road-map. Does it do what you need, and are you able to modify it easily if not? Hand-in-hand with these questions are security – particularly since heartbleed came about and impacted just about everyone – and user management. Can you add/remove/restrict users as needed to get the job done? Does the project support RBAC? If so, is it solid? All questions that need to be asked in an enterprise environment (and should be asked regardless of where it’s deployed).

So, the things to look for in your open source project:

  • Maturity

It still astounds me that after years of experience, multi-million dollar operations will install Open Source that is largely vaporware written by one or two people with no long term roadmap. The idea being “it’s free”, but it isn’t if you’re installing and maintaining it – we’ve documented that over the years, so don’t. Yes, this poses a dilemma for new Open Source projects, but they can show maturity and stability by growing and finding acceptance at highly technical smaller shops.

And there’s the other end of maturity. Look for drop off of developer participation, look for sniping on bugzilla or the forums for a given project – particularly between project devs. This is a sign of trouble, and usually indicates the “ownership” that grows when this piece of the puzzle has been your baby for years. But it causes issues and bad feelings, poisonous to projects from reduced bug fixing to outright splintering.

Finally, in the middle stage, the thing to look out for is acceptance of help. It’s an open source project, people should be allowed to contribute. Large stable projects generally have a process that is designed to limit code changes because they’re in use in a lot of places and need stability, but most projects should be open to direct submission of changes, probably with review by a core team. If there is no process for users to update (my favorite is “You can’t change it, so fork it” – Really? You want people to do their development and not give it back to the community? Are you open source?), updates are routinely rejected, or the project source doesn’t build relatively easily on a new machine (no open source project I’ve worked on built easily on a new machine, but guidelines and helpful tips can make it minimally painful), then you should exercise caution. Resistance to community involvement is a symptom of egos running a project. No need to walk away over this issue – as we’ve already established, some projects have good reasons to limit submissions – but certainly look closely at what those reasons are.

  • Core Developers

The heart of any open source project is its core developers. Those who are there all the time, giving their time and effort to make it a success. Relevant questions for an organization looking to use the system are simple – What experience do those developers have? Is this their first foray into either open source (which is a different political model) or the market the product is entering? How many are there? What is their history of delivering? Are they cooperative, or fragmented? Basically, you need to determine if you can trust them with a core piece of your infrastructure. The other points here touch a little on this topic, but it was worthy of a separate bullet point, because the core developers and their relationships/experience are good predictors of stability, just as the overall number of submitters and the trend in that number is.

  • Sponsorship

If a project has corporate sponsors, look to see how many there are. A single sponsor is going to over-ride user desires when there is conflict. This is not a slap at sponsorship, it is an observation that the project team is motivated to pay the bills that the project generates, and the corporate sponsor sees their needs as important for everyone, particularly if the corporate sponsor is in or adjacent to the space of the open source project. This can have a negative impact. Do you wish the system integrated as easily with competitors of the corporate sponsor as easily as the sponsor? That’s a symptom.

Over time, concerns about consortium sponsorships have lessened. While it was (and occasionally still is) a valid concern when large corporations in direct competition get together to sponsor a project, those days are waning as value-add and services replace lock-in for most corporations’ sales goals. It is still worth watching though, what are the customizations a given sponsor uses? Just like standards body participants will sometimes use the gaps in the standards they helped develop to build lock-in mechanisms, so too do some members of consortiums. It is worth being aware of, but as I said, the concern is much less than it used to be, so not worth wasting too much time on.

Considering the time, a related concern is investor money. Is your project solely sponsored by a venture-backed company? If so, make certain it is not at the whim of investors. Should they pull funding from the backed company, what happens to the project? Oh sure, it’s open source, so it can be kept alive, but don’t underestimate the temporary mayhem and loss of users – and by extension developers – that such a scenario can create. While better than a startup going out of business and leaving unsupported closed-source projects behind, it’s not a ton better unless you have developer man-hours just laying around waiting to be poured in.

  • Technical Capabilities

We’ve all seen the open source project spectrum – from flashy but not much ability to get it to work with all the other tools in your datacenter to downright pliant and designed with integration in mind. Know what your integration needs are – particularly in light of automation and DevOps developments in your organization, and make certain the project can fulfill them. In the automation world for example, it is great to have a tool that can do one thing really well, but better if that one tool can be integrated into the tool-chain you are using to give a coordinated solution to automation issues. As time goes on it will even become necessary.

Check the real cost. Yes, the software is free, but there are a variety of charges from hosting to development to ops that need to be considered, as we all know. Compare what it is likely to cost to keep product A alive and working in relation to the other projects in the space. These analysis have actually sometimes shown that you are better off using purchased software (depending of course on the market and the products) than an open source project… Considering that can be the case even once, certainly a comparison of open source projects on the same TCO grounds can give you an idea what might be a better choice.

  • Support

Another perennial conversation is support. Some open source users are happy to be self-supporting, they have the staff and knowledge to do so. But the complexity of systems and the number of applications running in your average datacenter have greatly reduced this trend. Most organizations want somewhere to go when things go wrong. Forums and Google Groups can do that, but for corporate responsibility, a vendor to get help from is often more appealing, even though it makes Open Source not free (or the famous “Free like a puppy” quote from Sun). Often a sponsoring company is willing to offer its services for a fee (full disclosure, this is the model StackIQ – my employer – uses for Stacki). While the “sole sponsorship” issue (mentioned above) is the other side of this coin, these companies tend to be less obstructive simply because they’re seeing what users other than themselves are having to deal with on a regular basis, and can offer or recommend updates that solve general problems of the user base. Just make certain you include support in TCO calculations, and if you do, don’t include nearly as many man-hours for bug/integration issues. Each open source project is different, so make certain you understand your options.

  • Security

Since I got ahead of myself and mentioned security above, I’ll just reiterate that you have a security infrastructure, how the tool integrates into it and makes use of it matters. So does how well the source is written. While amazing, yes there are still buffer overflow and cross-site scripting vulnerabilities in open source projects (though less and less as time goes on, thankfully). Find a way to gauge the security of the system based on your organization’s needs, and do the tests. No sense putting a vulnerability infested product into the datacenter if you can avoid it. If you’re not familiar with performing such assessments, OWASP is a great place to start figuring it out.

Local conditions always win versus pundit bullet lists, so of course you will have other things to add, and a list like this covers what’s important at a pretty high and condensed level. I’ve seen evaluations that were far more broad and far more detailed than this list, but my aim was to remind people to be vigilant, and do what’s best for their org, not to build an exhaustive list. Heck, this blog is already too long. Adding all that orgs look for would turn it into a book.

As I and countless others have said over and over, in the end you are going to be stuck with this software. Do some due diligence, it is no more fun to have to transition off an open source product than to have to transition off a closed source product – manhours are wasted and frustration runs higher. So a little pre-deployment footwork can go a long way.

Of course none of this should trump suitability to task – if no one else is doing the job you need done, then it’s worth getting involved and driving the OSS project further along, while getting the benefit of not having to completely re-create the wheel.

I will end how I often do… Your organization is running, which is a sign that IT as a group is delivering. Keep doing what’s best for the org, no matter what pundits like me suggest.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.