In this series: Practical Framework for the FOSS Bill, Desktops, Small Servers, and Large Integrated Systems
Small servers either run some small custom application or some auxiliary service. They are typically deployed as small projects. For auxiliary services, typical functions are: file server; print server; firewall; authentication server; name server; web server; proxy server; load balancing server; email server; and data backup server.
They can also be slightly more complex as a database-backed application. But we'll talk about application in the context of source code and development in another post.
Most small servers run as independent units; where the service is a composite of multiple servers, there should be, as a rule-of-thumb, no more than five separate units (whether physical machines or virtual machines) working together. Small servers, if they follow open standards, should be able to interoperate with any other server or desktop.
There's a greater variety of functions for small servers than for desktops, and therefore a great degree of features and flexibility. Typically, hardware and software for small servers will typically come separately. An exception: small servers can come as appliances where the integration between hardware and software is so tight that they are sold as a unit and in no other form than as a unit.
So where does FOSS come in? For the auxiliary functions mentioned (file server, print server, etc.), FOSS software are generally available, and are in fact, the preferred choice for some functions. The problem arises when a vendor introduces a server with proprietary extensions that make it work only with specific servers. This reduces the customer to a narrower set of choices, usually other products sold by the same vendor. Result: lock-in.
What provisions then are required?
As with desktops, hardware and software prices must be unbundled when not purchased as an appliance. This affords the decision-makers and auditors a clear view of the cost of the software. Just as important, all server hardware must have officially supported drivers for FOSS operating systems.
To which I propose we add the following:
1) All servers must interoperate with a FOSS-only reference server. In operation, no server must take advantage of a feature that it cannot support for the FOSS-based reference server. Likewise, the server must operate with the services being provided by the FOSS-based reference server. Candidate services for this reference server would be authentication, web, and mail forwarding.
2) Services provided by new servers must be available to a FOSS-only reference client desktop. Moreover, the services provided to the FOSS-only reference client must be exactly the same as any other client.
3) At a stretch: existing servers that cannot interoperate with the FOSS-only reference client desktop must provide the means for doing so. If the existing server cannot provide this means, no new client desktop that must use this service can be purchased.