PaperlayerView exact revision on arXiv

Source-linked AI summary

A Cartography of Open Collaboration in Open Source AI: Mapping Practices, Motivations, and Governance in 14 Open Large Language Model Projects

Johan Linåker, Cailean Osborne, Jennifer Ding, Ben Burtenshaw

arXiv:2509.25397v2cs.SEcs.AIcs.LG

TL;DR

Open LLM collaboration across development and reuse has not been systematically studied, limiting understanding of how projects are organised and governed. This study interviews developers from 14 projects and finds collaboration across multiple artefact domains, shifting from selective early engagement to broader participation after release. It concludes that openness emerges from how collaboration is organised across domains, lifecycle stages, and institutional contexts.

  • Problem

    Collaboration methods across the open LLM lifecycle have not been systematically studied, leaving limited understanding of how projects are initiated, organised, and governed.

    Source: §1 · p. 2

  • Method

    The authors conduct semi-structured interviews with 17 developers from 14 open LLM projects, including models shared under permissive and restrictive licenses.

    Source: §1 · p. 2, §4.1 · p. 7

  • Results

    Collaboration spans multiple artefact domains and shifts from selective, centralised engagement early on to broader, distributed participation after release.

    Source: §1 · p. 2, §9 · p. 28

  • Takeaways & Limitations

    Openness in open source AI is an emergent outcome of collaboration organised across artefact domains, lifecycle stages, and institutional contexts.

    Source: §9 · p. 28

    Post-training collaboration is constrained by technical complexity, resource demands, competitive sensitivity, rapid iteration, and a lack of standardised frameworks.

    Source: §5.2 · p. 13

Abstract

from arXiv · show

The proliferation of open large language models (LLMs) is fostering a vibrant ecosystem in artificial intelligence (AI). However, the methods of collaboration used to develop open LLMs, both before and after their public release, have not yet been systematically studied, limiting our understanding of how open LLM projects are initiated, organised, and governed, as well as the opportunities to further foster this ecosystem. We address this gap through an exploratory analysis of open collaboration throughout the development and reuse lifecycle of open LLMs, drawing on semi-structured interviews with the developers of 14 diverse open LLM projects. These collaborations span multiple artefact domains -- including models, data, software, evaluation, compute, and community engagement -- each enabling distinct forms of participation and involving different stakeholders that evolves across the LLM development lifecycle, shifting from concentrated, selective engagement in the early stages to broader, distributed participation after model release. The open LLM developers are motivated by a variety of social, economic, and technological motivations, ranging from democratising access to AI and promoting open science to building regional ecosystems and expanding language representation. These dynamics are coordinated through a range of governance structures, typically formal and professionalised to varying degrees, including centralised company-led efforts to decentralised grassroots initiatives. We synthesise our findings in a conceptual model of open collaboration in open LLM ecosystems, provide recommendations for practice, and conclude that openness in open source AI is not a uniform property but an emergent outcome of how collaboration is organised across interconnected artefact domains, lifecycle stages, and institutional contexts.

1. Introduction

Open LLM collaboration has expanded, but its practices across development and reuse remain insufficiently mapped. This study examines those practices, motivations, and governance through interviews with developers from 14 projects.

1. Introduction

  • The study uses semi-structured interviews with 17 developers from 14 projects spanning organisational contexts and regions.Source: §1 · p. 2
  • The study maps open collaboration across the LLM lifecycle, identifying six interdependent artefact domains rather than focusing on models alone.The domains are models, data, software, evaluation, compute, and community.Source: §1 · p. 2
  • Participation access, expertise requirements, modularity, and control shape who can contribute and how collaboration unfolds across domains.Source: §1 · p. 2
  • Collaboration shifts from selective, centralised engagement in early development to broader, distributed participation after release.Source: §1 · p. 2
  • The authors synthesize their findings into a conceptual model linking artefact domains, lifecycle dynamics, motivations, and governance, and derive practice recommendations.Source: §1 · p. 2

2. Key terms

The paper defines the terms and lifecycle stages used to describe open LLM collaboration, from initial training through post-release reuse.

2.1. LLMs

  • LLMs are deep learning models, typically transformer-based, trained on extensive text corpora to perform language tasks without task-specific training.Source: §2.1 · p. 2

2.2. Open Collaboration

  • Figure 1 presents a cartography of open collaboration in open source AI across 14 open LLM initiatives.Source: Figure 1 · p. 3

2.3. Open LLM development and reuse lifecycle

  • The open LLM lifecycle covers training activities through reuse and redistribution after public release, spanning pre-training, post-training, and post-release reuse.Source: §2.3 · p. 4

2.3.1. Pre-training

  • Pre-training builds a base model from scratch using data, compute, software frameworks, and model architecture, producing checkpoints and initial evaluations.Source: §2.3.1 · p. 4

2.3.2. Post-training

  • Post-training refines a base model before release through methods such as supervised fine-tuning, preference alignment, and safety filtering.Its outputs include refined weights, safety evaluations, and task benchmarks.Source: §2.3.2 · p. 4

2.3.3. Post-release reuse

  • After release, models can be adapted into derivatives and shared, while users can send developers feedback through repositories and community channels.Source: §2.3.3 · p. 4

3. Related work

Prior work documents a growing but uneven open AI ecosystem and offers frameworks for openness, motivations, and governance. The authors identify empirical gaps in lifecycle-wide collaboration, developer motivations, and coordination in open LLM projects.

3.1. Open collaboration in AI R&D

  • Open AI collaboration spans software, datasets, research dissemination, standards, hardware, and models, while platform activity and contributions are concentrated and often short-lived.Grassroots projects have also demonstrated community-led LLM development from early stages.Source: §3.1 · pp. 4–5

3.2. Openness vs. Open Source in AI

  • Openness frameworks define AI through different combinations of released components, licensing, transparency, reusability, and system-stack coverage.Source: §3.2 · p. 5

3.3. Motivations of open LLM developers

  • Motivations attributed to open LLM developers remain largely anecdotal, and distinctions from OSS—including technical expertise and resource demands—warrant dedicated study.Source: §3.3 · p. 6

3.4. Governance and coordination in open LLM projects

  • OSS governance ranges from centralised authority to community consensus, with open LLM projects also facing strategic, organisational, cultural, legal, ethical, and business considerations.Source: §3.4 · p. 6

3.5. Summary

  • The review identifies three gaps: lifecycle-wide collaboration mapping, systematic evidence on motivations, and study of open LLM governance and coordination.Source: §3.5 · p. 7

4. Methods & Data

The study investigates collaboration across open LLM development and reuse using a qualitative design and purposeful sampling of mature, diverse projects.

4.1. Research aims and scope

  • The study aims to understand how open collaboration is practised and can be further enabled throughout the open LLM lifecycle.It includes LLMs shared on Hugging Face Hub under permissive or restrictive licenses, using “open LLMs” as a convenient sample label rather than a normative definition.Source: §4.1 · p. 7

4.2. Research design

  • A qualitative research design uses interviews to capture socio-technical practices and variation across projects, organisations, and geographies.Source: §4.2 · p. 7

4.2.1. Interviewee sampling

  • Purposeful sampling selected mature, distinct projects, beginning with Hugging Face text-generation base models whose derivatives had been adapted more than 100 times.The researchers narrowed the set to the 250 most-downloaded models, using recent downloads as a proxy for activity and popularity.Source: §4.2.1 · p. 7

I15 AI Lab, National Library of Norway

The project entries name model families, datasets, and dissemination venues; the dataset counts refer to Hugging Face-hosted datasets at the time of the research.

I10 SpeakLeash Foundation

  • Listed projects include Mistral 7B, Bielik V1-3, and ALLaMo 1, alongside the Open PL LLM Leaderboard, Chat Arena, and the Obywatel Bielik app.Source: I10 SpeakLeash Foundation · p. 8
  • Other entries name Typhoon v1-2 with 26 datasets and Teuken-7B-v0.4 and Teuken-7B-v0.6.Source: I10 SpeakLeash Foundation · p. 8
  • Listed dissemination venues include Hugging Face, X, Modelscope, GitHub, and Gitee; dataset counts refer to datasets hosted on Hugging Face Hub when the research was conducted.Source: I10 SpeakLeash Foundation · p. 8

I7 Beijing Academy of AI (BAAI)

The section describes the sampled-project information and explains how projects were selected, interviews conducted, and interview data analysed.

I7 Beijing Academy of AI (BAAI)

  • Downloads and repository discussions served as rough proxies for technical and social activity; the team added community-driven projects after noticing their absence from the initial sample.Source: I7 Beijing Academy of AI (BAAI) · p. 9

4.2.2. Interview process

  • Interviews were semi-structured, typically lasted 30–60 minutes, and were recorded, transcribed, and managed under a data management plan.Source: §4.2.2 · p. 9

4.2.3. Data analysis

  • One author coded transcripts using an abductive approach, a second reviewed the codes, and the team iteratively refined themes through discussion.Source: §4.2.3 · p. 9
  • After a tentative synthesis following interview 10, the team broadened sample diversity through interviews 11–17 and concluded data collection after judging saturation reached.Source: §4.2.3 · p. 9

5. Collaboration Challenges and On-ramps throughout the Open LLM Lifecycle (RQ1)

This section examines collaboration opportunities and barriers across the open LLM lifecycle, from pre-training and post-training through release. It covers post-release software maintenance and improvement, shared evaluation, and external research using open artefacts, including how these activities can inform future development.

5.1.1. Pre-training: Model Collaborations

  • Pre-training model collaboration includes partnerships and model reproduction, but secrecy, upfront planning, and specialist expertise constrain participation.External domain experts can provide targeted technical advice without full-time commitment.Source: §5.1.1 · p. 11

5.1.2. Pre-training: Data Collaborations

  • Pre-training data collaboration addresses legal and sharing barriers through provenance standards, community curation, strategic partnerships, and reuse or creation of datasets for underrepresented languages and unmet needs.Curating data receives fewer resources than model training, while its preparation costs and competitive value discourage sharing.Source: §5.1.2 · pp. 11–12

5.1.3. Pre-training: Software Collaborations

  • Pre-training software and evaluation collaboration builds shared frameworks, portable tools, benchmarks, and evaluation resources, but expertise demands and fragmented or internal infrastructure limit contributions.Lower-barrier software contributions include reporting bugs, while evaluation collaboration includes crowdsourced datasets and unified leaderboards.Source: §5.1.3 · p. 12, §5.1.4 · p. 12

5.1.5. Pre-training: Non-technical Collaborations

  • Pre-training non-technical contributions share methods, logs, and outreach, while compute partnerships and provider programs help projects access scarce training resources.Supercomputing centres can provide compute while gaining opportunities to test and benchmark infrastructure.Source: §5.1.5 · pp. 12–13, §5.1.6 · p. 13

5. Collaboration Challenges and On-ramps throughout the Open LLM Lifecycle (RQ1)

  • Collaboration spans diverse pre-training activities, remains limited during post-training, and becomes more open and community-engaged during post-release reuse.Pre-training includes work on datasets, frameworks, documentation, and compute partnerships; post-training activities mostly remain internal, while reuse encompasses dissemination, derivative development, feedback, and improvements to related artefacts.Source: §5.2 · p. 13

5.2. Post-training Stage

  • Post-training collaboration is limited: selected partners test intermediate checkpoints, released datasets enable reuse, and technical complexity, competitive sensitivity, and rapid iteration impede broader involvement.BAAI reported that its Infinity Instruct dataset had been used to post-train over 130 models within three months.Source: §5.2 · p. 13, §5.2.1 · p. 13, §5.2.2 · p. 13

5.2.3. Post-training: Evaluation Collaborations

  • Evaluation is post-training’s most collaborative aspect, as developers use community benchmarks, evaluation infrastructure, and leaderboards to assess and communicate model capabilities.Community resources support broad capability testing, including benchmarks not monitored during training.Source: §5.2.3 · p. 14

5.3. Post-release Reuse Stage

  • After release, platform-mediated reuse and regional partnerships enable derivatives and wider access, while engagement is often indirect, feedback reactive, and geographic restrictions or licensing can exclude collaborators.Post-release data collection can sustain community contributions and expand language coverage.Source: §5.3 · p. 14, §5.3.1 · pp. 14–15, §5.3.2 · p. 15

5.3.3. Post-release: Software Collaborations

  • Post-release software collaboration combines framework maintenance with academic upstream improvements and external testing or feedback, though some organisations face resource constraints.Research groups often contribute grant-funded optimisations and features, while external feedback can improve usability, performance, and applicability to new use cases.Source: §5.3.3 · p. 15

5.3.4. Post-release: Evaluation Collaborations

  • Community-managed evaluation platforms support standardised model comparisons and continuous community updates to benchmarks, results, models, and capabilities.They provide shared evaluation infrastructure and a neutral basis for users to make informed model selections.Source: §5.3.4 · p. 15

5.3.5. Post-release: Non-technical Collaborations

  • External research on open artefacts can create feedback loops that inform future model development and generate unexpected value for original developers.Land and Bartolo [80] found that “glitch tokens” can cause repeatable model failures, partly traceable to undertrained tokens; full pretraining-corpus release made the hypothesis easier to verify, and the findings informed model improvement.Source: §5.3.5 · p. 16

6. Motivations for engaging in the collaborative development of open LLMs (RQ2)

Open LLM developers cite social, economic, and technological motivations for collaborating across projects and related artefacts. These include widening access and representation, building ecosystems, and advancing open and reproducible research.

6. Motivations for engaging in the collaborative development of open LLMs (RQ2)

  • Social, economic, and technological motivations all incentivise stakeholders to collaborate on open LLMs and related artefacts.The motivations include democratising AI access, building regional ecosystems, and promoting open science.Source: §6 · p. 16

6.1.1. Democratizing access and inclusion in AI development

  • Projects pursue broader AI access and inclusion, community knowledge-sharing, and language and cultural representation, including for underrepresented languages.Examples include the Aya Initiative’s 101 languages, AI Singapore’s 13 Southeast Asian languages and dialects, and initiatives focused on Polish, Thai, and EU languages.Source: §6.1.1 · p. 16, §6.1.2 · p. 16, §6.1.3 · pp. 16–17

6.1.4. Mentorship and skills development

  • Mentorship, public accountability, peer recognition, and personal passion also motivate participation in open LLM projects.Masakhane offers technical and research mentorship; publicly funded projects describe releasing outputs as an obligation to the public.Source: §6.1.4 · p. 17, §6.1.5 · p. 17, §6.1.6 · p. 17

6.2.1. Ecosystem building for competitive advantage

  • Open collaboration is seen as a way to pool resources, avoid duplicated effort, and build regional ecosystems that can compete with leading AI companies.AI Singapore described foundations that are “70% complete,” leaving others to develop the remaining 30%; BigScience contributors also carried work to other organisations.Source: §6.2.1 · pp. 17–18

6.2.2. Resource efficiency through model reuse

  • Reusing base LLMs lets organisations focus resources on customising models for specific languages or domains rather than training from scratch.Projects select base models for application-specific advantages such as language coverage, tokenisation, interoperability, or fine-tuning performance.Source: §6.2.2 · p. 18

6.2.3. Gaining recognition for expertise

  • Recognition, career advancement, and market-entry strategies motivate companies and researchers to release or build on open LLMs.Organisations cite visibility for expertise and talent recruitment, while companies also use models to expand adoption across third-party products and platforms.Source: §6.2.3 · p. 18, §6.2.4 · p. 18, §6.2.5 · p. 18

6.3.1. Promoting open science and reproducibility

  • Some projects aim to reproduce closed-model capabilities openly, while others develop shared frameworks for LLM training and evaluation.Developers also cite demonstrating small models’ competitive capabilities and lower operating costs as a motivation.Source: §6.3.1 · p. 18, §6.3.2 · p. 19, §6.3.3 · p. 19

6.3.3. Demonstrating the capabilities of small models

  • Developers also seek to show that small models can compete with larger models while costing less to operate.Source: §6.3.3 · p. 19

7. Governance and Community Engagement Approaches in Open LLM Projects (RQ3)

Open LLM projects use five organisational models, from single-company control to grassroots arrangements combining central coordination with community-led development. Governance and community engagement vary across these models and lifecycle stages, with less collaboration before release and distributed platforms supporting later participation.

7.1. Organisational Models and Governance Approaches in Open LLM Projects

  • The five organisational models range from single-company and research-institute projects to non-profit- and company-sponsored grassroots projects, with governance shaped by institutional context and resources.Community engagement varies across models and lifecycle stages, and pre-release collaboration is more limited by structural constraints.Source: §7.1 · p. 19, §7 · p. 19

7.1.1. Company-led projects

  • Company-led projects retain central decision-making, typically limit external collaboration before release, and form user communities around released base models.Companies may selectively involve external specialists; licensing can also constrain derivative-model use while permitting adoption under stated terms.Source: §7.1.1 · pp. 19–20

7.1.2. Research institute-led projects

  • Research-institute projects are either driven by one institute or organised across multiple institutions through joint, often grant-funded, partnerships.AI Singapore describes formal partnership procedures and reliance on external partners; OpenGPT-X assigns work packages and partner roles through agreements.Source: §7.1.2 · p. 20, AI Singapore · p. 20

7.1.3. Grassroots organisation-led projects

  • Grassroots projects combine central coordination of critical decisions or infrastructure with decentralised community development.Non-profit-sponsored examples retain a core group’s authority while enabling community work, including tools, educational adaptations, language contributions, and project leadership.Source: §7.1.3 · pp. 20–21
  • Company-sponsored grassroots projects can distribute work among large volunteer communities while leaving substantial influence and final authority with the sponsor.In BigScience, Hugging Face coordinated the project and its Chief Scientific Officer held final decision authority; interview evidence describes committee decision-making as time-consuming and inefficient.Source: §7.1.3 · p. 21

7.2.1. Platform-mediated community building

  • Discord supports real-time knowledge-sharing, Slack supports working-group coordination, and global projects use multiple platforms for asynchronous work and local preferences.Cohere for AI used Discord for asynchronous coordination and resource sharing, while language-community leads also preferred platforms such as WhatsApp.Source: §7.2.1 · p. 21

7.2.2. Community recruitment and growth strategies

  • Recruitment can combine targeted invitations with open calls, while welcoming norms and dedicated community management support participation and continuity.BigScience began with 200–300 targeted invitations before attracting around 1,000 participants; Masakhane hired a community manager after relying on volunteers who could move on.Source: §7.2.2 · pp. 21–22

7.2.3. Community outreach and user engagement

  • Projects use showcases, structured feedback, and collaborative events to engage users, improve services, and build relationships for future collaboration.Typhoon’s Application Week demonstrated possible uses; AI Singapore collects user feedback, and hackathons helped the National Library of Norway build later connections.Source: §7.2.3 · p. 22

8. Discussion

The discussion considers how artefact domains, lifecycle stages, developer motivations, and governance structures interact in open LLM collaboration, drawing implications for research and practice. It also addresses limits to the findings’ validity and reliability, including interpretive classifications and lifecycle boundaries and the potential influence of researchers on qualitative analysis.

8.1. Implications for Research

  • Collaboration spans six interrelated domains—models, data, software, evaluation, compute, and non-technical work—so open source AI cannot be understood through models alone.The authors argue that research should examine how artefacts and stakeholders interact across development and reuse, including within distinct developer communities [13].Source: §8.1 · pp. 22, 24
  • Participation opportunities differ by domain: expertise, accessibility, modularity, ownership, and functional role help explain why some work scales broadly while other work remains concentrated.Models and compute are typically more restricted; software, evaluation, and non-technical work can be more accessible, modular, or community governed. Models, data, and compute are core domains, while the others enable system use and evolution.Source: §8.1 · p. 24
  • Collaboration shifts from selective pre-training to broader post-release engagement, alongside varied social, economic, and technological motivations and governance models.Pre-training centres on resource-intensive core domains, while post-release participation expands through more accessible enabling domains; governance ranges from company-led projects to grassroots initiatives [81].Source: §8.1 · pp. 24–25

8.2.1. AI researchers and developers •; 8.2.2. AI companies •

  • Researchers and companies should engage existing communities, build full-stack expertise, support fair participation, invest in shared ecosystems, and combine core-team coordination with community input.The recommendations also encourage mentorship and fair compensation, hybrid governance, clear data provenance and licensing, and company contributions of compute to open projects.Source: §8.2.1 · p. 26, §8.2.2 · p. 26

8.2.3. Policymakers •

  • Policymakers should fund public AI infrastructure and public-interest compute, support regional language representation, bridge developer-policy work on safety, and clarify open-source licensing.Recommendations include targeted support for language communities and use of licenses aligned with the OSI’s Open Source AI definition in publicly funded projects.Source: §8.2.3 · pp. 26–27

8.2.4. Platform providers •; 8.2.5. Academic institutions •; 8.2.6. Open source foundations •

  • Platforms and academic institutions should enable varied contributions and use licenses that uphold open-source freedoms, while foundations can offer neutral support structures for collaboration.Platform infrastructure can support data annotation, evaluation feedback, and documentation; the paper recommends standard open licenses and foundation support across industry, government, and academia.Source: §8.2.4 · p. 27, §8.2.5 · p. 27, §8.2.6 · p. 27

8.3. Threats to Validity

  • The qualitative findings are limited by possible selection, viewpoint, recall, social-desirability, generalizability, and measurement-proxy biases.The 14 projects are a purposively selected, visible subset hosted on Hugging Face Hub; interviews relied mainly on developers, and download and discussion counts may not capture collaborative engagement fully.Source: §8.3.1 · p. 27, BigScience Workshop · p. 27, §8.3.2 · p. 27

8.3.3. Construct Validity

  • Entity classifications relied on subjective interpretation of online sources, and the extended lifecycle framework may not match practitioners’ views of collaboration boundaries and stages.Potential misclassification is acknowledged.Source: §8.3.3 · p. 28

8.3.4. Reliability

  • Recorded and transcribed interviews, dual coding, audit trails, peer debriefing, member checking, and iterative codebook development supported reliability, but coding remains subjective and researcher-influenced.Different researchers might interpret the same data differently.Source: §8.3.4 · p. 28

9. Conclusion

Open collaboration is neither uniform nor static: it spans multiple artefact domains, changes across lifecycle stages, and varies with motivations and governance. The paper synthesises these dynamics in a conceptual model and recommendations for practice.

9. Conclusion

  • Collaboration spans models, data, software, evaluation, compute, and community engagement, with participation shaped by accessibility, expertise, modularity, and control.These differences affect who can contribute and how collaboration is organised.Source: §9 · p. 28
  • Collaboration shifts from concentrated, selective engagement in early stages to broader, distributed participation after model release.Developers’ motivations span social, economic, and technological aims, while governance ranges from centralised company-led efforts to decentralised grassroots initiatives.Source: §9 · p. 28
  • The conceptual model synthesises artefact domains, lifecycle dynamics, motivations, and governance; recommendations aim to promote collaboration in open LLM projects and open source AI.Source: §9 · p. 28

Appendix B. Collaboration Challenges and On-Ramps

  • Appendix B organises collaboration challenges and on-ramps by lifecycle phase and collaboration area, using phase-plus-number abbreviations.Source: Appendix B · p. 28

Appendix B.1. Pre-training: Model Collaborations

Pre-training model collaboration is constrained by secrecy, resource demands, and specialist expertise, while opportunities include reproduction, strategic partnerships, and expert advice. Data collaboration faces legal and investment barriers but also draws on shared datasets, distributed contributors, and cross-sector expertise.

Appendix B.1. Pre-training: Model Collaborations

  • Organisations guard pre-training methods as competitive secrets, while resource-intensive training requires early collaboration planning and limits spontaneous core-development partnerships.Security constraints on servers and databases can further impede external collaborators.Source: Appendix B.1 · p. 28
  • Pre-training’s technical complexity concentrates meaningful participation in small expert teams, and fast development cycles make sustained collaboration difficult.The passage also describes expertise-based working groups and notes that very large teams may be inefficient.Source: Appendix B.1 · p. 29
  • EleutherAI and Hugging Face reproduced Meta’s first Llama model together, using architecturally similar model code to address licensing limits and broaden access.Source: Appendix B.1 · p. 29
  • Strategic base-model partnerships support derivative capabilities and regional representation, while external advisors provide specialised guidance without full-time commitments.Examples include AI Singapore’s collaborations with Meta and Google and a professor advising Masakhane on machine-translation evaluation.Source: Appendix B.1 · p. 29
  • Copyright and rights-holder concerns constrain dataset sharing and release choices; data curation also receives less attention and investment, discouraging organisations from sharing costly work.Some teams use filtering, dual licensing, legal counsel, or community licensing conventions in response.Source: Appendix B.1 · pp. 29–30
  • Developers build on established open datasets and create specialised datasets to fill capability gaps revealed during model development.CommonCrawl may need additional processing, while the Pile is described as pre-cleaned; FineMath was rebuilt as an open dataset after a comparable dataset was not released.Source: Appendix B.1 · p. 30
  • Crowdsourced annotation and native-speaker contributions support multilingual data quality and culturally specific coverage, alongside strategic partnerships for regional-language data.Contributors included people without ML backgrounds, and one toxicity survey received over 60,000 responses.Source: Appendix B.1 · p. 30
  • Universities and companies contribute complementary data resources and research expertise, while community standards address dataset provenance and licensing trust.EleutherAI’s approaches include reverse-engineering CommonCrawl licensing and creating a vetted list of trusted data sources.Source: Appendix B.1 · p. 31

Appendix B.3. Pre-training: Software Collaborations

Pre-training software collaboration centers on shared frameworks and evaluation tools, while technical complexity, infrastructure dependencies, and compute costs constrain participation. Contributors also share fixes, documentation, and compute partnerships that support broader ecosystem use.

Appendix B.3. Pre-training: Software Collaborations

  • Internal infrastructure dependencies and limited portability shape what teams release, while user needs and vendor work prompt shared features and cross-platform ports.Examples include RLHF support contributed upstream, a PyTorch-to-JAX port, and hardware-provider work to improve framework portability.Source: Appendix B.3 · pp. 31–32
  • Open training frameworks provide foundational infrastructure, but technical expertise and competing tools keep core development concentrated and fragment community effort.Frameworks such as Nanotron and GPT-NeoX lower barriers for other teams, while nonstandardized alternatives can duplicate effort.Source: Appendix B.3 · p. 31
  • Shared evaluation frameworks support reproducible model comparisons, new benchmark integration, and evaluation resources for low- and medium-resource languages.Collaborations also combine datasets and benchmarks into unified leaderboards, with language communities contributing expertise and evaluation materials.Source: Appendix B.3 · pp. 32–33
  • Documentation, training logs, and coordinated blog posts circulate experimental and operational knowledge, while bug reports help community members identify and fix software issues.Complementary posts about an upstream contribution can also give the work visibility and explain the collaboration process.Source: Appendix B.3 · pp. 32–33
  • Pre-training compute costs constrain collaboration, while public-supercomputer, research-credit, and vendor partnerships provide resources and technical support for training.These arrangements can be reciprocal: infrastructure centres gain stress-testing or benchmarking, while developers gain access to compute and hardware expertise.Source: Appendix B.3 · pp. 33–34

Appendix B.8. Post-training: Model Collaborations

Post-training and release create different forms of model collaboration, from selective checkpoint testing and shared datasets to community-led evaluation, adaptations, and applications. Releases can also prompt continued work on language coverage and new collaborative projects.

Appendix B.8. Post-training: Model Collaborations

  • Before release, developers shared intermediate checkpoints with selected startups to gather feedback and test capabilities for post-training.The feedback informed additions before the final instruct model was released.Source: Appendix B.8 · p. 34
  • BAAI’s Infinity Instruct post-training dataset was used by external developers to post-train over 130 models within three months.The developers describe this reuse as an open-source cycle in which users also release models.Source: Appendix B.8 · p. 34
  • Developers use shared benchmark suites and community leaderboards to assess capabilities and compare models against third-party results.Some teams monitor checkpoints during training and submit post-trained models to community-managed platforms for user comparison.Source: Appendix B.8 · pp. 34–35
  • Community adaptations extend released models for regional languages and specialised contexts, sometimes producing derivatives without direct involvement from the original core team.Examples include Lugha Llama for 20 African languages and Aya community-built Maya; the cited account reports Lugha Llama outperformed Llama on Global MMLU.Source: Appendix B.8 · pp. 35–36
  • Startups and enterprises collaborate on demonstrations and specialised applications, including fine-tuning smaller models for use cases such as document processing.The paper reports that specialised small models can achieve strong performance close to larger models while saving inference costs.Source: Appendix B.8 · p. 36
  • Some model releases catalyse follow-up projects that inherit resources and lessons, while domain partnerships apply models in areas such as legal and medical use.BigCode followed BigScience with more direction from the start; Teuken 7B’s release also attracted new collaborations.Source: Appendix B.8 · p. 36
  • BLOOM’s release was followed by language extensions and continued Arabic data sourcing, while other open models prompted specialised datasets and ongoing community data collection.Cohere for AI’s post-release collection site provides a continuing mechanism for community language contributions.Source: Appendix B.8 · p. 36

Appendix B.14. Post-release: Software Collaborations

Post-release software collaboration ranges from upstream framework improvements and evaluation contributions to research feedback on open artefacts. Limited resources can nevertheless constrain how readily released tools become general-purpose software.

Appendix B.14. Post-release: Software Collaborations

  • Limited resources can leave open software insufficiently generalised, documented, or maintained for broad reuse.The National Library of Norway team reports that only a few people used its Whisper code as a project basis and that making it widely usable requires substantial work.Source: Appendix B.14 · p. 36
  • Grant-funded groups and external users contribute upstream framework improvements, testing feedback, and performance or accessibility changes.Examples include Summit/Frontier adaptations to GPT-NeoX, QLoRa support, and test cases and performance-related tools shared with maintainers.Source: Appendix B.14 · p. 37
  • When existing tools do not meet their needs, developers can release alternative frameworks, as Fraunhofer IAIS did with Modalities LLM under an MIT license.The team described its prior option as not easy to use out of the box.Source: Appendix B.14 · p. 37
  • Shared evaluation platforms support cross-model comparison and ongoing community contributions of new evaluation results.AfroBench solicits results for models not covered in its paper and adds them to its ranking.Source: Appendix B.14 · p. 37
  • Research using open artefacts can return insights to original developers, including findings about glitch tokens, undertraining, and training stability.The cited research connected unique token sequences with repeatable failures, and the resulting exploration informed model improvement.Source: Appendix B.14 · pp. 37–38

Appendix C.1. Allen Institute for AI (Ai2)

Appendix C profiles open-model organizations and projects spanning non-profits, government programmes, companies, research consortia, and grassroots collectives. Their work includes models, datasets, software, benchmarks, and language-focused AI initiatives.

Appendix C.1. Allen Institute for AI (Ai2)

  • Ai2 develops openly trained and documented OLMo models, post-training pipelines, multimodal models, software tools, and benchmarks.Its OLMo models use openly licensed datasets, transparent training documentation, and reproducible code.Source: Appendix C.1 · p. 38

Appendix C.2. AI Singapore

  • AI Singapore develops SEA-LION models and Southeast Asian language datasets, while supporting Singapore’s national AI strategy and multilingual collaboration.Its releases include SEA-PILE and SEA-HELM; the profile lists 44 models and 18 datasets.Source: Appendix C.2 · p. 38, Hugging Face · p. 38

Appendix C.3. BigScience Workshop

  • BigScience produced BLOOM and ROOTS through a year-long global workshop, while BAAI combines models, datasets, benchmarks, software, and algorithms in FlagOpen.BigScience also pioneered governance and licensing norms, including RAIL; BAAI’s releases include the Aquila, OpenSeek, and WuDao model families.Source: Appendix C.3 · p. 38, Appendix C.4 · p. 38

Appendix C.5. Cohere Labs

  • Cohere Labs emphasizes responsible open science and multilingual research, while EleutherAI is a grassroots collective focused on open access and research transparency.Cohere Labs supports ethical dataset creation and model documentation; EleutherAI releases model cards and training logs.Source: Appendix C.5 · p. 38, Appendix C.6 · p. 38

Appendix C.7. Hugging Face

  • Hugging Face hosts third-party projects and develops models and OSS libraries; Meta releases Llama models under a license with an acceptable-use policy and attribution requirements.Hugging Face also convenes and coordinates the ecosystem; Meta contributes research, PyTorch, vLLM, and evaluation datasets.Source: Appendix C.7 · p. 38, Appendix C.8 · pp. 38–39

Appendix C.9. SpeakLeash Foundation

  • SpeakLeash develops Polish models and datasets, Typhoon targets Thai language technologies, and inclusionAI pursues open AI projects guided by fairness, transparency, and collaboration.SpeakLeash releases quantised Bielik models for use on less powerful machines; Typhoon releases language, vision, and audio models alongside curated Thai datasets.Source: Appendix C.9 · p. 39, Appendix C.10 · p. 39, Appendix C.11 · p. 39

Appendix C.12. AI Lab, National Library of Norway

  • Norway’s National Library AI Lab releases Nordic-language models and archive datasets, while Masakhane co-creates African-language datasets and models through a decentralised multilingual approach.The Norwegian lab’s projects include NB-BERT and Norwegian Whisper fine-tuning; Masakhane works with researchers, linguists, and communities.Source: Appendix C.12 · p. 39, Appendix C.13 · p. 39

Appendix C.14. OpenGPT-X

  • OpenGPT-X was a 10-partner, government-funded consortium developing open European-language models; its flagship Teuken 7B is described as performant in all 24 official EU languages [90].The consortium was led by Fraunhofer IAIS and released derivative models including Teuken-7B-v0.4 and Teuken-7B-v0.6.Source: Appendix C.14 · p. 39
Loading 2509.25397v2…