Sensitive geographic data are invaluable assets for the people to whom they belong and their disclosure should be decided by the sovereign data owner (SDO). Due to several high‐profile data breaches and business models that commercialize user data, the need for new approaches to geoprivacy and data sovereignty has grown. We propose MapSafe, a client web application that first obfuscates datasets using donut masking or hexagonal binning, separately, and thereafter implements a multi‐level encryption scheme that permits SDOs to share the final encrypted volume containing the geospatial information when they choose and at a level of detail which they are comfortable. The authenticity verification of the volume is facilitated by storing the hash value corresponding to the encrypted volume immutably on the Blockchain as a public record. Our approach places geoprivacy under data guardians'’ control, and its integration capabilities promote its adoption in existing and future geospatial web systems.

Indigenous peoples should be able to govern data about themselves, their territories, resources, and ways of life, collected by themselves or others. However, the progressive use of cloud computing for the geoweb raises data security and privacy concerns. We propose a complete and trustless approach for indigenous geospatial data sovereignty on the cloud by furnishing security functions at the core—the web browser. Geomasking permits sharing an anonymized dataset with less privileged users, while the original is protected and shared with sovereign data owners via public‐key encryption. The encrypted dataset's hash value is notarized on the blockchain for the verification of its authenticity when on the cloud. The application was designed for the protection of Biodiversity Management Areas stewarded by the Māori people in Aotearoa New Zealand. It enables diversified functions of geospatial data protection compared with previous works focusing on the cloud by solving data‐sharing problems without relying on a third party.

Governance has been highlighted as a key factor in the success of an Open Source Software (OSS) project. It is generally seen that in a mixed meritocracy and autocracy governance model, the decision-making (DM) responsibility regarding what features are included in the OSS is shared among members from select roles; prominently the project leader. However, less examination has been made whether members from these roles are also prominent in DM discussions and how decisions are made, to show they play an integral role in the success of the project. We believe that to establish their influence, it is necessary to examine not only discussions of proposals in which the project leader makes the decisions, but also those where others make the decisions. Therefore, in this study, we examine the prominence of members performing different roles in: (i) making decisions, (ii) performing certain social roles in DM discussions (e.g., discussion starters), (iii) contributing to the OSS development social network through DM discussions, and (iv) how decisions are made under both scenarios. We examine these aspects in the evolution of the well-known Python project. We carried out a data-driven longitudinal study of their email communication spanning 20 years, comprising about 1.5 million emails. These emails contain decisions for 466 Python Enhancement Proposals (PEPs) that document the language’s evolution. Our findings make the influence of different roles transparent to future (new) members, other stakeholders, and more broadly, to the OSS research community.

Governance has been highlighted as a key factor in the success of an Open Source Software (OSS) project. It is generally seen that in a mixed meritocracy and autocracy governance model, the decision-making (DM) responsibility regarding what features are included in the OSS is shared among members from select roles; prominently the project leader. However, less examination has been made whether members from these roles are also prominent in DM discussions and how decisions are made, to show they play an integral role in the success of the project. We believe that to establish their influence, it is necessary to examine not only discussions of proposals in which the project leader makes the decisions, but also those where others make the decisions. Therefore, in this study, we examine the prominence of members performing different roles in: (i) making decisions, (ii) performing certain social roles in DM discussions (e.g., discussion starters), (iii) contributing to the OSS development social network through DM discussions, and (iv) how decisions are made under both scenarios. We examine these aspects in the evolution of the well-known Python project. We carried out a data-driven longitudinal study of their email communication spanning 20 years, comprising about 1.5 million emails. These emails contain decisions for 466 Python Enhancement Proposals (PEPs) that document the language's evolution. Our findings make the influence of different roles transparent to future (new) members, other stakeholders, and more broadly, to the OSS research community.

Group decision‐making (GDM) processes shape the evolution of open source software (OSS) products, thus playing an important role in the governance of open source software communities. While these GDM processes have attracted the attention of researchers, the rationale behind decisions, that is, how decisions are made that enhance the OSS, have not received much attention. This work bridges this gap by extracting these rationales from a large open source repository comprising 1.55 million emails available in Python development archives. This work makes a methodological contribution by presenting a heuristics‐based rationale extraction system called Rationale Miner that employs information retrieval, natural language processing, and heuristics‐based techniques. Using these techniques, it extracts the rationale behind specific decisions (for example, whether a new module was added based on core developer consensus or a benevolent dictator's pronouncement). This work unearths 11 such rationales behind decisions in the Python community and thus makes a knowledge contribution. It also analyzes the prevalence of these rationales across all PEPs and three sub‐types of PEPs: Process, Informational, and Standard Track PEPs. The effectiveness of our contributions has been positively evaluated using quantitative and qualitative approaches (e.g., comparison against baselines for rationale identification showed up to 47% improvement in the most conservative case, and feedback from the Python steering committee showed the accurate identification of rationales respectively). The approach proposed in this work can be used and extended to discover the rationale behind decisions that remain hidden in communication repositories of other OSS projects, which will make the decision‐making (DM) process transparent to stakeholders and encourage decision‐makers to be more accountable.