Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 2 Dec 2004 00:45:14 +0100

Hello All,

motivated by the recent exchange about a CA protocol specification, as well as 
by a number of (mostly private) discussions, I want to make some general 
remarks with regard to the way in which future EPICS functionality and 
interfaces are designed.

I wonder if a "release early, release often" policy wouldn't be a good idea 
for such future EPICS developments, at least (and foremost) with regard to 
the public interfaces.

(Side-note: The development of the ingenious AsynDriver component already 
adopted this approach to certain extent.)

(Other side-note: This is not about new minor EPICS base releases, where the 
policy is not to change interfaces if it can be avoided. It is about the 
design of completely new interfaces, sometimes providing access to new 
functionality, for future major releases.)

I believe that there are a number of people (not just me ;) who are interested 
in the design of future interfaces, but cannot -- for lack of time or 
whatever other reason -- actively take part in the development process 
itself. Typically, they are potential users of these interfaces. Such people 
could evaluate pre-releases, and thereby supply valuable feedback with regard 
to usability, consistency, missing features, versatility, orthogonality, 
documentation, etc.pp.

Apart from the simple more-eyes-see-more argument, evaluation by people who 
are not developers of components themselves, but rather users or developers 
of client code, tends to reveal weaknesses that are easily overlooked by core 
developers (who know all the internals and therefore sometimes can't see the 
wood for the trees).

Partly this is just the old debate between "the cathedral and the bazaar" 
style of open source development (see 
http://www.catb.org/~esr/writings/cathedral-bazaar). Up to now, EPICS has 
aways used the "cathedral" model for the core components. One could argue 
that it has been quite successful so far. Nevertheless, I want to point out 
the possibility that the success may not have been so much due to, but rather 
in spite of restricting the relevant discussions a small circle of core 
developers. There are a number of shortcomings in EPICS as it is today, some 
of which arguably could have been avoided with a somewhat more "bazaar"-like 
approach.

There have often been voiced concerns against releasing early versions of new 
interfaces. The perceived danger is that these will be used by people eager 
to get at some new functionality for production code or other long-term 
development investments. Thus, developers of libraries or other core 
components might be coming under pressure to further support a deprecated 
interface, with detrimental effects on progress and maintainability of the 
components in question.

IMHO, the best precaution against such (mis-)use is to unmistakably mark such 
versions as preliminary and unstable. I'd say anyone who has been clearly 
warned but still relies on them against better knowledge must carry the 
consequences themselves and partly rewrite their code each time a new version 
apears.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System