Our results reveal the existence of a significant number of foundations with the sole purpose of promoting the free software movement<\/strong> and\/or that limit themselves to core legal aspects but do not play any role in the day-to-day operations of the project (e.g., umbrella organizations for a large variety of projects). Therefore, while useful, foundations do not remove the need for specific projects to develop their own specific governance, contribution and development policies<\/strong>.<\/p>\n The first version of this work<\/a> was accepted in the Software Engineering in Society track<\/a> of the International Conference on Software Engineering 2018.<\/a> You can also read it below. An extended and updated version has been released on Arxiv:\u00a0A Survey of Software Foundations in Open Source<\/a><\/p>\n As part of the work we have also launched a website displaying all these open source foundations<\/a>. Click on the foundation name to see its individual characteristics or filter them based on a number of predefined dimensions. We are also happy to see that the official EU report on the “The impact of open source software and hardware on technological independence, competitiveness and innovation in the EU economy<\/a>” reuses part of this work. So make sure you contribute any missing foundation or wrong information!<\/p>\n The impact of Open Source Systems (OSS) in modern society is undeniable. It has become a relevant part of the software industry and has contributed to the advance of the state of the art in research, education and government\u00a0. Sustainability of OSS projects relies on active contributions of passionate developers. Therefore, survival of a OSS project largely depends on its ability to retain developers and onboard new ones (i.e., newcomers), as well as to create a community of users who promote its adoption and use. As these projects grow, developers tend to organize and create communities to drive their development but many projects lack of formal models, especially governance models,<\/a> to structure and manage the (potentially large) community around them (and the challenges this implies<\/a>). Support to deal with all kinds of organizational decisions (including legal and economic aspects) is a huge concern for all projects at this stage.\u00a0As an example, we are part of an internal reflection taking part in the Decidim community<\/a> (a participatory democracy software framework initiated by the Barcelona city council) aimed to decide whether a foundation should be created and, if so, which foundation model it should inspire on.<\/p>\n In other domains, non-profit initiatives organize themselves around foundations (either public or private) that provide the legal and economical infrastructure for a community. Foundations can also define a number of internal regulations regarding, for instance, the activity, membership and decision-making process for the non-profit and non-governmental organizations. In the last years, we have also seen a number of foundations created around open source projects. Software foundations are non-profit organizations whose mission is to provide the needed grounds for open and collaborative software development. They also provide a legal framework for individual volunteers and enable the donation of resources for the public benefit. But, so far, little is known regarding the number, type, impact of such foundations and the differences among them. For instance, the Apache Software Foundation<\/em> and Linux Foundation<\/em> are maybe two of the most well-known software foundations. However, they follow different strategies for the management of the projects they cover. While the Apache Software Foundation<\/em> proposes a meritocratic system where different committees control and drive the development of several software projects (and the board oversees the whole process); the Linux Foundation<\/em> follows a flexible approach which serves as an umbrella for its projects, which can deploy specific development processes, and therefore concentrates more on the promotion of OSS benefits.<\/p>\n In this blog post we study the different flavors of foundations behind open source software and their impact in the development of OSS projects. Our goal is to give a clear picture of the current state of the art of software foundations and to help developers make informed decisions when creating new ones or choosing an existing one to join. To this aim, we build a dataset of 89 software foundations, which we analyze according to their scope, openness, and influence in the development practices taking place in the project itself.<\/p>\n The rest of the post is organized as follows. Section 2 presents the research methodology followed in our study, including the definition of the research questions and the construction of the dataset for our study. Section 3 addresses the research questions and describes the results of our study. Section 4 describes the threats to validity. Section 5 presents the related work. Section 6 finalizes the blog post and presents the future work.<\/p>\n In this section, we discuss how our study has been set up. We first present our research questions (Section 2.1) and then describe how we built the dataset for our study (Section 2.2).<\/p>\n Our objective is to grasp a better understanding of the role played by software foundations in the development of OSS. More specifically, we have identified the following main research questions:<\/p>\n To answer the questions above, we built a dataset composed of a number of foundations. To construct the dataset, we initially relied on the list of foundations available in flossfoundations.org<\/a>, an online community created in 2005 by representatives from the Python Foundation<\/em>, Apache Software Foundation<\/em>, Perl Foundation<\/em> and Free Software Foundation<\/em>, with the aim of sharing their experiences and expertise in the field of free software and foundations. We complemented this list by incorporating additional foundations identified thanks to other sources devoted to promoting OSS like opensource.com<\/a> and oss-watch<\/a>, as well as our own expertise.<\/p>\n For each foundation, we extracted (a) its URL; (b) the legal organization type (c) the number of projects they cover (if any and publicly available); and (d) a brief description. When needed, additional information is later on retrieved to answer specific aspects of our research questions.<\/p>\n At the end of the process, we constructed a dataset composed of 89 foundations. Table 1 (see first two columns) shows the list of foundations we collected reporting only aspects (a) and (c) due to space limitations.<\/p>\n Table 1.\u00a0Foundations considered in our study and research questions<\/strong><\/p>\n Our dataset is fully used by RQ1, which identifies those foundations targeting software development. Then, RQ2 analyzes the scope of these software foundations (i.e., RQ1 output). Finally, RQ3 and RQ4 take the independent, international and transparent foundations identified in RQ2 to perform the study. Figure\u00a01 shows the followed method and the size of the dataset involved in each research question.<\/p>\n Figure 1. The method followed to answer the research questions.<\/strong><\/p>\n In the following, we address our research questions based on the analysis of the foundations considered in our dataset.<\/p>\n To address this research question, we first check each foundation in our dataset to find out whether its main goal is to support the development of a specific set of software projects. Other goals could include: training, certification or evangelization of open source in general. Table 1, column RQ1, presents the results of this analysis by showing a black square for foundations that fall in the former category (and a cross for the rest).<\/p>\n In total, 24 foundations were discarded at this stage and therefore will not be part of the core dataset for the other research questions (which focus only on studying those foundations whose main goal is to support OSS projects). Discarded foundations include well-known examples such as the Free Software Foundation<\/em> or Creative Commons<\/em>, among others. The other 65 foundations are currently endorsing and helping a total of 871 software projects. Even though this is a low value in comparison to the number of projects being developed in OSS communities like GitHub<\/a>, with more than 67 million of repositories (number taken from Octoverse<\/a> though the number of real projects under active development is probably, at least, an order of magnitude smaller than that); some of the projects covered by these foundations are among the ones with most impact in OSS, like the projects of the Apache Software Foundation<\/em> (e.g., the Apache Web Server), the Linux Foundation<\/em> (e.g., Linux Kernel, one of the top 10 most GitHub forked projects) or the Symphony Foundation<\/em> (e.g., Symphony project, also one of the top 10 projects in GitHub with most code participation of the community).<\/p>\n 73% of the analyzed foundations are specifically aimed at supporting software development efforts. Foundations not focused on software are mainly devoted to support and promote the open and free software movement.<\/p>\n Once identified the set of foundations targeting software development in our dataset, we study them to get some insights about their scope, according to three orthogonal dimensions, namely: geographical distribution, coverage and mission.<\/p>\n Geographical Distribution<\/strong>. This dimension studies the distribution of the foundations from a geographical point of view (i.e., whether the foundation has an international or local character). We detected 18 software foundations that were mainly focused on the development of local OSS communities. For instance, El Centro de Software Libre<\/em> or Software Livre Brasil<\/em> are two foundations whose activities focus on projects developed in Chile and Brasil, respectively. We are mainly interested in those foundations having an international distribution, as local ones are usually smaller and may adopt some behavior specific to the country they are located. Table\u00a01, column Geo. Dist., marks with a black square the foundations with an international distribution (and a cross for the rest).<\/p>\n Coverage<\/strong>. Foundations can either serve a specific project, a set of projects or provide an umbrella for a number of smaller foundations that use it to simplify its own creation, management and legal processes. We found 14 foundations that mainly act as umbrella for others, like Linux Foundation<\/em>, where inner organizations generally work in a stand-alone way (e.g., OpenAPI initiative<\/em> or Kubernetes<\/em> within the Linux Foundation<\/em>); or as subsidiaries, like Subversion Corporation<\/em>, which is part of the Apache Software Foundation<\/em>. In the next research questions, we focus on independent foundations. Table\u00a01, column Coverage, signals our individual foundations with a black square.<\/p>\n Mission<\/strong>. Beyond the development itself, foundations may aim to help the project on several aspects, like nurturing the community or facilitating the creation of new related projects. These goals are normally stated as part of the foundations\u2019 mission as mentioned either in the foundation website or in their bylaws. Surprisingly, a significant number of foundations did not provide any explicit information on their mission. According to our evaluation, 28 foundations did not include any reference to one or more of the following elements: mission, organization, projects or bylaws, being the last one the most difficult to find. Table\u00a01, column Mission, shows a black square for those foundations whose mission could be analyzed. For those, we collected the mission description and performed a term frequency study. Apart from the high frequency of terms directly related to their main tasks like software<\/em>, development<\/em>, open<\/em> or free<\/em>; the term community<\/em> is also often highlighted in the mission descriptions, thus revealing the importance of this dimension. Other relevant terms with high frequency refer to the core promotion and support of OSS (e.g., promote<\/em>, support<\/em>, defend<\/em> or infrastructure<\/em>).<\/p>\n 72% of the foundations targeting software development in our dataset have an international vocation and 78% are independent single software foundations. For the 57% of the software foundations with an explicit mission description, the community and defense of OSS are key concepts together with the development support.<\/em><\/p>\n For the independent, international and transparent (in the sense of having enough information describing its mission and organization available) we study next whether the role of the foundations is limited to providing a legal and organization framework for the software project or if it goes beyond this and it directly dictates and monitors how the software is actually developed. Last column in Table\u00a01 indicates the foundations considered (see the black squares), which are 18 in total.<\/p>\n We focus on four attributes, namely: communication, the process to become a project committer, the governance of the project, and the existence of a technical board. Table 2 summarizes the main results. Next, we describe each dimension and report on the findings in more detail.<\/a><\/p>\n Table 2. Analysis of the development process of the selected foundations<\/strong><\/p>\n Communication<\/strong>. In OSS projects, communication plays a key role to disseminate the project and to help onboard new developers, also known as newcomers. For each foundation, we evaluate the communication channels as well as the resources provided to help newcomers to participate such as specific portals, indications to identify where help is required or the existence of a code of conduct.<\/p>\n The most common communication channel is the mailing list, although the use of forums is also widely spread. Besides, the great majority of the foundations provide specific documentation to help onboard newcomers. This lowers the entry barrier to any developer willing to contribute to the software projects covered by these foundations, paving also the way to the future promotion of some of them to core project committers.<\/p>\n Becoming committer<\/strong>. OSS projects capitalize on people that freely contribute to their development. Hence, retaining and capturing developers is crucial for their success. This is specially true for committers who are developers that have write access to the codebase and therefore have the key role to write (and\/or review) new code to be committed to the project.<\/p>\n Our results reveal that becoming committer is in principle open to anyone interested in the project providing that has shown enough commitment and interest in it. The actual selection and evaluation process varies from foundation to foundation. Some of the decision-making mechanisms to select committers include: use of vouchers or some mechanism to gather support from other developers (e.g., Apache Software Foundation<\/em> or Mozilla Foundation<\/em>), a mentoring process (e.g., Gentoo Foundation<\/em>) or based on the number and success of previous pull-requests (e.g., Python Foundation<\/em> or Symphony Foundation<\/em>).<\/p>\n Governance<\/strong>. Effective and precise prioritization of the development tasks is also a crucial activity in any OSS project. With this purpose, each foundation defines and applies its own set of governance rules to govern the projects under its umbrella. These governance rules describe how to contribute to the project and how decisions regarding the acceptance\/rejection of such contributions are going to be made. We study how people coordinate (see Coord. column), the tool\/s they use to do so (see Impl. column) and how they govern the process.<\/p>\n As you can see in the Table, the definition of governance models is maybe the most ignored issue in the analyzed foundations. They are not clearly specified in one single place. Instead, governance information is scattered across several documents (if available at all). According to our results, most of the foundations rely on issue-trackers to identify development tasks for their projects (see What column), however, it is not clear how these tasks are prioritized, approved or refused (see Who and How columns).<\/p>\n A remarkable exception is the Apache Software Foundation<\/em> that clearly describes its development process where committees have the decision-making authority regarding the content and direction of the Apache projects. In turn, these committees are overseen by the foundation\u2019s board. Decision making processes normally follow a lazy consensus approach: a few positive votes with no negative vote is enough for approval. Negative votes always include some explanation for the reason to reject and may include an alternative proposal to be discussed.<\/p>\n Mozilla Foundation<\/em> also describes how its development process is governed. The governance of Mozilla modules is a meritocracy, where developers need to demonstrate their abilities and find someone in the community who has adequate authority and will vouch for his\/her competence. Module development is governed by the module owners, while release management is decided by the release drivers. The full governance process is overseen by super-reviewers, who review code for its effects on the overall state of the development branch and its adherence to Mozilla coding guidelines; and ultimate decision-makers, who are trusted members of the community who have the final say in the case of disputes.<\/p>\n In some cases, the foundation explicitly states that it takes no part in the day-to-day activities of the project, like the statement done by the Open Source Geospatial Foundation<\/em>, which reads the foundation is not interested in controlling foundation projects<\/em>, thus clearly separating the foundation structure and the development process of its projects. However, even in those cases, the foundation may give some recommendations for the governance of its projects, like the rejection of the benevolent dictator for life<\/em> governance role or the enforcement of code management systems.<\/p>\n Technical Board<\/strong>. Some software projects may employ boards composed of recognized developers to drive the main technical decisions that may arise during the development process. Becoming part of these boards is usually hard and requires demonstrating clear compromise and commitment to the project.<\/p>\n Around half of the analyzed foundations make use of technical boards. Typically, these boards focus on technical aspects with an advisory role and are not used as a \u201cformal\u201d bridge between the project and the foundation internal organization. An exception is Apache and Eclipse, where the project committee (i.e., the Project Management Committees, PMCs) periodically report to the board about the status of the project.<\/p>\n Most of the foundations provide communication means and useful information for newcomers, but have limited implication and influence in the software project day-to-day work and decision process.<\/em><\/p>\n As a final aspect of our study, we wanted to see whether the foundations themselves (and not the projects they support) follow as well an open philosophy. Or, if in an apparent contradiction to their mission, they are closed organizations. To answer this question, we study the organization according to three main attributes, including the board, the membership and the meetings. It turns out that the internal organization of the analyzed foundations follows always a similar pattern, with only a few exceptions. We report on this in the following.<\/p>\n Board<\/strong>. In an organization, the board of directors is usually a recognized group of people who is responsible for the management and oversight the organization. The directors\u2019 powers, duties and responsibilities are generally specified in the bylaws of the foundation, where it is also common to specify the size of the board, who can be elected and how they are chosen or removed. In our analysis, we study essential information about the board including its size, the term, who can be part of the board, how they make decisions and how they are elected\/removed from their seats.<\/p>\n Table 3 summarizes this information. In general, the board of directors has a term of one year and is elected by the members of the organization; besides, board actions are taken by majority with a majority quorum. A variety of different mechanisms are put in place for electing and removing directors. Also, while the election of directors usually involves the members of the organization, their removal sometimes does not count on them (e.g., Django Foundation<\/em>, Symphony Foundation<\/em> and X.Org Foundation<\/em>), thus restricting the members\u2019 freedom.<\/p>\n Table 3. Analysis of the board for the selected foundations.\u00a0<\/strong><\/p>\n The Eclipse Foundation<\/em> is maybe the most peculiar one in our analysis. It classifies the organization membership into four main groups, namely: (a) strategic developers, (b) strategic consumers, (c) add-in providers and (d) committers. Each group has the right to elect\/remove a number of corresponding directors for the board. The election for the first two groups is unanimous while for the last two groups is by single transferable vote. The removal, however, is usually by majority for the four groups. Finally, the decision-making mechanism depends on the action being taken (see table footnotes), but simple majority is applied by default. This board organization shows a customized structure for the roles of the community, which may promote a better management of the organization.<\/p>\n Other issues worth noting are how some foundations select a special group of people to manage the board and the definition of causes for removing board members. Although they are called differently (e.g., trustees<\/em>, active members<\/em> or committee members<\/em>) they share a common objective and can be considered the elite<\/em> in the organization, as they have the power to modify the board. On the other hand, some of the foundations clearly establish the procedures to follow to remove directors from the board with\/without a cause, thus proposing different decision-making mechanisms for each one.<\/p>\n Membership<\/strong>. Most organizations admit people to become members, thus allowing them to participate in the decision-making processes like the election of the board or other affairs of the corporation. We are interested in analyzing who can be part of the foundation members as well as how they are elected\/removed.<\/p>\n Table 4 shows the results of the analysis of the membership for the selected foundations. Decisions on new members usually rely on the current members, who participate in the election and removal processes. The decision-making mechanism applied differs across the foundations. Although some of them apply the well-known majority procedure, most of them rely on specific procedures, for instance, nomination mechanisms (e.g., Open Source Geospacial Foundation<\/em> and Parrot Foundation<\/em>), or simple agreement (e.g., NetBSD Foundation<\/em> or Python Software Foundation<\/em> for basic member level).<\/p>\n Table 4. Analysis of the membership for the selected foundations.<\/strong><\/p>\n Meetings<\/strong>. Most foundations hold an annual meeting, where members and the board can manage the business and affairs of the corporation. These meetings are also used to renew the board and elect other possible committees of the foundation. We study how frequent these meetings are and who can take part in them (Table 5). In the vast majority of foundations, any member can participate in the meeting and meeting decisions are based on a majority procedure with a quorum. However, most bylaws do not specify whether decisions made in these meetings can involve aspects that directly affect the development processes of their OSS projects. Only Apache Software Foundation<\/em> defines the purpose of the meetings, which includes a revision of the status of every project, the election of developers for the committees or the approval of releases, among others.<\/p>\n Table 5. Analysis of the meetings held by the selected foundations.<\/strong><\/p>\n The analyzed foundations show a high level of openness with most decision procedures based on member voting and democratic practices.<\/em><\/p>\n Beyond the main conclusions reported so far we would like to highlight some additional contributions derived from the results.<\/p>\n Utility of umbrella foundations for new projects<\/strong>. As we have seen, some foundations serve as umbrella for other smaller foundations or sets of related projects. For instance, the Linux Foundation<\/em> clearly states that it provides unparalleled support for open source communities through financial and intellectual resources, infrastructure, services, events, and training<\/em>. We believe that this kind of foundations are especially useful for young OSS projects as they provide the required scaffolding and liberate them from organizational issues while freeing them also from the burden of setting up their own foundation. Also, they create an ecosystem where projects and developers can easily collaborate together, which may help them to boost their development.<\/p>\n Weak alignment between the foundation and the project\u2019s concrete development practices<\/strong>. Our study has revealed that, while the organization itself is well defined, this organization does not generally extend to the software projects that depend on it. As we have commented before, as the projects grow, there is the need to put in place adequate structures to manage the community around the project and optimize its contributions. Since it has been reported before that projects do not typically take care of this issue themselves, we were hoping that foundations could play that role. Unfortunately, this does not seem to be the case. We believe this is a clear aspect where foundations could help. A tighter integration between the foundations and the project could help projects benefit from the organizational knowledge available at the foundation to decide the best governance and contribution model for the project. This does not necessarily mean that the project should strictly follow the internal organization of the foundation itself but that at least the project could use some of the know-how available there.<\/p>\n Lack of precise documentation<\/strong>. One of the main issues we found in our study was the lack of precise documentation about how the foundation works. This may scare away some potential contributors that want to first clearly understand how their effort (e.g., in terms of time invested in coding patches for reported bugs) will be evaluated. Conversely, sometimes the information was abundant but unclear and scattered (e.g., the Wikimedia Foundation<\/em>), thus causing over-documentation issues and confusion, specially since it is easy that at some point this redundant documentation becomes partially outdated and even contradictory. To maximize the efficiency and impact of foundations, we believe a clear and concise information about all foundation aspects is a must.<\/p>\n No historical data publicly available<\/strong>. Most of the foundations analyzed in our study (with very few exceptions, like the Apache Software Foundation<\/em>) do not provide easy means to access the assets tracking the foundation activity (e.g., minutes of general meetings, past composition of committees, historical list of projects supported, meetings hold by the committees, etc.). This makes really difficult to evaluate the real impact the organization has on open source since we can only have the current snapshot. No longitudinal studies can be done at this point. Therefore, we encourage foundations to make the effort to open more of its data for further analysis.<\/p>\n Our work is subjected to a number of threats to validity, namely: (1) internal validity, which is related to the inferences we made; and (2) external validity, which discusses the generalization of our findings.<\/p>\n Regarding the internal validity, the dataset construction process mainly relies on the set of foundations identified by flossfoundati ons.org. To minimize the risk of missing foundations not listed there, we explored other online sources to extend the initial list of foundations.<\/p>\n Another threat to validity is our subjectivity in selecting and classifying the foundations of our dataset. A wrong perception or misunderstanding on our side of a given foundation may have resulted in a misclassification of the foundation regarding the reported research questions. To minimize the chances of this to happen, the study and classification of the foundations were validated by all authors, discussing any misalignment until reaching a full agreement.<\/p>\n As for the external validity, note that our study is based on a sample of software foundations we constructed and therefore our results should not be generalized to other kinds of foundations linked to (non-software) collaborative projects, like book writing efforts or similar initiatives also commonly used GitHub or other code hosting platforms.<\/p>\n Research on OSS development has been widely addressed in the scientific literature specially given the growing number of organizations adopting open source practices [27]. Crowston et al. [8] review the empirical research on Free\/Libre and Open-Source Software (FLOSS) development and assess the state of the literature. Likewise, Cosentino et al. [6] perform a systematic mapping study of all research works studying software development aspects in the context of the GitHub code hosting platform<\/a>. As an example, there are a number of works studying development models [23], diversity of developer teams [29], community structures [4], documentation procedures [1] or collaboration practices [10], among many others.<\/p>\n Nevertheless, the role of open source foundations to organize and coordinate open source projects has been largely ignored. Previous works on the topic of OSS organization have mainly focused on the (self-)organization of developer communities, for instance, by analyzing the social ties [2] or the blossoming of spontaneous collaboration networks [4, 7, 13] as the project grows and evolves. This evolution over time has also been covered by Panichella et\u00a0al. [22] and Joblin et. al [14]. Additionally, a number of works have studied different coordination mechanisms that may be put in place to organize the work [9, 12, 15]. The formalization of such collaboration is typically done by means of defining the governance model of the project [19, 21]. Nevertheless, the explicit definition of governance models is still mostly missing in OSS projects, as analyzed by C\u00e1novas Izquierdo et al. [18].<\/p>\n Among the few exceptions, we would like to mention the work of O\u2019Mahony [20] and Riehle [24] (that discusses the role of software foundations in OSS from a more economic\/business perspective), the studies of Lindman and Hammouda [17] (performing a qualitative analysis of how foundations support OSS projects) and Riehle and Berschneider [25] (evaluating six foundations to build a comparative model that should help project leaders understanding the differences between existing foundations). These studies (especially the latest two) are useful to complement, from a more qualitative point of view, our RQ3 and RQ4 research questions even if our work covers a larger number of foundations and dimensions.<\/p>\n Some of the dimensions studied in this blog post have been individually addressed by other works but at the project level. For instance, Tourani et al. [28] study the importance of codes of conduct in OSS, where instructions on how to be part of the project community or to become committer are usually included. Guzzi et al. [11] study the role of communication channels in the development process of OSS, in particular, the use of mailing lists.<\/p>\n We have studied 89 software foundations to better understand the role they play in the development of open source software projects. Our results show that very few foundations are devoted to providing complete support (i.e. including guidelines on the governance and contribution rules they should follow) to the projects they endorse. Their mission is more directed towards providing legal support and leading evangelizing actions.<\/p>\n As further work, we would like to compare the role foundations play in OSS with the role they have in other kinds of non-governmental organizations (and non-profit organizations in general) where the distinction between the foundation and the organization itself (the software project in our case) is much blurred. Since foundations in OSS are still rather young, we hope that by learning from more established foundations in other fields, as well as best practices of the most senior ones in OSS, we can bring back some useful recommendations for OSS projects interested in setting up its own foundation (or looking for an established one they could join). A more qualitative study, comprising interviews with actual users and contributors of open source projects will also help to explore their opinions and views on the needs and expectations they have from software foundations.<\/p>\n [1] Karan Aggarwal, Abram Hindle, and Eleni Stroulia. 2014. Co-evolution of Project Documentation and Popularity within GitHub. In Int. Conf. on Mining Software Repositories. 360\u2013363.<\/p>\n [2] Mohammad Y. Allaho and Wang-Chien Lee. 2013. Analyzing the Social Ties and Structure of Contributors in Open Source Software Community. In Int. Conf. on Advances in Social Networks Analysis and Mining Analyzing. 56\u201360.<\/p>\n [3] Christian Bird, Alex Gourley, Prem Devanbu, Anand Swaminathan, and Greta Hsu. 2007. Open Borders? Immigration in Open Source Projects. In Int. Conf. on Mining Software Repositories. 6.<\/p>\n [4] Christian Bird, David Pattison, Raissa D Souza, Vladimir Filkov, and Premkumar Devanbu. 2008. Latent Social Structure in Open Source Projects Categories and Subject Descriptors. In Int. Symp. on Foundations of Software Engineering. 24\u201335.<\/p>\n [5] European Comission. 2015. The Economic and Social Impact of Software & Services on Competitiveness and Innovation. (2015).<\/p>\n [6] Valerio Cosentino, Javier Luis C\u00e1novas Izquierdo, and Jordi Cabot. 2017. A Systematic Mapping Study of Software Development With GitHub. IEEE Access5 (2017), 7173\u20137192.<\/p>\n [7] Kevin Crowston, Qing Li, Kangning Wei, U. Yeliz Eseryel, and James Howison. 2007. Self-organization of Teams for Free\/Libre Open Source Software Development. Information and Software Technology 49, 6 (2007), 564\u2013575.<\/p>\n [8] Kevin Crowston, Kangning Wei, James Howison, and Andrea Wiggins. 2012. Free\/Libre open-source software development: What We Know and What We Do Not Know. Comput. Surveys 44, 2 (2012), 1\u201335.<\/p>\n [9] Kevin Crowston, Kangning Wei, Qing Li, U. Yeliz Eseryel, and James Howison. 2005. Coordination of Free\/Libre Open Source Software Development. In Int. Conf. on Information Systems.<\/p>\n [10] Laura Dabbish, Colleen Stuart, Jason Tsay, and Jim Herbsleb. 2012. Social Coding in GitHub: Transparency and Collaboration in an Open Software Repository. In Conf. on Computer Supported Cooperative Work. 1277\u20131286.<\/p>\n [11] Anja Guzzi, Alberto Bacchelli, Michele Lanza, Martin Pinzger, and Arie van Deursen. 2013. Communication in Open Source Software Development Mailing Lists. In Int. Conf. on Mining Software Repositories. 277\u2013286.<\/p>\n [12] James D. Herbsleb and Rebecca E. Grinter. 1999. Splitting the Organization and Integrating the Code: Conway\u2019s Law Revisited. In Int. Conf. on Software Engineering. 85\u201395.<\/p>\n [13] Qiaona Hong, Sunghun Kim, S. C. Cheung, and Christian Bird. 2011. Understanding a Developer Social Network and its Evolution. In Int. Conf. on Software Maintenance. 323\u2013332.<\/p>\n [14] Mitchell Joblin, Sven Apel, and Wolfgang Mauerer. 2017. Evolutionary Trends of Developer Coordination: A Network Approach. Empirical Software Engineering 22, 4 (2017), 2050\u20132094.<\/p>\n [15] Robert E. Kraut and Lynn A. Streeter. 1995. Coordination in Software Development. Comm. ACM 28, 3 (1995), 69\u201381.<\/p>\n [16] Sang-Yong Tom Lee, Hee-Woong Kim, and Sumeet Gupta. 2009. Measuring Open Source Software Success. Omega 37, 2 (2009), 426\u2013438.<\/p>\n [17] Juho Lindman and Imed Hammouda. 2017. Investigating Relationships Between FLOSS Foundations and FLOSS Projects. In Int. Conf. on Open Source Systems. 14\u201322.<\/p>\n [18] C\u00e1novas Izquierdo Javier Luis and Jordi Cabot. 2015. Enabling the Definition and Enforcement of Governance Rules in Open Source Systems. In Int. Conf. on Software Engineering, Software Engineering in Society track. 505\u2013514.<\/p>\n [19] M. Lynne Markus. 2007. The Governance of Free\/Open Source Software Projects: Monolithic, Multidimensional, or Configurational? Journal of Management & Governance 11, 2 (2007), 151\u2013163.<\/p>\n [20] Siobh\u00e1n O\u2019Mahony. 2007. Non-Profit Foundations and their Role in Community-Firm Software Collaboration. MIT Press, 393\u2013414.<\/p>\n [21] Siobh\u00e1n O\u2019Mahony and Fabrizio Ferraro. 2007. The Emergence of Governance in an Open Source Community. Academy of Management Journal 50, 5 (2007), 1079\u20131106.<\/p>\n [22] Sebastiano Panichella, Gerardo Canfora, Massimiliano Di Penta, and Rocco Oliveto. 2014. How the Evolution of Emerging Collaborations Relates to Code Changes: An Empirical Study. In Int. Conf. on\u00a0 Program Comprehension. 177\u2013188.<\/p>\n [23] Martin Pinzger and Arie Van Deursen. 2014. An Exploratory Study of the Pullbased Software Development Model. In Int. Conf. on Software Engineering. 345\u2013355.<\/p>\n [24] Dirk Riehle. 2010. The Economic Case for Open Source Foundations. IEEE Computer 43, 1 (2010), 86\u201390.<\/p>\n [25] Dirk Riehle and Sebastian Berschneider. 2012. A Model of Open Source Developer Foundations. In Int. Conf. on Open Source Systems. 15\u201328.<\/p>\n [26] Ravi Sen, Siddhartha S. Singh, and Sharad Borle. 2012. Open Source Software Success: Measures and Analysis. Decision Support Systems 52, 2 (2012), 364\u2013372.<\/p>\n [27] Diomidis Spinellis and Vaggelis Giannikas. 2012. Organizational adoption of open source software. Journal of Systems and Software 85, 3 (2012), 666\u2013682.<\/p>\n [28] Parastou Tourani, Bram Adams, and Alexander Serebrenik. 2017. Code of Conduct in Open Source Projects. In Int. Conf. on Software Analysis, Evolution and Reengineering. 24\u201333.<\/p>\n [29] Bogdan Vasilescu, Daryl Posnett, Baishakhi Ray, Mark G. J. van den Brand, Alexander Serebrenik, Premkumar T. Devanbu, and Vladimir Filkov. 2015. Gender and Tenure Diversity in GitHub Teams. In Conf. on Human Factors in Computing Systems. 3789\u20133798.<\/p>\n [30] Minghui Zhou and Audris Mockus. 2015. Who Will Stay in the FLOSS Community? Modeling Participant\u2019s Initial Behavior. Software Engineering, IEEE Transactions on 41, 1 (2015), 82\u201399.<\/p>\n Feature Photo by\u00a0Mpho Mojapelo<\/a>\u00a0on\u00a0Unsplash<\/a><\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" A number of Open-Source Systems (OSS) have created parallel foundations, as legal instruments to better articulate the structure, collaboration and financial model for the project. We study over 80 foundations to analyze the impact they have on the open source projects the foundations aim to help.<\/p>\n","protected":false},"author":3,"featured_media":118543,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[10,9],"tags":[63,64,77],"_links":{"self":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts\/118531"}],"collection":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/comments?post=118531"}],"version-history":[{"count":0,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts\/118531\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/media\/118543"}],"wp:attachment":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/media?parent=118531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/categories?post=118531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/tags?post=118531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"List](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/OSSfoundationswebsite.png\")
<\/a><\/p>\n\n1 Introduction to open source foundations<\/h2>\n
2 Research Method<\/h2>\n
2.1 Research Questions<\/h3>\n
\n
2.2 Dataset Construction<\/h3>\n
![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-tab1-247x300.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-fig1-300x136.png\")
<\/p>\n3 Results<\/h2>\n
3.1 RQ1: Number of Foundations Supporting Open Source Projects<\/h3>\n
3.2 RQ2: Scope of Software Foundations<\/h3>\n
3.3 RQ3: Role in the Development Process<\/h3>\n
![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-tab2-300x181.png\")
<\/a><\/p>\n3.4 RQ4: Openness<\/h3>\n
![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-tab3-300x251.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-tab4-300x230.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/livablesoftware.com\/wp-content\/uploads\/2018\/02\/icseseis-tab5-300x264.png\")
<\/a><\/p>\n3.5 Additional Discussion Points<\/h3>\n
4. Threats to Validity<\/h2>\n
5. Related Work<\/h2>\n
6. Conclusion<\/h2>\n
References<\/h2>\n