Check out the new USENIX Web site.
BSDCon '03, September 8-12, 2003, Marriott Hotel, San Mateo, California, USA
Guidelines for BSDCon '03 Authors

[Back to BSDCon '03 Call for Papers]

Please read these guidelines carefully. They are written to help you give your submission its best possible chance to be accepted. As you know, the Program Committee can't accept every paper submitted to the conference.

The key element of a good paper is that it advances the state of the art in the BSD world. A well-written paper should acknowledge previous work done in the area, as well as current related work. Implementation of ideas and technologies that have been previously published is fine, but the paper should concentrate on how the idea or technology was ported to BSD. Performance numbers and benchmarks that document the benefits of your work are strongly encouraged. If you have any questions about whether your paper is appropriate, please contact the conference chair at

Conference Dates

The BSDCon '03 conference will be held in San Mateo, California, September 8-12, 2003. The Technical Sessions will be held Wednesday through Friday, September 10-12.

Dates for paper submissions:

  • Refereed paper abstracts due: April 1, 2003
  • Invited Talk proposals due: April 1, 2003
  • Notification to authors: May 12, 2003
  • Final papers due: July 8, 2003

The Call For Papers

For your convenience, here is a summary of the important information in the Call For Papers:
  • Authors must submit a 2-5 page extended abstract. Submissions should be written from a strong technical background and should clearly demonstrate that:
    • There is a significant problem being solved or a real world experience being demonstrated.
    • There is active work being done.
    • There is enough progress to make a complete written submission.
    • There is data proving either the success or failure of any claims.
  • Abstracts and papers should be submitted electronically in ASCII, Postscript, or PDF format via our web form. If you have questions or encounter problems, please send electronic mail to the program chair at
  • The final paper should be no more than 12 pages in length.
  • Cash prizes will be awarded for Best Paper and Best Student Paper.

What Kinds of Papers Does USENIX Publish?

The most important thought to keep in mind when deciding whether to submit a paper is "what will the audience or readers learn from my paper?" We don't expect every paper to report on a major breakthrough, but we do look for something new, potentially useful, and not entirely obvious. Think about how different your work is from previously published papers; it may be good work but it should also be an improvement over the previously published work. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems or environments? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often more important than positive results, especially in case studies.

Also think about whether a BSDCon conference is the right place to publish your paper. Perhaps it belongs in a more theoretical conference, or a conference with a different kind of focus. We encourage theory papers with a BSD focus. Papers, theoretical or otherwise, that do not have a BSD focus should be submitted to the USENIX General Technical Conference. If your paper would be very short or is more of an opinion piece, it might be more appropriate for the USENIX newsletter ;login:. Also try asking if the reader would find the paper interesting, and try asking them to identify the most important aspects of your paper.

When you are writing your paper, keep in mind "what do I intend to teach the reader?" That means keeping the paper focused on one or a few main points. Don't try to cram too many big issues into the paper, and don't fill it up with irrelevant details. Do include enough background for the reader to understand why your problem is important, how your work relates to previous work in the field, and how it might fit into a practical system. Also, provide enough detail for the reader to put your performance measurements or other technical evaluation in context. It is vitally important to provide a good bibliography, both so that you give proper credit to previous work, and so that a reader can know where to turn to find additional background information. The Program Committee will not look kindly on a paper if the author doesn't appear to be familiar with the current literature. A complete list of papers previously published by USENIX is available at If you have questions, feel free to ask the Program Committee.

What Do We Mean By Extended Abstract?

An "extended abstract" might better be thought of as a "condensed paper". The Program Committee will be trying to evaluate your final paper, not merely whether the work you are reporting on is good. This means that we will view the extended abstract as a sample of your ability to write clearly about your topic, to organize your paper, and to convey sufficient information to the readers. This also means that outlines, copies of presentation slides, or 1-page abstracts will be returned for resubmission. In addition, the Program Committee will also try to judge if the final paper will lead to a good 25 minute talk.

When you write an extended abstract, you are explicitly leaving things out of the paper. Each time you do that, ask yourself, "Will it make it hard for the Program Committee to judge my paper?" There are no easy rules to follow here: something that might be vital in judging the value of one paper would be irrelevant detail in another case. It's best to leave out things that take a lot of explanation but are not central to the main point of the paper. You might also leave out descriptions of variations on, or extensions to, the main concepts. Don't leave out references to related work, but you can probably reduce this part to an explanation pitched to the Program Committee, rather than an "introduction to the field" written for the benefit of a non-expert reader. Include graphs, figures, and tables that are central to understanding the paper! We don't count these against the 4-page limit, because they make an extended abstract easier to read. Try to design figures that can be understood without lots of explanatory text.

Also, it's perfectly okay to write notes to the Program Committee in your abstract! Tell them why you left something out, if a section may be fundamentally changed in the final paper, or similar comments that will help them better understand your abstract.

More Information On How To Write A Good Paper

We recommend that you read the proceedings of some recent LISA conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect, but most of them are better than most of the papers that did not get accepted. A few papers to consider are:

John Viega, Barry Warsaw and Ken Manheimer "Mailman: The GNU Mailing List Manager" Proceedings of the Twelfth Systems Administration Conference (LISA '98)
Extended Abstract: PDF   Full Paper: PDF | HTML

Tom Limoncelli, Tom Reingold, Ravi Narayan, Ralph Loura "Creating a Network for Lucent Bell Labs Research South" Proceedings of the Eleventh Systems Administration Conference (LISA '97)
Extended Abstract: PDF   Full Paper: PDF | HTML

You can also refer to the "USENIX Online Library and Index" (at for additional papers that may be of use.

Finally, if you have any other questions, at any time during the entire submissions process, especially if you have a paper idea but have concerns about it not being "right" for the conference, please send mail to the Program Chair at

Good Luck,
The Program Committee

?Need help? Use our Contacts page.
Last changed: 30 Dec. 2002 aw
Events calendar