Background: Time-bounded collaborative events are events that bring together different participants to address a problem through the creation of a computational artifact over a short period of time. Examples of these events include hackathons, game jams, and ideathons. Despite previous research on these events, little is understood about how people seek and get help during these events. Aims: Our goal is to understand how event participants seek and get help during time-bounded collaborative events to design better strategies supporting search behaviour. This is necessary because participants learn and improve different skills important for working in the industry during these events. Method: We conducted a mixed-methods study where we collected data through a large-scale survey with participants of a global-scale game jam. Our primary method was quantitative, but we had a qualitative dataset that we used to augment aspects of our quantitative results. Results: Our findings suggest that professional and independent developers are the ones who provide help most often, while students interact more with mentors. In addition, the frequency that participants getting help from mentors decreases with increased experience in game development and the number of participations in game jams. Participants also point to mentors as an essential part of the jams: they are expert facilitators, so much so that the perception of the mentors' absence or distance was reported as a disappointment. Conclusions: Understanding how participants in time-bounded collaborative events seek and get help is important to design more effective events and improving the participants' overall experience. We translate our findings into suggestions for event organizers.

Traditional Software Engineering (SE) courses often prioritize methodologies and concepts in small, controlled environments: naive projects used as a proof of concept instead of full-fledged real software systems. Although this strategy has clear benefits, it does not place enough care in training students to face complex, non-trivial legacy software projects. To bridge this gap, novel SE courses are leveraging the rich variety of open-source software (OSS) projects to illustrate how these methodologies and concepts are applied to existing, non-trivial software systems. To better understand the benefits, challenges, and opportunities of this transition, in this paper, we interview seven SE professors that changed their academic setting to aspire students to comprehend, maintain, and evolve OSS systems as part of their SE course. We found that there are different ways to make use of OSS projects in SE courses in terms of project choice, assessment, and learning goals. Moreover, we evidence clear benefits of this approach, including improving students' social and technical skills, and helping students enhancing their resume. Also, we observed that this strategy comes with costs: the activity demands effort and time from the professor and the barrier for one getting involved with and, therefore, placing a meaningful contribution, in an OSS community is often high.

Software developers use many different communication tools and channels in their work. The diversity of these tools has dramatically increased over the past decade and developers now have access to a wide range of socially enabled communication channels and social media to support their activities. The availability of such social tools is leading to a participatory culture of software development, where developers want to engage with, learn from, and co-create software with other developers. However, the interplay of these social channels, as well as the opportunities and challenges they may create when used together within this participatory development culture are not yet well understood. In this paper, we report on a large-scale survey conducted with 1,449 GitHub users. We discuss the channels these developers find essential to their work and gain an understanding of the challenges they face using them. Our findings lay the empirical foundation for providing recommendations to developers and tool designers on how to use and improve tools for software developers.

Software ecosystems as a paradigm for large-scale software development encompass a complex mix of technical, business, and social aspects. While significant research has been conducted to understand both the technical and business aspects, the social aspects of software ecosystems are less well understood. To close this gap, this paper presents the results of an empirical study aimed at understanding the influence of social aspects on developers' participation in software ecosystems. We conducted 25 interviews with mobile software developers and an online survey with 83 respondents from the mobile software development community. Our results point out a complex social system based on continued interaction and mutual support between different actors, including developers, friends, end users, developers from large companies, and online communities. These findings highlight the importance of social aspects in the sustainability of software ecosystems both during the initial adoption phase as well as for long-term permanence of developers.

Productivity as a result of individual developers' contributions is an important aspect for software companies to maintain their competitiveness in the market. However, there is no consensus in the literature on how to measure productivity or developer contribution. While some repository mining-based metrics have been proposed, they lack validation in terms of their applicability and usefulness from the individuals who will use them to assess developer contribution: team and project leaders. In this paper, we propose the design of a suite of metrics for the assessment of developer contribution, based on empirical evidence obtained from project and team leaders. In a preliminary evaluation with four software development teams, we found that code contribution and code complexity metrics received the most positive feedback, while participants pointed out several threats of using bug-related metrics for contribution assessment. None of the metrics can be used in isolation, and project leaders and developers need to be aware of the benefits, limitations, and threats of each one. These findings present a first step towards the design of a larger suite of metrics as well as an investigation into the impact of using metrics to assess contribution.

To be able to respond to source code modifications with large impact or commits that necessitate further examination, developers and managers in a software development team need to be aware of anything unusual happening in their software projects. To address this need, we introduce UEDashboard, a tool which automatically detects unusual events in a commit history based on metrics and smells, and surfaces them in an event feed. Our preliminary evaluation with a team of professional software developers showed that our conceptualization of unusual correlates with developers' perceptions of task difficulty, and that UEDashboard could be useful in supporting development meetings and for pre-commit warnings.

Software developers pursue a wide range of activities as part of their work, and making sense of what they did in a given time frame is far from trivial as evidenced by the large number of awareness and coordination tools that have been developed in recent years. To inform tool design for making sense of the information available about a developer's activity, we conducted an empirical study with 156 GitHub users to investigate what information they would expect in a summary of development activity, how they would measure development activity, and what factors influence how such activity can be condensed into textual summaries or numbers. We found that unexpected events are as important as expected events in summaries of what a developer did, and that many developers do not believe in measuring development activity. Among the factors that influence summarization and measurement of development activity, we identified development experience and programming languages.

The microblogging service Twitter has over 500 million users posting over 500 million tweets daily. Research has established that software developers use Twitter in their work, but this has not yet been examined in detail. Twitter is an important medium in some software engineering circles—understanding its use could lead to improved support, and learning more about the reasons for non-adoption could inform the design of improved tools. In a qualitative study, we surveyed 271 and interviewed 27 developers active on GitHub. We find that Twitter helps them keep up with the fast-paced development landscape. They use it to stay aware of industry changes, for learning, and for building relationships. We discover the challenges they experience and extract their coping strategies. Some developers do not want to or cannot embrace Twitter for their work—we show their reasons and alternative channels. We validate our findings in a follow-up survey with more than 1,200 respondents.

The multitude of social media channels that programmers can use to participate in software development has given rise to online developer profiles that aggregate activity across many services. Studying members of such developer profile aggregators, we found an ecosystem that revolves around the social programmer. Developers are assessing each other to evaluate whether other developers are interesting, worth following, or worth collaborating with. They are self-conscious about being assessed, and thus manage their public images. They value passion for software development, new technologies, and learning. Some recruiters participate in the ecosystem and use it to find candidates for hiring; other recruiters struggle with the interpretation of signals and issues of trust. This mutual assessment is changing how software engineers collaborate and how they advance their skills.

Many software development projects struggle with creating and communicating a testing culture that is appropriate for the project's needs. This may degrade software quality by leaving defects undiscovered. Previous research suggests that social coding sites such as GitHub provide a collaborative environment with a high degree of social transparency. This makes developers' actions and interactions more visible and traceable. We conducted interviews with 33 active users of GitHub to investigate how the increased transparency found on GitHub influences developers' testing behaviors. Subsequently, we validated our findings with an online questionnaire that was answered by 569 members of GitHub. We found several strategies that software developers and managers can use to positively influence the testing behavior in their projects. However, project owners on GitHub may not be aware of them. We report on the challenges and risks caused by this and suggest guidelines for promoting a sustainable testing culture in software development projects.

Through the past years, several digital rights man- agement (DRM) solutions for controlled dissemination of dig- ital information have been developed using cryptography and other technologies. Within so many different solutions, however, interoperability problems arise, which increase the interest on integrated design and management of these technologies. Pursu- ing these goals, this paper presents a framework which aims at promoting interoperability among DRM systems, using a service- oriented architecture (SOA) and a high-level policy modeling approach.