How relevant are personas in open-source software development?

Introduction: Open-source software (OSS) projects, characterized by distributed development and volunteer contributions, face challenges in prioritizing user-centered design and usability. This difficulty arises because these projects are primarily driven by developers who focus on technical contributions. As a result, usability and user experience (UX) considerations are often neglected, leading to software that may not meet the needs of its broad and diverse users.

Methods: To address this issue, we explore the potential of using user personas which are fictional characters representing real user groups, to enhance user-centered design in OSS projects. Personas promote empathy and a deeper understanding of user needs, thereby improving alignment between developers and users. We conducted an experimental study on three OSS projects: Moodle, Lichess, and Audacity. Personas were created for each project and refined based on feedback from industry experts.

Results: Developers rated personas highly for credibility (86%), consistency (79%), and friendliness (86%), highlighting their relevance in OSS projects. A follow-up experiment with students confirmed these findings, with consistency (79%) demonstrating personas' role in improving usability and aligning developers with user needs.

Discussion: While adoption remains limited due to technical priorities (only 14% of developers and 34% of students found personas useful and expressed willingness to adopt them), personas show significant potential to enhance user-centered design in OSS. Further research is needed to understand developers' reluctance to adopt this technique and explore strategies to integrate personas more effectively into OSS workflows. This study's novelty lies in its empirical exploration of personas within OSS, providing quantitative evidence of their effectiveness in improving usability and user-centered design.

1 Introduction

Open source software (OSS) has revolutionized software development by fostering collaborative, community-driven innovation through its open inspection, use, modification, and redistribution of source code. The collaborative approach has significantly impacted the software industry, leading to the development of high-quality software (Crowston et al., 2008), fostering innovation (Von Krogh and Von Hippel, 2006), enhancing security (Raymond, 2001), improving reliability (Feller and Fitzgerald, 2000), and reducing development costs (Rajanen, 2011). These diverse benefits have driven the exponential growth and popularity of OSS. Projects such as Linux, Apache, and Firefox exemplify these benefits, showing substantial increases in both user base and code contributions (Deshpande and Riehle, 2008; Raymond, 2001).

Despite these numerous strengths, OSS projects face significant challenges in usability–a key quality attribute defined by ISO 9126-1 as “the capability of the software product to be understood, learned, used, and attractive to the user when used under specified conditions” (ISO/IEC, 2001). Several studies have identified critical usability challenges within OSS projects that need to be addressed to ensure broader user adoption and satisfaction (Rajanen, 2023; Rajanen and Iivari, 2019; Cheng and Guo, 2018; Masson et al., 2017). These challenges are largely attributed to the lack of User-Centered Design (UCD) practices, which, as revealed by the literature, are due to the governance models of open-source projects. In fact, the decision-making process is generally driven by developers who are not usability experts and tend to value code and technical contributions more than usability and UX Design-related contributions. Decisions are often based on their own preferences, neglecting the needs of users who do not belong to the developers' community (Rajanen, 2023; Cheng and Guo, 2018; Masson et al., 2017).

To address these usability issues, our research explores the potential of integrating user persona–a proven UX design tool–into OSS development processes. Personas, defined by Cooper as fictional characters representing real user groups, help bridge the gap between developers and end-users by reducing self-centered bias and enhancing empathy (Cooper, 1999; Nielsen, 2012). Despite the extensive use of personas in the software industry, their application in OSS remains underexplored. Our review of the literature highlights a significant gap in their application within OSS projects. Our Google Scholar search using keywords like “personas” or “user personas” alongside “Open source,” “Open-source software,” or “FLOSS” indicated that personas are rarely used in OSS. The most relevant work, a study by Llerena et al. (2016), noted that few papers discuss the use of personas in this context.

Our study seeks to address this gap by investigating the benefits and challenges of using personas in the development of OSS.

To explore this further, we selected three high-active, popular, and diverse OSS projects to ensure a representative sample of applications across education (Moodle), gaming (Lichess), and audio editing (Audacity). Our methodology involved collecting user data through surveys, creating and refining personas based on this data, and gathering feedback from developers and students to assess the impact of personas on enhancing UCD. Specifically, we used Persona Evaluation Constructs to assess various attributes such as personas' credibility, clarity, completeness, consistency, empathy, and overall usefulness. This approach allowed us to measure their effectiveness in bridging the gap between developers and end-users, with the goal of enhancing the usability and user experience in OSS projects.

Based on these observations, we formulate the following research questions:

1. How aware are open-source developers of the benefits of personas, and how frequently are personas utilized in popular open-source projects?

2. In what ways do personas enhance the understanding of user needs and improve usability in open-source software projects?

3. In case using personas does solve the problem of poor user-centered design, why is this technique not popular in open-source software?

In response to these research questions, this study makes the following contributions:

• Gap analysis in OSS practices: by analyzing documentation from popular OSS projects on platforms such as Openhub and CodeTriage, we identify the absence of publicly available personas as a tool within the OSS contributor community. This finding highlights a significant gap in current OSS practices and opportunities for improvement.

• Assessment of personas in OSS: we conducted empirical studies with OSS developers and software engineering students to evaluate their perceptions of personas using well-established persona evaluation constructs. These constructs were extended to the OSS domain to assess the credibility, clarity, completeness, consistency, empathy, and overall usefulness of personas in enhancing user-centered design (UCD).

• Data-driven insights into persona adoption: our findings highlight both the strengths and limitations of personas in OSS contexts, revealing their role in fostering empathy and understanding of diverse user groups while identifying barriers to their broader adoption.

Our findings show that while personas are perceived positively across attributes such as credibility and empathy, their adoption in OSS development remains limited due to technical priorities and developer disinterest in usability aspect. These results underscore the need for tools to integrate UCD practices into OSS workflows effectively.

The remainder of this paper is structured as follows. We will first present our review of the related literature, then describe our methodology. The following sections will cover the results found and our discussion. Finally, the last section outlines the conclusion and opens perspectives for future research.

2 Related work

2.1 UX design and usability issues in open source software

Several studies have highlighted significant shortcomings in the implementation of UCD within open-source software (OSS) development, emphasizing a lack of attention to usability. Cheng and Guo conducted an exploratory study that highlighted the absence of UCD techniques in OSS projects (Cheng and Guo, 2018). They also raised the fact that OSS projects suffer from poor usability issues, referring to the work of Masson et al. (2017). Rajanen (2023) further affirmed the limited engagement of open-source projects in UX design. In a literature review, Raza et al. (2012) concluded that Open-Source Software projects suffer from neglecting usability issues, emphasizing the need for more attention to user-centered design. These studies delve into the challenges of poor usability in open-source software projects, attributing them to various factors, including the lack of resources and tools to monitor UX Design progress; as specifically mentioned by Cheng and Guo (2018) and Wang et al. (2020). However, a key aspect lies in the nature of such projects, where numerous contributors predominantly develop based on their individual needs, resulting in a bias that favors developers and neglects the non-technical user base (Cheng and Guo, 2018; Masson et al., 2017; Raza et al., 2012; Terry et al., 2010; Wang et al., 2020).

Cheng and Guo highlight that even discussions aimed at gathering insights from the contributors' community tend to prioritize technical aspects over usability. This is mainly because participants are mainly developers who assess issues based on their own technical preferences (Cheng and Guo, 2018). Thus, end users often find them intimidating to use (Hellman et al., 2022). This issue is particularly pronounced in projects that don't necessitate advanced technical knowledge for usage. In such cases, where the projects aren't programming libraries or frameworks, the contributing community may vastly differ from the user community in terms of their expertise and needs.

Wang et al. (2020) surveyed OSS contributors and found that communities prioritize system-centric goals over user-centric design, emphasizing the need for tools and practices to improve user engagement and support UCD in OSS.

Martinelli et al. (2024) conducted a systematic literature review identifying 38 UX practices and 52 associated methods, techniques, and tools used across the broader software industry, including long-term UX practices. They highlighted challenges such as difficulty maintaining user participation and limited adoption of user-centered practices. These findings highlight systemic usability gaps beyond OSS, emphasizing the need for improved practices across the software industry.

Bradley et al. (2021) introduced the concept of systemic UX, a holistic approach to minimizing negative experiences for all users within a system. Nichols and Twidale (2006) similarly observed that many OSS teams rely primarily on interface construction tools (e.g., Glade) and lack structured usability evaluation processes, particularly for non-web applications. They stressed the need for accessible tools for communities with limited UX expertise.

In response, Raza et al. (2012) proposed the Open Source Usability Maturity Model (OS-UMM), a structured framework to evaluate usability practices based on input from developers, contributors, users, and industry stakeholders. However, while the model highlights important areas, it doesn't provide clear, and practical guidance for developers, which makes it hard to apply in real OSS projects.

Iivari (2009) also found that user needs in OSS are often only symbolically acknowledged, with technical priorities dominating. In support of this, a mapping study by Dawood et al. (2019) characterized existing OSS usability efforts as fragmented and ad hoc, highlighting inconsistent adoption of usability techniques across projects and a lack of clear processes.

These findings reinforce the need for more systematic and developer-friendly approaches to usability, particularly ones that can be integrated into existing OSS workflows with minimal disruption. In this context, the present study explores personas as a lightweight and adaptable method for embedding user perspectives into the OSS development process, aiming to bridge the gap between technical focus and user-centered design.

2.2 The use of personas in open source software development

There is a significant research gap regarding the use of user personas in OSS development. Our Google Scholar search revealed that personas are rarely used in OSS. The only notable work we found was by Llerena et al., who explored how to adopt the personas usability technique within the OSS development process, particularly in a real OSS project called PSeInt. They used a case study research method and community participation to identify obstacles and modify the technique for better applicability (Llerena et al., 2016). To further investigate the use of personas in open-source software development, we manually checked the documentation of randomly selected popular open-source projects from Openhub and CodeTriage. Two online databases that contain a list of popular open-source projects to contribute to. However, our search failed to identify a single published persona designed to assist the contributor community in these projects. This absence underscores the rarity of personas being employed as a tool within the open-source community.

2.3 The use of personas in software development

We extended our literature review to investigate the use of personas as a UX Design technique in software development in general, not just open-source software. Several works explored the use of different UX techniques in Software Development, including Personas. (Parizi et al. 2020), (2021) discussed the integration of Design Thinking techniques into software development processes across various teams, from startups to large corporations, and referred to user personas as a possibly most suitable technique for a specified context. Pruitt and Grudin discussed the extended use of personas in the computer software industry, emphasizing their effectiveness in engaging team members in small and large projects. Their findings underscored the need for effective and considered use of Personas as a powerful tool in software product development (Pruitt and Grudin, 2003). Billestrup et al. conducted a literature review on the utilization of personas in software development across companies within a specific region. Their findings revealed that a significant proportion of the respondents did not know the technique, attributed to a set of challenges such as lack of knowledge of the technique and lack of time and funding resources (Billestrup et al., 2014b). In another work, Billestrup et al. conducted a case study to understand how personas are perceived and utilized in software development industry. They interviewed four software developers who have actively worked with personas. The respondents viewed personas as a valuable technique with a strong focus on end-users (Billestrup et al., 2014a). More recently, Wang et al. (2025), in a survey they conducted, found that 46% of respondents consider personas a priority approach in software development and 54% reported that using personas can improve the success of software projects, highlighting their role in supporting user-centered practices.

3 Methodology

Since the use of personas is not very popular among open-source software projects, we decided to follow an approach where we create appropriate user personas for different open-source projects and then assess the developers' perception of these personas. Our study involves two distinct processes: experimentation with developers and experimentation with students.

3.1 Experimenting with developers

The process of experimentation with developers, summarized in Figure 1, involves five steps:

Figure 1

Figure 1. Process of experimentation with developers.

First, (A) we selected three OSS projects. (B) We gathered user data through well designed surveys and created detailed user personas based on this data. (C) Detailed personas were then developed based on the collected survey data, representing the diverse user segments of each project. (D) The personas were then refined with feedback from industry experts. (E) Following this, evaluation surveys were created to assess the personas. These refined personas and surveys were shared with developers to evaluate their perception, and the collected feedback was analyzed. Each step corresponds to a specific block in the diagram (from A to E) and is detailed upon below:

3.1.1 Projects selection

We set the following selection criteria for candidate OSS applications:

• Diversity of application domains: the projects should represent different application domains. This diversity enables assessing personas' effectiveness and usefulness across various OSS contexts.

• High activity: the project must be categorized as “Very High Activity” on OpenHub, ensuring a robust and active user base. This criterion indicates several contributors, frequent commits, and ongoing issue resolution, reflecting the project's dynamism and the community's engagement.

• Non-technical user base: projects that do not require programming knowledge for usage, such as frameworks and libraries, were avoided to prevent potential biases. Additionally, selected projects should be ones we are familiar with and have used before. This is crucial because, in such cases, the developers' community might represent an important part of the users' community, which could potentially bias our results.

Based on these criteria, we selected three different open-source projects:

• Moodle: an open-source learning management system.

• Lichess: an online chess playing platform.

• Audacity: an open-source audio editing software.

Audacity¹ and Lichess² both primarily host their code on Github and use the Github issues tracker to track their issues. While Moodle uses Gitlab to primarily host its code,³ and use its own issues tracker.⁴ Although, Moodle does have a public mirror for its source code on GitHub.⁵

Based on the information indicated on their GitHub repositories, issues trackers, and on the corresponding project page on Openhub, we gather different data about the projects. To provide a comprehensive overview, we initially accessed code repositories (GitHub for Audacity and Lichess, GitLab for Moodle) to extract metrics such as commits, contributors, and lines of code. We then reviewed issue trackers to analyze the number of open issues. Additionally, we verified project activity levels and supplemented our data using OpenHub's “Very High Activity” categorization. Official project pages and documentation provided further details, including project licenses and other relevant metadata. We summarize them in Table 1, providing key metrics such as license type, number of stars, open issues, commits, contributors, year of first commit, and lines of code. All the information indicated in this project are retrieved online at the time when this section of the paper was being written.

Table 1

Table 1. Key metrics related to the selected open source projects.

To conclude, even though the three projects selected are similar in terms of high activity and in being popular open-source projects, major differences have been observed in terms of nature (one audio editing software, a learning management system, and a chess playing platform), licenses (MIT which is permissive VS GPLv3 which is strong copyleft), size (major differences in number of commits, number of lines of code, number of contributors and number of open issues), and age (Moodle was first started in 2001, while Lichess and Audacity are almost a decade younger).

3.1.2 Persona creation

To create the personas, we reviewed the related literature. Cooper et al. (2007) first introduced a seven-step process to be followed to create personas for conventional products. Llerena et al. (2016) further adopted this process to make it more suitable for open-source software and more convenient for the nature of such projects and made it instead a set of nine sequential tasks. Based on these works, we will follow the set of the following steps:

1. Prepare an online survey for users to identify personas.

2. Use the survey to gather data about users.

3. Cluster the data according to identified behavioral patterns.

4. Analyze the data.

5. Define different personas.

6. Share the personas and the data with fields experts and gather their feedback to check for redundancy and completeness.

7. Refine the personas based on feedback from step 6.

8. Designate the different persona types (primary/Secondary).

To check for completeness and redundancy after having defined the personas, Llerena et al. (2016) administered another survey and gathered more data from the users. Since this specific set of tasks was not specifically instructed by Cooper et al.'s original work, we decided it might make the produced personas more reliable if we share them along with the collected data with field experts and gather their feedback and insights to refine our personas and make sure they are not biased.

3.1.3 Data collection

Steps 1 and 2 are about collecting data about the users of each project. We prepared three different online surveys containing relevant questions for each project (the full Moodle user survey is included in Supplementary Appendix A). All the surveys were relatively short (the average time to complete a survey was around 4 min), anonymous, and were almost entirely composed of close-ended questions.

To prepare the survey, we also had to agree on the different sections that will be included in our personas. Thus, Based on the template suggested by Nielsen (2012) from his experience, and according to different literature reviews about a template for creating personas (Nielsen et al., 2015; Salminen et al., 2020a), as well as the work by Caddick and Cable (2011) under “Anatomy of Persona,” our personas were composed of the following sections:

• Picture: a picture of a user that matches the demographic information. It will be helpful to make the persona more “Human-like” (Caddick and Cable, 2011).

• Demographic information: general identifying information such as the name, age, gender, occupation, or marital status. They are Important to understand the persona and to identify it (Nielsen, 2012).

• About persona: a short description of the life situation of the persona which may help the developer empathize with it and understand it more properly. It was employed by Polst and Stupfert as they deduced from their experience and their literature review its importance (Polst and Stüpfert, 2019).

• Attributes and behavior: a description of the most relevant personality and character traits.

• Frustrations: covers the main problems that made the users use the product in the first place.

• Goals and motivations: covers the expectations the user has from the product and why they are using it. Goals were used as differentiators between different personas in a cast, as mentioned by the literature review of Nielsen et al. (2015).

• Quote: a quote that summarizes the persona and helps make it memorable. It is helpful to “Bring the persona to life and give an overview of her state of mind when trying to complete her goals” (Caddick and Cable, 2011) and provide personal insights (Jung et al., 2018).

Before sharing the surveys with users, we did pilot tests for our surveys with a couple of users to manually check for clearance and conciseness, and to anticipate the estimated time to fill each survey.

Just like for Llerena et al. (2016), collecting participants was a challenging process. We used social networks and official forums for the projects to share our surveys. Over a period of around 7 days, we collected 31 responses from Lichess users, 18 from Audacity users, and just two from Moodle users. This is why we decided to share the Moodle survey with South Mediterranean University (SMU) community. This might make the data collected less representative, but it allowed us to collect 50 additional responses in a short time. All experimental data, including collected responses, and persona descriptions, are publicly available for transparency and reproducibility at the following repository: ChellyAhmed/personas-os-resources.

3.1.4 Defining personas

We then used the most important goal from using each project and the most important use case to identify behavioral patterns that allowed us to cluster the data according to the different types of users. Each data cluster represented a user profile. We then analyzed the data to define a set of personas for each project.

Each persona has a number of subcategories (sections containing different types of information) as encountered in the literature review by Nielsen et al. (2015). The mean number of subcategories found by Salminen et al. (2020a) is 8,33, and all of our personas contained the seven sections mentioned above.

Our personas were not very long. All of them had approximately the same length and were one page long, similar to what was described by Nielsen et al. (2015).

3.1.5 Refining personas

After defining the personas, we sought feedback from industry experts to refine them. The experts we consulted were a UX Designer with 9 years of experience, a marketing officer with 8 years of experience, and a psychology professor in our university.

To begin, we ensured each expert's familiarity with Open-Source Software development and user personas. We clarified that our personas aimed to foster empathy among Open Source developers toward their software users. Before presenting the three selected projects, we provided an overview of each project, highlighting its features and relevance. Additionally, we invited the experts to ask any questions they had regarding the personas or the projects, ensuring they had a clear understanding before proceeding.

Overall, the experts approved of our personas, but they provided one observation. They noted that the language structure of some personas might not be clear enough to non-English speakers. Consequently, we rephrased and simplified those personas.

3.1.6 Collecting feedback from developers

Once the personas are ready, we collected feedback from developers to assess how they would perceive them. We created a second survey for each project destined to the developers. The survey contained some questions about the developers themselves, then a presentation of the personas, followed by a set of questions aiming to rate their validity and how would developers perceive them. These questions consist of statements related to the personas, and the developers had to quantify the extent to which they disagree or agree with the statement on a scale ranging from 1 to 5 (the complete set of evaluation items is provided in Supplementary Appendix B).

We based our survey questions on the constructs identified by Salminen et al. (2018) to assess the validity of personas from the perspective of developers. These constructs have been utilized in previous studies to evaluate the usefulness and validity of various personas (Salminen et al., 2020b,c). Drawing inspiration from the questionnaires employed in these studies, we formulated our own set of questions, as indicated in Table 2.

Table 2

Table 2. Persona evaluation constructs and related assessment items.

In the aforementioned works, Likert questions consisting of seven response options were utilized to compare the validity of different personas. However, since we will be evaluating the same set of personas across multiple participants, we have opted to employ five-point Likert-type questions for each construct, ranging from 1 (strongly disagree) to 5 (strongly agree). Our decision to use Likert-type questions aligns with the guidelines for analyzing Likert data presented by Boone and Boone (2012). In our study, only integer values from 1 to 5 were used; fractional values were not allowed.

When there are multiple questions related to the same construct, we will calculate the mean of the responses for those questions. Finally, to evaluate each construct, we would calculate the median. A positive persona evaluation would indicate that personas can serve as a valuable tool for open-source developers to empathize with users and gain a deeper understanding of their user base.

To contact the developers of Audacity and Lichess, we posted the survey link in the discussions channel of the corresponding project GitHub link. Concerning Moodle, There is a link on the Moodle.org website containing the profiles of all the contributors to the project. We created a web scraper that gathered all the published 637 email addresses of these developers and emailed them a link to the form.

3.2 Experimenting with students

After completing an initial experiment with developers, we decided to conduct a second experiment with a larger group to validate our findings. We targeted software engineering students in the second to last year of their studies at the South Mediterranean University (SMU). As part of one of their courses, they were required to contribute to an open-source project of their choice. Their contributions would later be assessed to determine their course performance.

Figure 2 illustrates the process of experimentation with students, detailing each step involved:

1. First, we introduced the students to the concept of personas and provided them with a standardized template designed to guide them in creating user personas effectively.

2. Then, we tasked them with creating these personas to help them understand the users of their chosen open-source projects better. Todo this, students conduct surveys among users to gather the necessary data.

3. Based on the collected survey data, students develop detailed and comprehensive user personas.

4. To ensure accuracy, a random sample of the created personas is reviewed by the instructors to ensure they accurately represent the user and meet the necessary criteria.

5. Following this, students use their developed personas to better understand and address the needs and preferences of the users they are designing for.

6. At the end of the semester, students are surveyed using the same constructs we used for the developers. After customizing some questions to fit the students' class project environment, we distributed a survey to the students.

7. The students then assess the impact and usefulness of the personas in their project work.

Figure 2

Figure 2. Process of experimentation with students.

The survey responses were not anonymous, as we wanted to review each student's persona manually. Thus, we only analyzed the responses of students who had created a user persona specifically for their project. We received responses from 29 different participants.

4 Results

4.1 Results from experimenting with developers

4.1.1 Developers participation

Similarly to the first survey, The developer participation rate was low. We received 16 responses from Moodle developers, two from Lichess developers, and none from Audacity developers. As a result, we mainly focused on the Moodle results, comparing them to the Lichess responses. We examined the time taken by all participants to complete the survey and discarded one response where the participant read the personas and answered all the questions in less than 2 min, casting doubt on the honesty of their answers.

Most developers who contributed to Moodle indicated “One commit or a few commits” when asked about their contributions to the project. Only one participant claimed to be a core contributor. In contrast, Lichess contributors identified themselves as core contributors, signifying their significant role in the decision-making process.

Before inquiring about the personas, we asked developers if they believed they had a comprehensive understanding of all users of their respective project. Only three Moodle participants responded affirmatively, while both Lichess respondents, despite being core developers, answered negatively. We also asked if they had previous experience working with personas, and only two Moodle participants indicated that they had used personas “five times or more.” This suggests that most developers are unfamiliar or only slightly familiar with the technique.

4.1.2 Persona perception by developers

Overall, the results of our personas were positive. An analysis of the data we collected indicates that the developers approve of our personas. Considering the constructs introduced in the previous section, our personas obtained scores greater or equal than 3.5 in nine out of the 11 constructs (with 5 representing “Strongly agree” and 1 representing “Strongly disagree”). The only construct that scored below 3 was Usefulness and willingness to use, which scored a median of 2.83. The second lowest scoring construct was Attraction, with 3 as a Median. Table 3 represents each construct and the median value of the responses from the developers for Moodle.

Table 3

Table 3. Personas constructs and respective medians for the moodle project.

Similar trends were noticed in the Lichess project responses with positive results for most of the constructs and Usefulness and Willingness to Use scoring the lowest. To further analyze the results, Figure 3 provides a detailed visualization using boxplots, showing the distribution and variability of developer responses across constructs.

Figure 3

Figure 3. A boxplot of the different constructs based on results from the developers experiment.

Constructs like credibility and clarity show narrow ranges, with minimum scores above 3 and maximum scores reaching 5, indicating strong agreement. In contrast, familiarity and usefulness and willingness to use display wider variability, with scores ranging from 1 to 4 or 5, highlighting mixed perceptions among developers.

4.2 Results from experimenting with students

4.2.1 Students participation as open-source developers

We repeated a similar experiment with students. The participation rate of the students was significantly higher than that of the developers in the first experiment. All the students were software engineering students contributing to different open-source projects as part of a class assessment. All considered responses come from students who actually contributed to their open-source project in one way or another. The students had the freedom to select an active open-source project with a relatively large community. They selected a range of diverse projects including but not limited to digitomize, Zulip, and idurar-erp-crm.

All the participants were young students and did not have long-term professional experience in software development other than their student jobs and internships. Although most of the students had never contributed to an open-source project before, they were relatively familiar with the concepts of open-source development and user personas. Additionally, we organized sessions with the students to further explain to them the experiment and the idea of Personas.

Similarly to the first experiment, we asked the students “Did you have an idea about the different user groups of the open-source project of your choice before you made the choice to contribute to it?”. Only six students responded with “No,” while the others responded with “Yes.” This means that the students are somewhat familiar with the projects they chose to work on.

4.2.2 Perception of personas based on the second experiment

The same computations from the previous experiment were performed on the results of the students. Table 4 presents the different constructs and their median scores.

Table 4

Table 4. Personas constructs and respective medians based on students' evaluations.

The responses to the constructs tend to show a positive perception of personas. The results of the students are slightly more positive compared to the results of the developers. On the same scale of the previous experiment, All the constructs achieved a median score equal to or higher than 3. The lowest-scoring constructs were attraction, and liking with a median score of 3 each, followed by usefulness and willingness to use with a score of 3.33.

Figure 4 highlights the distribution of student responses across constructs, with completeness showing relatively consistent consensus among participants. Constructs such as credibility, clarity, and consistency also display narrow ranges, indicating strong consensus. However, constructs like familiarity, usefulness and willingness to use, and attraction illustrate broader variability, indicating more diverse perceptions.

Figure 4

Figure 4. A boxplot of the different constructs based on results from the students experiment.

4.3 Comparing results from the 2 experiments

When we put together the results from the two experiments, we can see a certain level of consistency. We measured the median, mean, highest and lowest values across the responses from each experiment and we present them in Table 5.

Table 5

Table 5. Comparison of the results from the first and second experiments.

In both experiments, the highest value to evaluate each construct was 5, except for Similarity and Usefulness and Willingness to Use evaluated by developers at 4.5 and 4.33 respectively. The lowest evaluation value for the different constructs ranged between 1 and 3 for both experiments. Median and mean values are close and allow us to observe a pattern of similarity between the results from the two experiments. Based on the results from the developers, the lowest-scoring construct was Usefulness and Willingness to Use, followed by Attraction. While the results from the students show a similar trend with Attraction and Liking equally scoring the lowest, directly followed by Usefulness and Willingness to Use.

5 Discussion

As highlighted in the first subsection of our results, the developers are unfamiliar with using personas. They also confirmed that they are not completely familiar with the user base of the project they contribute to. This indicates that they lack awareness of the benefits and effects of using this technique. Additionally, after conducting our thorough research on open-source projects, we have discovered that using personas in open-source software is uncommon and occurs infrequently. To further investigate the use of personas in open-source software development, we manually checked the documentation of randomly selected popular open-source projects from Openhub and CodeTriage–two online databases that contain a list of popular open-source projects to contribute to. However, our search failed to identify a single published persona designed to assist the contributor community in these projects. This absence underscores the rarity of personas being employed as a tool within the open-source community. Compared to the results of the second experiment involving students, the majority of the participants stated that they were somewhat familiar with the users of their projects. Since the experiment was part of a course assessment and considering that the students had the freedom to choose a project to work on, it would be typical for students to select projects they are already very familiar with or to conduct extensive research about their projects' user base before choosing one. In relation to the first research question, we conclude that developers, specifically in the context of open-source development, need to have more awareness of the benefits of personas in understanding and empathizing with the users.

Addressing our second research question, the positive results analysis and evaluation of the Credibility, Clarity, Completeness, Consistency, Empathy, Familiarity, Friendliness, Attraction, Liking, and Similarity constructs demonstrate how the use of personas can positively impact developers. Both developers and students were able to better understand and empathize with the users of their projects. The results indicate that open-source developers are likely to positively react to personas if they were ever presented to them. The slightly lower value observed for the construct Usefulness and Willingness to Use for developers mainly but also for students suggests that developers are not interested in using personas, and potentially are not interested in paying more attention to the users of their project. After comparing the results from the two experiments, it is evident that similar patterns indicate comparable trends among developers and students, with slightly more positive effects of personas on students, who could be considered less experienced developers.

Showing disinterest, particularly in the usefulness and willingness to use, is a key factor in formulating a response to our third research question. Although personas have the potential to help developers empathize with the users of their projects and better understand them, developers are not interested in adopting this UX technique into their work. One likely explanation is the broader cultural context within OSS communities, where technical contributions are more visible, rewarded, and prioritized than design or usability efforts. As Stewart and Gosain note (Daniel et al., 2011), the values and norms of OSS culture often deprioritize non-code contributions. Additionally, many OSS contributors lack formal UX training, which can make it unclear how to apply personas effectively. As a result, resistance may stem less from the personas themselves and more from the development context in which they are introduced. Therefore, future research should consider qualitative methods, such as interviews or ethnographic studies, to uncover deeper educational, cultural, and motivational barriers to adoption.

While understanding these barriers is only the first step, practical strategies are needed to bridge the gap between technical development and user-centered design. One promising solution is the 1 + 5 Architectural Views Model, which provides a structured framework for integrating usability into software architecture. As demonstrated by (Górski 2021), (2020), this model supports the systematic inclusion of UX-related concerns, including personas, into complex IT systems. Applying it in OSS could help normalize UX considerations without requiring disruptive changes to development workflows.

That said, the successful integration of user-centered approaches also depends on their scalability across large, decentralized OSS communities. While our study focused on three mid-sized projects, larger initiatives such as Linux or Apache involve thousands of contributors and highly decentralized coordination. In such environments, persona adoption presents logistical and organizational challenges. One scalable solution is to embed persona insights directly into collaborative tools already in use such as GitHub issue templates, or pull request descriptions. These lightweight, embedded formats can help keep user needs visible without disrupting established development processes.

6 Threats to validity

This section discusses potential threats to the validity of the study related to this work. The main limitation of our work is the low number of participants. That is why at the end we focused mainly on the Moodle project. In addition, to assure the most relevant results possible, we manually checked each response. We also paid close attention to the survey completion time, since reading a persona's details may require some time. The time to complete our Moodle survey (which contained just two personas) was 11:35. We discarded the answers of one participant who responded to all the questions in less than 2 min. All the other participants took at least almost 5 min.

Data validity concerns the accuracy and completeness of the data collected. The manual process of data collection from repositories and issue trackers, as well as the use of web scraping tools for Moodle user email addresses, introduces potential for errors or omissions. To ensure data accuracy, we cross-verified information from multiple sources, including primary code repositories, issue trackers, OpenHub, and official project documentation.

Another potential threat to construct validity in our study is related to the participant pool. Participants were predominantly from the South Mediterranean University (SMU) community. This reliance on a single university community may introduce biases related to the specific educational and cultural environment of SMU. To mitigate this threat, we ensured that our participant pool included a variety of respondents, encompassing both students and faculty from the Mediterranean Institute of Technology(MedTech) and the Mediterranean Business School(MSB). Future replications of this study considering participants from multiple universities and professional environments are necessary to confirm our findings. Another limitation of our proposal is that the constructs used to evaluate the personas, such as credibility, completeness, consistency, empathy, attraction, and willingness to use, were based on established frameworks from the literature (Salminen et al., 2018). These constructs have been validated in prior studies to ensure their relevance and effectiveness for persona evaluation (Salminen et al., 2020b,c). Nonetheless, the subjective nature of these constructs means that personal biases of the participants could influence the results. To address this, we employed both quantitative (Likert-scale surveys) and qualitative (expert feedback) methods to validate our data and provide a comprehensive assessment of the personas' effectiveness.

7 Conclusions and future work

The objective of this research paper was to determine if adopting user personas in open source software development would result in an improved user-centered design and in reduced usability issues; and to identify the possible reasons behind the unpopularity of the personas technique within open source software.

After conducting our study, we conclude that adopting user personas in open source software development may be a way to solve the aforementioned user-centered design problem. However, we also conclude that open-source developers are less likely to accept such a tool, as they disagreed with it being useful and did not express their willingness to use it.

We deduce that the unpopularity of personas within open-source software is most likely caused by the nature of the developers who would prefer focusing on the technical aspect of their work and resist to the adoption of user personas.

While this study examined three mid-sized OSS projects, large-scale initiatives like Linux or Apache involve thousands of contributors and decentralized workflows. Future work should explore how personas can be scaled in these settings, considering both logistical and cultural constraints. Additionally, follow-up research should go beyond subjective feedback by using controlled usability assessments such as A/B testing, task performance measures, and user satisfaction metrics to evaluate real impact. Comparing personas with alternative UX techniques such as heuristic evaluations, usability testing, or user journey mapping may also help identify which methods are most practical and impactful in OSS environments. Hybrid approaches combining personas with these methods could yield more robust outcomes.

To improve scalability and reduce dependence on manual input, automated persona generation using NLP techniques applied to OSS forums, GitHub issues, or StackOverflow data is a promising direction. At the same time, addressing motivational and structural barriers is key. Future studies could explore gamification, contribution badges, or visual recognition in project dashboards as ways to incentivize developer engagement with user-centered design practices.

Altogether, this study highlights both the potential and the resistance surrounding personas in OSS. Moving forward, research should focus on empirical validation, integration into development workflows, automation, incentive mechanisms, and alignment with OSS culture. Advancing along these lines may strengthen the role of usability in decentralized development ecosystems.

Author's note

Images used in Supplementary material reproduced from Unsplash.

Data availability statement

The raw data supporting the conclusions of this article will be made available by the authors, without undue reservation.

Ethics statement

The studies involving humans were approved by aGljaGVtLmthbGxlbEBtZWR0ZWNoLnRu (Dean Medtech), South Mediterranean University. The studies were conducted in accordance with the local legislation and institutional requirements. The participants provided their written informed consent to participate in this study.

Author contributions

AC: Conceptualization, Data curation, Formal analysis, Investigation, Methodology, Software, Validation, Writing – original draft. SH: Conceptualization, Investigation, Methodology, Project administration, Supervision, Validation, Writing – original draft, Writing – review & editing. JK: Writing – review & editing, Writing – original draft.

Funding

The author(s) declare that no financial support was received for the research and/or publication of this article.

Conflict of interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Generative AI statement

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/fcomp.2025.1457563/full#supplementary-material

Footnotes

1. ^https://github.com/audacity/audacity

2. ^https://github.com/lichess-org/lila

3. ^https://git.in.moodle.com/moodle/moodle

4. ^https://tracker.moodle.org/projects/MDL/issues

5. ^https://github.com/moodle/moodle

References

Billestrup, J., Stage, J., Bruun, A., Nielsen, L., and Nielsen, K. S. (2014a). “Creating and using personas in software development: experiences from practice,” in Human-Centered Software Engineering: 5th IFIP WG 13.2 International Conference, HCSE 2014, Paderborn, Germany, September 16-18, 2014. Proceedings 5 (Berlin: Springer), 251–258. doi: 10.1007/978-3-662-44811-3_16

Crossref Full Text | Google Scholar

Billestrup, J., Stage, J., Nielsen, L., and Hansen, K. S. (2014b). “Persona usage in software development: advantages and obstacles,” in The Seventh International Conference on Advances in Computer-Human Interactions, ACHI (Barcelona: International Academy, Research, and Industry Association (IARIA)), 359–364.

Google Scholar

Boone, H. N. Jr., and Boone, D. A. (2012). Analyzing likert data. J. Ext. 50:48. doi: 10.34068/joe.50.02.48

Crossref Full Text | Google Scholar

Bradley, C., Oliveira, L., Birrell, S., and Cain, R. (2021). A new perspective on personas and customer journey maps: proposing systemic ux. Int. J. Hum. Comput. Stud. 148:102583. doi: 10.1016/j.ijhcs.2021.102583

Crossref Full Text | Google Scholar

Caddick, R., and Cable, S. (2011). Communicating the User Experience: A Practical Guide for Creating Useful UX Documentation. Hoboken, NJ: John Wiley & Sons.

Google Scholar

Cheng, J., and Guo, J. L. C. (2018). “How do the open source communities address usability and ux issues?: an exploratory study,” in Proceedings of the 2018 ACM SIGCHI Conference on Human Factors in Computing Systems (New York, NY: ACM), 1–6. doi: 10.1145/3170427.3188467

Crossref Full Text | Google Scholar

Cooper, A. (1999). The Inmates are Running the Asylum. Berlin: Springer. doi: 10.1007/978-3-322-99786-9_1

Crossref Full Text | Google Scholar

Cooper, A., Reimann, R., and Cronin, D. (2007). About Face 3: The Essentials of Interaction Design. Hoboken, NJ: John Wiley & Sons.

Google Scholar

Crowston, K., Wei, K., Howison, J., and Wiggins, A. (2008). Free/libre open-source software development: What we know and what we do not know. ACM Comput. Surv. 44, 1–35. doi: 10.1145/2089125.2089127

Crossref Full Text | Google Scholar

Daniel, S., Maruping, L., Cataldo, M., and Herbsleb, J. (2011). When Cultures Clash: Participation in Open Source Communities and its Implications for Organizational Commitment.

Google Scholar

Dawood, K. A., Sharif, K. Y., Zaidan, A., Abd Ghani, A. A., Zulzalil, H. B., Zaidan, B., et al. (2019). Mapping and analysis of open source software (OSS) usability for sustainable oss product. IEEE Access 7, 65913–65933. doi: 10.1109/ACCESS.2019.2914368

Crossref Full Text | Google Scholar

Deshpande, A., and Riehle, D. (2008). The Total Growth of Open Source. Boston, MA: Springer US, 197–209. doi: 10.1007/978-0-387-09684-1_16

Crossref Full Text | Google Scholar

Feller, J., and Fitzgerald, B. (2000). “A framework analysis of the open source software development paradigm,” in Proceedings of the Twenty-First International Conference on Information Systems (ICIS 2000) (Brisbane, QLD).

Google Scholar

Górski, T. (2020). “Verification of architectural views model 1+ 5 applicability,” in Computer Aided Systems Theory-EUROCAST 2019: 17th International Conference, Las Palmas de Gran Canaria, Spain, February 17-22, 2019, Revised Selected Papers, Part I 17 (Cham: Springer), 499–506. doi: 10.1007/978-3-030-45093-9_60

Crossref Full Text | Google Scholar

Górski, T. (2021). The 1+ 5 architectural views model in designing blockchain and it system integration solutions. Symmetry 13:2000. doi: 10.3390/sym13112000

Crossref Full Text | Google Scholar

Hellman, J., Chen, J., Uddin, M. S., Cheng, J., and Guo, J. L. (2022). “Characterizing user behaviors in open-source software user forums: an empirical study,” in Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering (New York, NY: ACM), 46–55. doi: 10.1145/3528579.3529178

Crossref Full Text | Google Scholar

Iivari, N. (2009). “constructing the users” in open source software development: an interpretive case study of user participation. Inf. Technol. People 22, 132–156. doi: 10.1108/09593840910962203

Crossref Full Text | Google Scholar

ISO/IEC (2001). ISO/IEC 9126-1: Software engineering - Product quality- Part 1: Quality Model. ISO/IEC.

Google Scholar

Jung, S.-G., Salminen, J., Kwak, H., An, J., and Jansen, B. J. (2018). “Automatic persona generation (APG): A rationale and demonstration,” in Proceedings of the 2018 Conference on Human Information Interaction & Retrieval (New York, NY: ACM), 321–324. doi: 10.1145/3176349.3176893

Crossref Full Text | Google Scholar

Llerena, L., Rodríguez, N., Sacca, G., Castro, J., and Acuña, S. (2016). “Adoption of the personas technique in the open source software development process,” in Proceedings of the 2016 ACM Conference Companion Publication on Designing Interactive Systems (New York, NY: ACM), 1–4. doi: 10.1145/2998626.2998653

Crossref Full Text | Google Scholar

Martinelli, S., Lopes, L., and Zaina, L. (2024). Ux research practices related to long-term UX: a systematic literature review. Inf. Softw. Technol. 170:107431. doi: 10.1016/j.infsof.2024.107431

Crossref Full Text | Google Scholar

Masson, A. L., Amstutz, T., and Lalanne, D. (2017). “A usability refactoring process for large-scale open source projects: the Ilias Case Study,” in Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing Systems (Ne wYork, NY: Association for Computing Machinery), 1135–1143. doi: 10.1145/3027063.3053345

Crossref Full Text | Google Scholar

Nichols, D. M., and Twidale, M. B. (2006). Usability processes in open source projects. Softw. Process Improv. Pract. 11, 149–162. doi: 10.1002/spip.256

Crossref Full Text | Google Scholar

Nielsen, L. (2012). Personas - User Focused Design, volume 15 of Human-Computer Interaction Series. Berlin: Springer. doi: 10.1007/978-1-4471-4084-9

Crossref Full Text | Google Scholar

Nielsen, L., Hansen, K. S., Stage, J., and Billestrup, J. (2015). A template for design personas: Analysis of 47 persona descriptions from danish industries and organizations. Int. J. Sociotechnol. Knowl. Dev. 7, 45–61. doi: 10.4018/ijskd.2015010104

Crossref Full Text | Google Scholar

Parizi, R., da Silva, M. M., Couto, I., dos Santos Marczak, S., and Conte, T. (2021). A tool proposal for recommending design thinking techniques in software development. J. Softw. Eng. Res. Dev. 10, 3:1–3:15. doi: 10.5753/jserd.2021.1931

Crossref Full Text | Google Scholar

Parizi, R., da Silva, M. M., Couto, I., Trindade, K., Prestes, M. P., dos Santos Marczak, S., et al. (2020). “Design thinking in software requirements: What techniques to use? A proposal for a recommendation tool,” in Proceedings of the XXIII Ibero-American Conference on Software Engineering (CIbSE 2020), Estados Unidos (USA).

Google Scholar

Polst, S., and Stüpfert, P. (2019). “A comprehensive persona template to understand citizens' mobility needs,” in HCI in Mobility, Transport, and Automotive Systems, Lecture Notes in Computer Science, ed. H. Krömker (Cham: Springer International Publishing), 295–306. doi: 10.1007/978-3-030-22666-4_22

Crossref Full Text | Google Scholar

Pruitt, J., and Grudin, J. (2003). “Personas: practice and theory,” in Proceedings of the 2003 Conference on Designing for User Experiences (New York, NY: ACM), 1–15. doi: 10.1145/997078.997089

Crossref Full Text | Google Scholar

Rajanen, M. (2011). Applying Usability Cost-Benefit Analysis in Commercial and Open Source Software Development Contexts (Ph.D. dissertation). University of Oulu, Oulu, Finland.

Google Scholar

Rajanen, M. (2023). Open source usability and user experience. Computer 56, 106–110. doi: 10.1109/MC.2022.3219634

Crossref Full Text | Google Scholar

Rajanen, M., and Iivari, N. (2019). Empowered or Disempowered?: An Analysis of Usability Practitioners' Interventions in Open Source Projects. New York, NY: Nova Science Publishers.

Google Scholar

Raymond, E. S. (2001). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol, CA: O'Reilly Media.

Google Scholar

Raza, A., Carpetz, L. F., and Ahmed, F. (2012). An open source usability maturity model (OS-UMM). Comput. Human Behav. 28, 1109–1121. doi: 10.1016/j.chb.2012.01.018

Crossref Full Text | Google Scholar

Salminen, J., Guan, K., Nielsen, L., Jung, S., and Jansen, B. J. (2020a). “A template for data-driven personas: analyzing 31 quantitatively oriented persona profiles,” in Human Interface and the Management of Information. Designing Information, volume 12184 of Lecture Notes in Computer Science, eds. S. Yamamoto, H. Mori (Cham: Springer International Publishing), 125–144. doi: 10.1007/978-3-030-50020-7_8

Crossref Full Text | Google Scholar

Salminen, J., Kwak, H., Santos, J. M., Jung, S.-G., An, J., Jansen, B. J., et al. (2018). “Persona perception scale: developing and validating an instrument for human-like representations of data,” in Extended Abstracts of the 2018 CHI Conference on Human Factors in Computing Systems (New York, NY: ACM), 1–6. doi: 10.1145/3170427.3188461

Crossref Full Text | Google Scholar

Salminen, J., Santos, J. M., Jung, S.-g., Eslami, M., and Jansen, B. J. (2020c). Persona transparency: analyzing the impact of explanations on perceptions of data-driven personas. Int. J. Hum. Comput. Interact. 36, 788–800. doi: 10.1080/10447318.2019.1688946

Crossref Full Text | Google Scholar

Salminen, J., Jung, S.-g., Santos, J. M., and Jansen, B. J. (2020b). Does a smile matter if the person is not real?: the effect of a smile and stock photos on persona perceptions. Int. J. Hum. Comput. Interact. 36, 568–590. doi: 10.1080/10447318.2019.1664068

Crossref Full Text | Google Scholar

Terry, M., Kay, M., and Lafreniere, B. (2010). “Perceptions and practices of usability in the free/open source software (FOSS) community,” in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Nw York, NY: Association for Computing Machinery), 999–1008. doi: 10.1145/1753326.1753476

Crossref Full Text | Google Scholar

Von Krogh, G., and Von Hippel, E. (2006). The promise of research on open source software. Manage. Sci. 52, 975–983. doi: 10.1287/mnsc.1060.0560

Crossref Full Text | Google Scholar

Wang, W., Cheng, J., and Guo, J. L. (2020). How do open source software contributors perceive and address usability?: valued factors, practices, and challenges. IEEE Softw. 39, 76–83. doi: 10.1109/MS.2020.3009514

Crossref Full Text | Google Scholar

Wang, Y., Arora, C., Liu, X., Hoang, T., Malhotra, V., Cheng, B., et al. (2025). Who uses personas in requirements engineering: the practitioners' perspective. Inf. Softw. Technol. 178:107609. doi: 10.1016/j.infsof.2024.107609

Crossref Full Text | Google Scholar