@proceedings {1875, title = {Considering the use of walled gardens for FLOSS project communication}, year = {2017}, month = {05/2017}, abstract = {At its core, free, libre, and open source software (FLOSS) is defined by its adherence to a set of licenses that give various freedoms to the users of the software, for example the ability to use the software, to read or modify its source code, and to distribute the software to others. In addition, many FLOSS projects and developers also champion other values related to "freedom" and "openness", such as transparency, for example in communication and decision-making, or community-orientedness, for example in broadening access, collaboration, and participation. This paper explores how one increasingly common software development practice - communicating inside non-archived, third-party "walled gardens" - puts these FLOSS values into conflict. If communities choose to use non-archived walled gardens for communication, they may be prioritizing one type of openness (broad participation) over another (transparency). We use 18 FLOSS projects as a sample to describe how walled gardens are currently being used for intra-project communication, as well as to determine whether or not these projects provide archives of these communications. Findings will be useful to the FLOSS community as a whole as it seeks to under- stand the evolution and impact of its communication choices.}, keywords = {apache, chat, communication, email, free software, irc, mailing list, open source, Slack, Stack Overflow, teams, Wordpress}, doi = {10.1007/978-3-319-57735-7_1}, url = {https://link.springer.com/content/pdf/10.1007\%2F978-3-319-57735-7_1.pdf}, attachments = {https://flosshub.org/sites/flosshub.org/files/preprint_0.pdf}, author = {Squire, Megan} } @proceedings {1854, title = {Differentiating Communication Styles of Leaders on the Linux Kernel Mailing List}, year = {2016}, note = {Slides link: https://docs.google.com/presentation/d/1_5kqOXBYwH33ayfGKCncCtCondfUYtsHSDBS3DBig6Y/edit?usp=sharing Edited to fix typo in abstract. New version is v3.pdf}, month = {08/2016}, publisher = {ACM}, abstract = {Much communication between developers of free, libre, and open source software (FLOSS) projects happens on email mailing lists. Geographically and temporally dispersed development teams use email as an asynchronous, centralized, persistently stored institutional memory for sharing code samples, discussing bugs, and making decisions. Email is especially important to large, mature projects, such as the Linux kernel, which has thousands of developers and a multi-layered leadership structure. In this paper, we collect and analyze data to understand the communication patterns in such a community. How do the leaders of the Linux Kernel project write in email? What are the salient features of their writing, and can we discern one leader from another? We find that there are clear written markers for two leaders who have been particularly important to recent discussions of leadership style on the Linux Kernel Mailing List (LKML): Linux Torvalds and Greg Kroah-Hartman. Furthermore, we show that it is straightforward to use a machine learning strategy to automatically differentiate these two leaders based on their writing. Our findings will help researchers understand how this community works, and why there is occasional controversy regarding differences in communication styles on the LKML.}, keywords = {email, flossmole, linus torvalds, linux, lkml}, attachments = {https://flosshub.org/sites/flosshub.org/files/v3_0.pdf}, author = {Schneider, Daniel and Spurlock, Scott and Squire, Megan} } @proceedings {1715, title = {"Should we move to Stack Overflow?" Measuring the utility of social media for developer support}, year = {2015}, month = {05/2015}, pages = {10pp}, publisher = {IEEE}, abstract = {Stack Overflow is an enormously popular question-and-answer web site intended for software developers to help each other with programming issues. Some software projects aimed at developers (for example, application programming interfaces, application engines, cloud services, development frameworks, and the like) are closing their self-supported developer discussion forums and mailing lists and instead directing developers to use special-purpose tags on Stack Overflow. The goals of this paper are to document the main reasons given for moving developer support to Stack Overflow, and then to collect and analyze data from a group of software projects that have done this, in order to show whether the expected quality of support was actually achieved. The analysis shows that for all four software projects in this study, two of the desired quality indicators, developer participation and response time, did show improvements on Stack Overflow as compared to mailing lists and forums. However, we also found several projects that moved back from Stack Overflow, despite achieving these desired improvements. The results of this study are applicable to a wide variety of software projects that provide developer support using social media.}, keywords = {developer support, forums, mailing list, metrics, quality, social media, Stack Overflow, technical support}, attachments = {https://flosshub.org/sites/flosshub.org/files/SEIP2015stackv2.pdf}, author = {Squire, Megan} } @conference {1317, title = {Describing the Software Forge Ecosystem}, booktitle = {45th Hawai{\textquoteright}i International Conference on System Sciences}, year = {2012}, note = {http://flossmole.org/content/everything-you-ever-wanted-know-about-software-forges-code-forges-june-2011}, month = {01/2012}, pages = {3416-3425}, abstract = {Code forges are online software systems that are designed to support teams doing software development work. There have been few if any attempts in the research literature to describe the web of people, projects, and tools that make up the free, libre, and open source (FLOSS) forge ecosystem. The main contributions of this paper are (1) to introduce a classification of FLOSS-oriented forges according to their characteristics; (2) to describe the forge-level and project-level data and artifacts currently available at each FLOSS forge; (3) to show various patterns already discovered in the FLOSS forge ecosystem, such as timelines of creation or arrangements by size or feature; (4) to make some recommendations to forge providers and data collectors about how to expose the structure and information in the forges; and (5) to describe the effort needed to extend our publicly- available information about the FLOSS forge ecosystem into the future.}, keywords = {features, FLOSS, forge, hosting, metrics}, attachments = {https://flosshub.org/sites/flosshub.org/files/SquireWilliamsHICSS2012.pdf}, author = {Squire, Megan and Williams, David} } @article {1231, title = {Integrating Projects from Multiple Open Source Code Forges}, journal = {International Journal of Open Source Software and Processes}, volume = {1}, year = {2009}, month = {31/2009}, pages = {46 - 57}, abstract = {Much of the data about free, libre, and open source (FLOSS) software development comes from studies of code forges or code repositories used for managing projects. This paper presents a method for integrating data about open source projects by way of matching projects (entities) across multiple code forges. After a review of the relevant literature, a few of the methods are chosen and applied to the FLOSS domain, including a comparison of some simple scoring systems for pairwise project matches. Finally, the paper describes limitations of this approach and recommendations for future work.}, keywords = {data integration, forges}, issn = {1942-3934}, doi = {10.4018/jossp.2009010103}, author = {Squire, Megan} }