Open Source NAC, But Only With Commercial Support

There are many reasons to not consider open source NAC, the first of which is how much workload do you want to put into your NAC solution, above and beyond having to figure out what you want your NAC to do for you, laying out policies, ensuring that your network architecture will support NAC, deploying the product, managing endpoints, and a bunch of other little things that in totality add to your workload. If you work for a university where you have a large pool of talented, but cheap, labor (interns), then an open source project might make sense because you have people who can manage and maintain the system. Task an employee as a project manager and make sure you get your work done during the semester. However, enterprises don???t have the luxury of a cheap labor pool.

So keeping the education/enterprise distinction in mind, I found that David Davis??? TechRepublic SolutionBase article, Discover Open Source Alternatives For NAC On Your Network, makes a few common mistakes about open source. Davis gives a nod to pitfalls with open source NAC, but the problems can be far more significant for an enterprise than just a pitfall.

First, there are no open source NAC projects that vendors see as a threat and so open source NAC projects won't keep vendors on their toes. I spend quite a bit of time talking to vendors and none of them mention open source NAC. Now, it could be that some vendors aren't aware of open source projects, but that would assume some vendors are aware. However, none of them has mentioned it. The silence tells me these projects aren???t popping on vendors' radar, and, in turn, that means they aren't popping onto enterprises' radar, either. The same holds true for standards development. Unless the open source projects are active in the various workgroups, there's no impact.

Next, I hate the too-common statement that with open source, you have control -- you can view the code, find bugs, and add your new features. If programming were that easy, we'd all do it. But programming isn't easy. Taking an existing large software project and understanding the code, then modifying it, is extremely difficult and time consuming. I don???t know many IT admins who have the time to write code, much less analyze a large project and contribute. Basically, if you don't have the time or skills to write code, then you're no better off with open source than closed source.

Finally, the support issue. This one is critical for enterprises. The benefit of a support contract is key because if your NAC starts to fail, you don???t have days or weeks to resolve a problem. You need it fixed now, not later. I guess it doesn???t matter whether you're using an open source NAC or not if you have a crack support team that can get you out of a jam. But I bet the support contracts limit the ways customers can modify the NAC installation, which I think would be reasonable. If you purchase a support contact and the vendor comes in and help you get it working, and then you add a patch you found off a forum that breaks your installation, why should the support vendor be held responsible?What You Can Expect With Open Source

Now, I haven't looked at any of the open source NAC projects in any depth, so I don???t know how effective or stable they are. But I do have some 13 years experience as a user of open source projects large and small. Let me take the time to say that I am constantly thankful that there are people who work very hard on open source projects. The IT world would be a much different, and possibly less rich, place without high-quality open source. I don't buy into the warm, fuzzy notion that open source imbues this magical support quality to the various projects.

The problems are easy to articulate but difficult to solve. There is little benefit from having the source code available to users who aren???t programmers or don't have the time to contribute to projects. The documentation for many open source programs (commercial products, too) is often horrible and rarely provides much value beyond high-level features and functions. The breadth and depth of forum support can be spotty, largely depending on how well you can articulate your problem to begin with. New open source projects simply haven???t acquired the community support needed to answer many uncommon questions (the common ones are easy). The combination of those things lays the burden on support on your staff and can very likely leave that no-cost-for-software open source NAC as effective as a random pile of bits.

You shouldn???t have any expectation that the open source community will help you solve your problems. You can't really cajole volunteers to spend time on your problem on your schedule. There's nothing binding them to you other than their goodwill. If you don't like this open source project and go find another one, fine, what impact do you have on the project? None. It's not like you're taking money out of their pockets or food off their table.

When you accept an open source application without a commercial support contract, you accept the full burden of support for the application. If you have the staff in-house that you can train and can dedicate to the application, then you're in good shape (and you should, of course, give back to the project). If you don't have the people with the necessary skills, avoid open source.1011