Commercial Use articles focus on functional programming "as a means, not an end". As such, we solicit papers about experiences using functional languages in commercial and open source settings. The purpose of a Commercial Use article is to document and assess cases where functional programming was used in a real world setting. We are interested not only in successes, but also in failures. Articles should distill experiences using functional languages so that others can learn from those experiences, whether the lessons learned be technical, organizational, or about the narratives used to make the case to management.
A Commercial Use article is distinguished from a normal JFP paper by its title, its length, and the criteria used to evaluate it. The title of each accepted Commercial Use article must begin with the words "Commercial Uses'' followed by a colon. Commercial Use articles will typically, but not necessarily, be shorter in length than normal JFP papers. The suggested length is 5 to 10 JFP pages.
A Commercial Use article should make clear points about the efficacy of functional programming and provide supporting evidence. The content of the article must be relevant to JFP, but it need not be novel. The editors will accept or reject Commercial Use articles based on whether they judge the material to be relevant and the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. The editors will be especially convinced by evidence that includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people.
A Commercial Use article should be short and to the point: if functional programming worked for you in the same ways it has worked for others, you need only to summarize the results, the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterise your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. While we want you to be as specific as possible, we do not want you to give away any trade secrets!
If you are considering writing a Commercial Use article, the following list suggests some questions you might want to address in your article:
A single article need not address all these questions. Nor should it simply list the questions and provide answers to them. Rather, it should tell the story of your project and use of functional languages.
If you have questions about these guidelines and whether to submit a particular article, please feel free to contact the editor.