Title: A Response to the C++ SIG Organiser

I take the editorial provided by Alan Griffiths for this issue very seriously. As time is short, I am sticking my neck out and responding here.

Back in 1987 a band of enthusiasts created a newsletter for C programmers and named it C Vu. By 1990 this had expanded to a regular periodical covering both C and related languages. Between its covers, you found a mix of articles that would scare a newcomer witless down to ones that expert programmers found trivial. Generally, the extremes learned to ignore each other. Errors in articles written by well-intentioned (but not always well-informed) enthusiasts (including me) were gently corrected by more knowledgeable readers.

Early in the 1990's (I forget the exact dates) the then C Users Group (UK) absorbed 'The European C++ Users Group.' The latter contained a great deal of technical expertise but those actually doing the administration left a good deal to be desired and had never really met the initial promises (such as a regular newsletter and a bi-annual conference). In the same time frame we learned of a band of Borland C++ enthusiasts who were preparing to launch a specific user group for that product and launch a newsletter: Overload. We managed to prevent this potential source of fragmentation. CUG(UK) became ACCU and now had two periodicals, Overload for C++ specialists and C Vu for everyone, including specialists who were not interested in C++.

Overload was strictly for the C++ SIG of ACCU. It set a model for a SIG newsletter that was shortly emulated by the Acorn RISC enthusiasts with the development of a smaller but regular newsletter called CAUGers. Until Acorn effectively pulled out of the desktop market, the Acorn developers' SIG had a membership of nearly 200.

Throughout the 90's the apparent calm that existed between our publications actually hid a deal of discontent from the editors. The early editors of Overload wanted pure C++. Sean Corfield wanted to expand into more general areas that would be of interest to the wider range of programming specialists and became increasingly frustrated with the limitations imposed by Overload being tightly coupled to the C++ SIG. He felt that good books for specialists should be reviewed in Overload rather than C Vu. I resisted on the grounds that good books deserved to be known of by all programming specialists, not just those that paid a premium for a mainly C++ periodical.

There was also a degree of conflict between CAUGers and C Vu (and eventually, to a lesser extent with Overload) because a proportion of the articles being published there were of more general interest.

Periodically C Vu incorporated sections edited by enthusiasts for some special aspect. In such cases I always published their section though editorial responsibility lay with the organiser of the section. Even if each specialist section lasted for a relatively short time, the principle that C Vu was a portmanteau publication was established.

Over the last year there has been a great deal of discussion about the organisation of ACCU and its publications. One change was to the membership structure. SIGs can exist and fund there own newsletters (the parent body will even be sympathetic to providing a degree of financial and other support). However we decoupled Overload from the C++ SIG and created a two tier membership: 'Basic,' open to anyone and 'Full' aimed at specialist programmers, software engineers and the like. C Vu would publish general administrative items and material aimed at (well the trouble is that pinning a title to the target readership can seem paternalistic, derogatory etc.) The basic intent was that C Vu material should be relevant and interesting to non-expert programmers. The second publication (perhaps we should have changed its name) was to go to all Full members. I think that means that its content should be appropriate to such members. Where should a section aimed at embedded C developers go? Where should material on methodologies go? Where should reviews of books for specialist programmers be published?

For example, two members are proposing to run a section for Java programmers, initially as an independent section of C Vu. Does that mean that in future articles such as Peter Pilgrim's 'An Implementation of Double Dispatch in Java' go to that section and be published in C Vu. I would hope that past lessons would suggest that that is a poor solution. I would prefer to see both periodicals find space for material provided by the 'Java Specialist Editor' and that that material is the editorial responsibility of that editor, just as material published under the CAUGers banner is the editorial responsibility of Tom Hughes. The concept that I have is of a number of independent editors being responsible for material in their subject area (for example I would very much like to see an 'Embedded Programming' section and have an idea as to who might make a good editor for such a section. Generally it is very clear as to which of our two titles should publish specific articles (if we stick with the concept of one publication, currently called Overload, being for specialists. Sometimes it would be a judgement call. Who should make that call? In general, the editor of the section. The 'editor in chief' who should be the person who works with the production editor will need some latitude (helpful sectional editors will indicate items that they think could go either way) so that our periodicals are produced to professional standards. I think that 'the editor in chief' needs to be easily available to the production editor. That is a real problem in a distributed organisation. There is virtually no business time overlap between someone in California and someone in London.

Before I conclude, look at the way book reviews are organised between C Vu and Overload. For PR reasons, we need a single person responsible for co-ordinating the process from acquisition of title to publication of review. As that person, I have an option with a review in that I can always just publish on our website. However it may surprise some of you to learn that there are still members who do not have web access (indeed one contributor to our publications has to send me material as hardcopy because he has no compatible electronic mechanism) so I always try to ensure that it is books that would seem to require Internet 'understanding' that get relegated to electronic publication only.

You may not have realised that under the new regime C Vu is strictly limited to 32 pages (I cheated last time by usurping the inside front and back covers, but will not be allowed to get away with that again) and Overload is limited to 28 pages (again, we do not have the right to use cover space)

I think the membership needs to think very carefully about how our publications are organised. We must learn from the past (or be forever doomed to relive it). I think any coherent programming section with a defined editor (it is up to the Committee to accept or reject offers) should have a right of access to our publishing real-estate. It is not like the Internet where you can just expand the space. Both competition and co-operation have something to offer. Co-operation to provide content for our periodicals and competition between editors to provide a section they can feel proud of.

One final point needs addressing urgently and that is developing an editorial structure that does not largely depend on a single individual. Currently ACCU wants to retain sole responsibility for editorial content while contracting out the production process. That only works because I can change hats on the fly. I understood the original offer from Centaur Communications was based on ACCU providing someone for at least two days every two months with the authority and the knowledge to make editorial (rather than just production) decisions. If the material will not fit the space, someone has to have the authority to drop it or change it. Even such things as code presentation are outside the scope of a normal production editor (and believe me, you would hate what you would get if you left it to their tender mercies)

What we need is constructive ideas and willing volunteers. We need an organisation that can work with voluntary labour, and one where such volunteers feel a warm sense of satisfaction with what they have contributed. To be honest, that sense of satisfaction is missing from my contributions at the moment. Though I am paid for part of it, much of it is done by me simply because I cannot do the paid element unless the voluntary side has been done by someone (and I am someone, but so are you, gentle reader). I take a pride in all aspects of my work, and take it very personally when things go wrong.