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?
