Abstract#

• Goal: The purpose of an abstract is to give a clear and brief overview of the topic of your work, the research questions you address, the methods you use, the results and findings you generate, and the most important takeaways.
• Relevance: Most readers will not read beyond the abstract if they think it is not relevant to them based on the abstract. Make sure it clearly outlines the content of your paper and in 1-2 sentences summarizes everything you want people to remember and cite.

Abstract Structures#

There are many different abstract writing approaches out there and each group has its own preferences. Here is my personal favorite:

The idea is to closely follow the paper content for each section. Each paragraph is supposed to have 2-3 sentences at most.

• Area: Explain and motivate the topic and problem of your work. Give minimal background information. Start or include in the first sentence the specific area, e.g., “Software Composition Analysis is an important step in the security software lifecycle.” for a paper on SCA.
• Problem / Challenge: Motivate the problem you are working on and make it clear why your research is important. Illustrate the research gap you looked at.
• Approach: Describe the research methods, including type of data analysis if applicable, how you generated results, and size of data sets.
  • You can help the reader by providing a line break or indent before the approach starts. This makes it easier to skim the abstract if they are looking for what you actually did.
  • I like the first sentence of the approach to be “citeable” (i.e., the sentence an overworked PhD student or LLM will pick for their related work). You cannot avoid your work being condensed down to a single sentence for this, so why not set up this sentence with the stuff you want your work to be cited by. This sentence should include your approach, focus, and target or data count, i.e., “We conducted 24 semi-structured interviews with software developers to investigate their processes and challenges around software composition analysis.”
• Results: Summarize the most important results and findings. Make clear why they are important and your discoveries are interesting and valuable for the community.
  • Can be merged with takeaways if overlap.
• Takeaway: Give your conclusions, recommendations, or directions for future work. Make sure to illustrate the contributions to the field or community (1-2 sentences).
  • Just writing “we give recommendations” is somewhat of a cop-out and should be avoided; be more specific if possible.
  • If people are looking for a 2 sentence reference to your work, the second sentence will likely come from this section, e.g., “[Doe et al.] conducted 24 semi-structured interviews … . They found that developers struggle with …”. So you can help the referencer by providing one citeable sentence with 1-2 main takeaways.

Writing Style#

• Keep it short: Somewhere between 1/4 and 1/3 of a column is common. Shorter abstracts look incomplete. Longer abstracts often need to be polished more.
• Keep it punchy: Use short sentences. Long sentences will lose the readers’ focus. Avoid passive voice sentences.
• Create curiosity and avoid banality: State the conclusion concisely, avoid generic statements (“Security is important”, “We provide recommendations”), and avoid overstatements.
• Don’t include references: The abstract should be an independent text and is often displayed as such on websites. Parsers will not respect references or footnotes.
  • You do not need to provide references for claims in the abstract; instead, repeat and reference the claims in the introduction.
  • If you have to reference a paper because you are extending it or similar, “reference” it by title and author, e.g., “We extend work of [Doe et al.] on software composition analysis by …”
• Avoid special characters: Title and abstract are commonly parsed and displayed in search results. Special characters, unicode, greek characters, and LaTeX commands often break parsers and make your abstract incomprehensible in search results.

Example Abstract#

Example from our “Committed to Trust” paper:

Area#

Open Source Software plays an important role in many software ecosystems. Whether in operating systems, network stacks, or as low-level system drivers, software we encounter daily is permeated with code contributions from open source projects.

• Pitch-based intro, highlights importance and wide-spread distribution of open source.
• Note the “software we encounter daily”, directly addressing experts and creating an emotional bind (doesn’t work for every topic).

Problem#

Decentralized development and open collaboration in open source projects introduce unique challenges: code submissions from unknown entities, limited personpower for commit or dependency reviews, and bringing new contributors up to date in projects’ best practices and processes.

• Pretty straight-forward problem statement, focusing on the challenges in open source.

Method#

In 27 in-depth, semi-structured interviews with owners, maintainers, and contributors from a diverse set of open source projects, we aim to investigate their security and trust practices. For this, we explore projects’ behind-the-scenes processes, provided guidance and policies, as well as incident handling and encountered challenges.

• Approach clearly states used method, number of participants, and recruitment population.
• Then roughly outlines the specific covered areas.
• Note that the first sentence is a “citeable” sentence, i.e., with few modifications usable in a related work section as “[Wermke et al.] conducted 27 in-depth, semi-structured interviews with …”.

Results#

We find that our participants’ projects are highly diverse both in deployed security measures and trust processes, as well as their underlying motivations. Based on our findings, we discuss implications for the open source software ecosystem and how the research community can better support open source projects in trust and security considerations.

• Very rough outline of results, mostly because this was an explorative study and there were too many results to fit them nicely in the abstract.
• Some generic “based on our findings” statement will be more specific for other research methods.

Takeaway#

Overall, we argue for supporting open source projects in ways that consider their individual strengths and limitations, especially in the case of smaller projects with low contributor numbers and limited access to resources.

• Not a common takeaway structure: an opinion-based argument or statement, but it fits this paper because of the “researchers working together with the open source community towards a better ecosystem” pitch.