The concern over the future of Centos is fair, but why not use Scientific Linux if it is producing the core that ClearOS needs?
The way I see it the value ClearOS delivers is not in the core, but the administration interface and web services. I can be talking to a another IT person and say "it's Centos with a user-friendly front-end" and they understand exactly what the value proposition is. My concern is that ClearOS Core ceases to be 100% RHEL compatible, and we are left with a distribution that cannot take advantage of new developments and existing repositories.
I have put ClearOS into a number of businesses and I am not against development that delivers more value and/or encouragement to purchase a ClearOS subscription. My only concern is that this doesn't dilute or distract resources from the more important long-term issues that are centered around the administration and monitoring suite of tools ClearOS provides.
I used ClarkConnect and I remember the announcements that took place when the "core" was moved to Centos so that the ClarkConnect developers could be freed to focus on the front-end configuration tools. With a release of a Centos 6 beta nearing I do not understand the logic behind a move back to a custom core. As ClearOS is targeted at a server environment I struggle to see the advantage of moving away from a core that has such a strong reputation and installed base. The best aspect of ClearOS is that it took Centos and made setting up a Samba/LDAP service a painless, the only disadvantage being that there was no 64bit ClearOS, which was no fault of Centos.
Can you please explain how this move will maximize your capability and the potential of ClearOS, because from where I am sitting it appears only to be further diluting an already thin development resource?
i.e. There are many functional holes in ClearOS that can be filled without changing cores.
If the answer to this question is that you will be better able to create the ultimate Active Directory replacement with Samba4 and Bind that is great, but if it is just to have a couple of shiny new kernel modules that have no place on a server then there is a problem.
Comments 
The concern over the future of Centos is fair, but why not use Scientific Linux if it is producing the core that ClearOS needs?
The way I see it the value ClearOS delivers is not in the core, but the administration interface and web services. I can be talking to a another IT person and say "it's Centos with a user-friendly front-end" and they understand exactly what the value proposition is. My concern is that ClearOS Core ceases to be 100% RHEL compatible, and we are left with a distribution that cannot take advantage of new developments and existing repositories.
I have put ClearOS into a number of businesses and I am not against development that delivers more value and/or encouragement to purchase a ClearOS subscription. My only concern is that this doesn't dilute or distract resources from the more important long-term issues that are centered around the administration and monitoring suite of tools ClearOS provides.
I used ClarkConnect and I remember the announcements that took place when the "core" was moved to Centos so that the ClarkConnect developers could be freed to focus on the front-end configuration tools. With a release of a Centos 6 beta nearing I do not understand the logic behind a move back to a custom core. As ClearOS is targeted at a server environment I struggle to see the advantage of moving away from a core that has such a strong reputation and installed base. The best aspect of ClearOS is that it took Centos and made setting up a Samba/LDAP service a painless, the only disadvantage being that there was no 64bit ClearOS, which was no fault of Centos.
Can you please explain how this move will maximize your capability and the potential of ClearOS, because from where I am sitting it appears only to be further diluting an already thin development resource?
i.e. There are many functional holes in ClearOS that can be filled without changing cores.
If the answer to this question is that you will be better able to create the ultimate Active Directory replacement with Samba4 and Bind that is great, but if it is just to have a couple of shiny new kernel modules that have no place on a server then there is a problem.