[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
The BSDCon '03 conference will be held in San Mateo, California, September
8-12, 2003. The Technical Sessions will be held Wednesday through Friday,
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
- There is a significant problem being solved or a real world experience
- 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
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
The Program Committee