Open Source Software Broadcast and Preservation Policy | P2-003

Based on: Global distribution strategy for Mass Production Networks

POLICY AUTHORITY AND SCOPE

Legal Basis

This policy establishes the standardized approach for distributing, preserving, and amplifying all open-source software developed under NTARI organizational frameworks

Policy Authority

• Adoption Authority: NTARI Board of Directors per Bylaws Article VI

• Modification Authority: Program Director with Board notification

• Implementation Authority: Project leads and repository maintainers

• Compliance Monitoring: Secretary coordinates with Program Director

Policy Scope

This policy governs:

• Primary and mirror code repository selection

• Package registry distribution requirements

• Geographic amplification strategies

• Institutional credibility mechanisms

• Long-term preservation procedures

• License compliance verification across all platforms

ARTICLE I: STRATEGIC DISTRIBUTION FRAMEWORK

Section 1.1: Core Distribution Principles

Multi-Layered Distribution Model:

All NTARI-affiliated open-source projects shall implement distribution across five strategic layers:

1. Primary Code Hosting - Developer collaboration and version control

2. Package Distribution - Language-specific ecosystem integration

3. Geographic Amplification - Regional platform presence for global reach

4. Institutional Channels - Government and organization repositories for credibility

5. Preservation Systems - Long-term archival and accessibility

Rationale: Network architecture and civic infrastructure software requires broader distribution than consumer applications. Multi-layer presence ensures: developer trust through familiar platforms, institutional validation through official channels, geographic accessibility across linguistic regions, and resilience through redundant preservation.

Section 1.2: License Compliance Requirements

AGPL-3 and OSI License Verification:

Before submitting to any platform, project maintainers must:

1. Verify platform explicitly supports project's chosen license (AGPL-3, MIT, Apache 2.0, GPL v3, etc.)

2. Document license compatibility in project distribution log

3. Include LICENSE file in all distributed artifacts

4. Reject platforms requiring license modifications or restrictions

5. Avoid platforms with censorship or mandatory government review (specifically: Gitee)

Compliance Documentation: Maintain distribution compliance matrix tracking each platform's license support status.

ARTICLE II: MANDATORY PLATFORMS (TIER 0)

Section 2.1: GitHub - Primary Repository

Status: Non-negotiable baseline for all projects

Implementation Requirements:

• Establish organization or user repository within 7 days of project inception

• Configure repository with:

  • Comprehensive README.md with multilingual project name per P2-002

  • LICENSE file (project's chosen OSI-approved license)

  • CONTRIBUTING.md with contribution guidelines

  • CODE_OF_CONDUCT.md (Contributor Covenant v2.1 or equivalent)

  • .gitignore appropriate to project language/framework

• Enable GitHub Actions for automated testing and deployment

• Configure branch protection rules for main/master branch

• Set up GitHub Discussions or Issues for community engagement

• Tag releases using semantic versioning (MAJOR.MINOR.PATCH)

Responsibilities:

• Project Lead: Repository setup and configuration

• All Contributors: Follow contribution guidelines and Code of Conduct

• Secretary: Verify NTARI organizational repositories list current projects

Section 2.2: Software Heritage - Permanent Archival

Status: Mandatory for long-term preservation

Implementation Requirements:

• Automatic archiving: Verify GitHub repository appears in Software Heritage within 90 days of first commit

• Manual deposit: For immediate archiving needs, use Software Heritage deposit interface

• Documentation: Include Software Heritage SWHID (Software Hash Identifier) in release notes

• Verification: Quarterly check that all releases appear in Software Heritage archive

Process:

1. Software Heritage automatically crawls GitHub repositories

2. Project Lead verifies archival via https://archive.softwareheritage.org/ 

3. Include SWHID in release documentation for persistent citation

4. Secretary maintains master list of NTARI project SWHIDs

Section 2.3: Digital Public Goods Alliance - Institutional Certification

Status: Mandatory for projects serving UN Sustainable Development Goals

Applicability Criteria:

Projects qualifying for DPG certification demonstrate:

• SDG 9 (Industry, Innovation, Infrastructure) alignment

• SDG 11 (Sustainable Cities and Communities) support

• SDG 16 (Peace, Justice, Strong Institutions) advancement

• SDG 17 (Partnerships for the Goals) facilitation

Implementation Requirements:

1. Nomination (within 90 days of v1.0 release):

2. Submit via DPG nomination form or repository integration

3. Document SDG alignment with specific indicators

4. Provide evidence of compliance with 9-indicator standard:

   • OSI-approved license (AGPL-3, MIT, Apache 2.0, etc.)

   • Clear documentation of ownership

   • Platform independence

   • Do no harm assessment

   • Privacy and security documentation

   • Appropriate data standards

   • Mechanism for extracting data

   • Adherence to relevant standards

5. Assessment Process:

6. Communities of Practice review application

7. Address feedback and documentation requests

8. Maintain communication with DPG reviewers

9. Certification Maintenance:

10. Update DPG registry with major releases

11. Maintain 9-indicator compliance

12. Report usage in pathfinder countries (if applicable)

Responsibilities:

• Project Lead: Prepare and submit DPG nomination

• Program Director: Review SDG alignment and strategic fit

• Secretary: Track certification status and maintain records

ARTICLE III: REQUIRED DISTRIBUTION PLATFORMS (TIER 1)

Section 3.1: GitLab - Secondary Repository Mirror

Status: Required for all projects as GitHub alternative

Implementation Requirements:

• Establish GitLab repository mirror within 30 days of GitHub repository creation

• Configure automated synchronization:

  • Push-mirror from GitHub to GitLab on every commit

  • Synchronize tags and releases

  • Mirror GitHub Issues to GitLab Issues (optional but recommended)

• Enable GitLab CI/CD pipeline for independent verification

• Configure container registry for Docker images (if applicable)

Rationale: Provides enterprise DevSecOps credibility, mitigates single-platform dependency, offers self-hosted options for sovereignty concerns.

Section 3.2: Package Registries (Language-Specific)

Implementation Requirements Based on Project Type:

Python Projects (PyPI)

Mandatory if project includes Python components, libraries, or CLI tools.

Implementation checklist:

• Create setup.py or pyproject.toml with complete metadata

• Register project on PyPI

• Configure automated publishing via GitHub Actions

• Include comprehensive documentation on PyPI project page

• Follow semantic versioning for releases

• Test installation across Python versions (3.8+)

JavaScript/Node.js Projects (npm)

Mandatory if project includes JavaScript/Node.js components.

Implementation checklist:

• Create package.json with complete metadata

• Register package on npmjs.com

• Configure automated publishing via GitHub Actions

• Include comprehensive README for npm package page

• Follow semantic versioning for releases

• Test installation across Node versions (LTS+)

Containerized Applications (Docker Hub)

MANDATORY for all network architecture and infrastructure software.

Implementation checklist:

• Create Docker Hub organization or user account

• Build multi-architecture images (amd64, arm64)

• Configure automated builds via GitHub Actions

• Tag images with semantic versioning and 'latest'

• Include LICENSE in Docker image filesystem

• Document container usage in README.md

• Provide docker-compose.yml examples

• Security scan images before publishing

Rationale: Containerization is standard deployment for modern infrastructure. Docker Hub provides 10-100x distribution multiplier vs. code hosting alone.

System Packages (Debian/Ubuntu)

Required for projects intended for system-level deployment.

Implementation requirements:

• Create .deb package following Debian Policy

• Seek Debian Developer sponsorship

• Submit to Debian NEW queue or Ubuntu PPA

• Maintain package through release cycles

• Respond to bug reports and security updates

Timeline: Package submission within 6 months of v1.0 release (longer timeline due to sponsorship process).

Section 3.3: Archive.org - Backup and Historical Preservation

Status: Required for all projects

Implementation Requirements:

• Create Internet Archive account for NTARI organization

• Upload full repository snapshots at major releases:

  • Complete source code tarball/zip

  • Compiled binaries (if applicable)

  • Documentation archive

  • Release notes and changelogs

• Upload annually between major releases

• Include metadata: project name, version, license, description

• Tag with keywords: open-source, network-architecture, civic-tech, NTARI

Process:

1. Generate complete source archive at release

2. Upload to Internet Archive with descriptive metadata

3. Record Archive.org URL in release notes

4. Maintain inventory of all archived versions

ARTICLE IV: GEOGRAPHIC AMPLIFICATION STRATEGY (TIER 2)

Section 4.1: Regional Platform Selection

Implementation Timeline: Within 6 months of v1.0 release

Required Geographic Coverage:

Projects shall establish presence in platforms serving these linguistic regions:

1. Chinese-Speaking Regions - Minimum 2 platforms

2. Latin America - Minimum 1 platform (if Spanish/Portuguese localization exists)

3. India - Minimum 1 platform (if Hindi localization exists)

4. Middle East/North Africa - Minimum 1 platform (if Arabic localization exists)

5. Europe - Minimum 1 platform

Section 4.2: Chinese-Speaking Regions (2+ platforms required)

PROHIBITED: Gitee

• Mandatory government code review contradicts open-source principles

• Manual censorship without explanation creates unacceptable risks

• DO NOT use under any circumstances

RECOMMENDED Platforms:

Tier 1 - Community Presence (Required: Select minimum 1):

• OSChina (开源中国) - Developer community, project directory

• CSDN (中国软件开发者网络) - Technical articles, community engagement

Tier 2 - Code Hosting (Required: Select minimum 1):

• http://Coding.net  (腾讯云 CODING) - Enterprise DevOps platform

• Gitcode - Alternative Git hosting

• AtomGit - Developer community platform

Tier 3 - Automated Mirrors (Automatic):

• Package registries automatically mirror to http://cnpmjs.org , Alibaba mirrors, Tencent mirrors

• No direct action required; verify availability

Implementation Process:

1. Translate README.md to Simplified Chinese

2. Establish presence on selected Tier 1 platform (community profile, project listing)

3. Mirror repository to selected Tier 2 platform with synchronized updates

4. Monitor package registry mirror availability

5. Engage with Chinese developer community through translated documentation

Section 4.3: Latin America (1+ platform required)

If Spanish or Portuguese localization exists:

Required Platforms (Select minimum 1):

• Software Público Brasileiro - If government partnership potential (Portuguese)

• Codeando México - If civic tech focus (Spanish)

• SciELO - If academic research component (Spanish/Portuguese)

Implementation Process:

1. Complete Spanish or Portuguese README.md translation

2. Submit to selected platform per their requirements

3. Engage with regional civic tech or academic communities

4. Maintain localized documentation

Section 4.4: India (1+ platform required)

If Hindi localization exists:

Required Platforms (Select minimum 1):

• OpenForge - Government open-source projects

• TechGig - Developer community and competitions

• FOSS United - Community membership and engagement

Implementation Process:

1. Complete Hindi README.md translation

2. Submit to selected platform

3. Engage with Indian developer and civic tech communities

Section 4.5: Middle East/North Africa (1+ platform required)

If Arabic localization exists:

Required Platforms (Select minimum 1):

• Code for MENA - If civic tech applications

• Saudi Arabia National Digital Platform - If government partnership

• UAE Pass Developer Portal - If government integration

Section 4.6: Europe (1+ platform required)

Required Platforms (Select minimum 1):

• Codeberg - Ethics-focused free software hosting (Germany)

• http://code.europa.eu - If EU institutional relationship

• EU Open Source Solutions Catalogue - Via national catalogue submission

ARTICLE V: INSTITUTIONAL CREDIBILITY CHANNELS (TIER 3)

Section 5.1: Government and International Organization Repositories

Applicability: Projects with government, public sector, or international development applications

Available Platforms:

International Organizations:

• World Bank GitHub - Development sector focus

• UNDP GitHub - Human development applications

• UNICEF GitHub - Child welfare and education applications

• Inter-American Development Bank GitHub - Latin American development

Government Platforms:

• http://Code.gov (United States) - Federal open-source code

• http://code.gouv.fr (France) - French government open-source

• Open CoDE (Germany) - German government open-source

• http://code.europa.eu (European Union) - EU institutional code

Implementation Process:

1. Qualification Assessment:

2. Evaluate project's government or institutional applicability

3. Review platform submission requirements

4. Prepare required documentation and compliance evidence

5. Partnership Development:

6. Identify relevant government agency or international organization program

7. Establish communication channel with platform administrators

8. Present project alignment with platform mission

9. Submission and Maintenance:

10. Complete platform-specific submission process

11. Provide required metadata and documentation

12. Maintain project listing with updates

13. Report usage statistics if requested

Responsibilities:

• Program Director: Assess institutional alignment and approve submissions

• Project Lead: Prepare documentation and manage submission

• Secretary: Track institutional platform presence and maintain records

Section 5.2: Non-Profit Technology Coalitions

Code for America / Code for All Network:

• Applicability: Civic tech applications, government transparency tools

• Implementation: Engage with local Code for [Country] chapters

• Value: Brigade networks, government partnerships, policy influence

Open Knowledge Foundation:

• Applicability: Open data, open government, open science projects

• Implementation: Community engagement, align with OKFN principles

• Value: Global advocacy, policy connections

Mozilla Open Source Support (MOSS):

• Applicability: Infrastructure-critical projects, security-focused tools

• Implementation: Apply for relevant MOSS track (foundational technology, secure open source, mission partners)

• Value: Funding for security audits, infrastructure support, recognition

Civic Tech Organizations:

• Participate in civic tech conferences and events

• Submit projects to civic tech showcases

• Engage with civic tech research communities

ARTICLE VI: DEVELOPER DISCOVERY PLATFORMS (TIER 4)

Section 6.1: Automated Discovery Platforms

These platforms automatically index from primary repositories - verification required only:

• http://Libraries.io - Verify project appears within 90 days of first package release

• Sourcegraph - Verify repository indexed (public repositories automatic)

• Open Hub - Claim project and maintain accurate information

• SearchCode - Automatic indexing from public repositories

Implementation Process:

1. Publish to primary platforms (GitHub, GitLab, package registries)

2. Wait 30-90 days for automatic indexing

3. Verify project appears in search results

4. Claim project profiles where available (Open Hub)

5. Maintain accurate project descriptions

Section 6.2: Manual Submission Discovery Platforms

Required submissions within 90 days of v1.0 release:

AlternativeTo:

• Submit project as alternative to proprietary solutions

• Provide comprehensive feature comparison

• Maintain listing with updates

• Engage with user reviews and feedback

Free Software Directory (FSF):

• Submit detailed project entry

• Emphasize free software principles

• Document AGPL-3 or other free software license

• Maintain accurate technical specifications

Implementation Checklist:

• [ ] Prepare project description (200-500 words)

• [ ] Create feature list and comparison matrix

• [ ] Capture screenshots or demo videos

• [ ] Document system requirements

• [ ] Submit to AlternativeTo

• [ ] Submit to FSF Free Software Directory

• [ ] Monitor listings for accuracy

ARTICLE VII: PRESERVATION AND ARCHIVAL PROCEDURES (TIER 5)

Section 7.1: Academic Repository Distribution

Zenodo (CERN) - Required for Research-Oriented Projects:

Implementation Process:

1. GitHub Integration (Recommended):

2. Connect GitHub repository to Zenodo

3. Configure automatic DOI assignment for releases

4. Zenodo creates permanent archive with DOI for each GitHub release

5. Manual Upload (Alternative):

6. Create Zenodo account

7. Upload release archives manually

8. Provide comprehensive metadata

9. Assign software category and keywords

Metadata Requirements:

• Title: Full project name in English + multilingual names

• Authors: All contributors with ORCID (if available)

• Description: Comprehensive project description

• License: Exact license identifier (AGPL-3.0, MIT, etc.)

• Keywords: Relevant technical and domain keywords

• Related identifiers: GitHub URL, Software Heritage SWHID

• Version: Semantic version number

• Programming languages: All languages used

• Operating systems: Supported platforms

Zenodo Benefits:

• DOI for academic citation

• Integration with Software Heritage (automatic SWHID)

• EU-funded permanent storage

• Research database visibility

Other Academic Repositories (Optional):

• Figshare - Research output preservation

• Dataverse - Institutional repository network

• DSpace - Institutional repository deposits

Section 7.2: Decentralized Storage Implementation

IPFS (InterPlanetary File System) - Recommended for Censorship Resistance:

Implementation Requirements:

1. Release Distribution:

2. Add release tarballs/zips to IPFS

3. Pin content on persistent IPFS node or pinning service

4. Include IPFS CID (Content Identifier) in release notes

5. Provide IPFS gateway URLs for easy access

6. Pinning Service Selection:

7. Use Pinata, Web3.Storage, NFT.Storage, or similar

8. Maintain pinned content for project lifetime

9. Monitor pinning service health

10. Documentation:

11. Include IPFS access instructions in README.md

12. Provide both IPFS native addresses (ipfs://) and HTTP gateway URLs

13. Document how to verify content integrity via CID

Blockchain-Based Archival (Optional - Long-Term Preservation):

Filecoin:

• For critical long-term archival (10+ year horizon)

• Pay-once storage with cryptographic verification

• Implementation: Store major releases and comprehensive documentation

Arweave:

• For permanent archival with single payment

• Implementation: Store foundational documentation and major version releases

Implementation Decision Criteria:

• Project maturity: v1.0+ releases

• Long-term importance: Infrastructure or foundational software

• Budget availability: Filecoin/Arweave require payment

• Technical capacity: Team ability to manage decentralized storage

Process:

1. Evaluate project criticality and long-term preservation needs

2. Select appropriate blockchain storage platform

3. Upload key artifacts with comprehensive metadata

4. Document storage locations and access methods

5. Include retrieval instructions in project documentation

Section 7.3: Preservation Verification and Monitoring

Quarterly Preservation Audit (Secretary Responsibility):

Verify all NTARI projects maintain presence on:

• [ ] Software Heritage (automatic archival confirmed)

• [ ] Internet Archive (manual uploads current)

• [ ] Zenodo (DOIs assigned for all major releases)

• [ ] IPFS (content pinned and accessible via gateways)

Annual Comprehensive Review:

• Audit all distribution platforms for accuracy

• Verify license compliance across all platforms

• Update project metadata on all platforms

• Assess new platform opportunities

• Remove deprecated or non-functional platforms

Documentation Requirements:

• Maintain master distribution matrix in project wiki

• Track platform status (active, deprecated, removed)

• Document access URLs and identifiers (SWHIDs, DOIs, IPFS CIDs)

• Record submission dates and contact information

ARTICLE VIII: IMPLEMENTATION TIMELINE AND PHASES

Section 8.1: Immediate Implementation (Week 1)

Upon project inception or policy adoption:

• [ ] Establish GitHub repository

• [ ] Configure repository with LICENSE, README, CONTRIBUTING, CODE_OF_CONDUCT

• [ ] Set up GitHub Actions for CI/CD

• [ ] Create GitLab mirror with auto-sync

• [ ] Submit to Software Heritage (verify automatic archiving)

• [ ] Upload initial archive to Archive.org

Responsibility: Project Lead

Timeline: 7 days from project inception

Approval: Program Director verification

Section 8.2: Short-Term Expansion (Month 1)

Within 30 days of v0.1.0 alpha release:

• [ ] Publish to appropriate package registry (PyPI, npm, Docker Hub)

• [ ] Create Zenodo account and configure GitHub integration

• [ ] Begin DPG Alliance nomination preparation (if applicable)

• [ ] Configure IPFS distribution for releases

• [ ] Set up automated builds and testing

Responsibility: Project Lead with contributor team

Timeline: 30 days from first alpha release

Approval: Self-executed, reported in quarterly update

Section 8.3: Geographic Amplification (Months 2-3)

Within 90 days of v1.0.0 release:

• [ ] Complete multilingual README translations (per NAGA P2-014)

• [ ] Establish presence on 2+ Chinese platforms (not Gitee)

• [ ] Submit to relevant Latin American platform (if applicable)

• [ ] Submit to relevant Indian platform (if applicable)

• [ ] Submit to relevant MENA platform (if applicable)

• [ ] Submit to Codeberg or other European platform

Responsibility: Project Lead with translation volunteers

Timeline: 90 days from v1.0.0 release

Approval: Program Director review

Section 8.4: Institutional Channels (Months 3-6)

Within 180 days of v1.0.0 release (if applicable):

• [ ] Complete DPG Alliance certification (if SDG-aligned)

• [ ] Submit to relevant government platforms

• [ ] Submit to relevant international organization repositories

• [ ] Engage with civic tech networks

• [ ] Apply for Mozilla MOSS or other funding (if applicable)

• [ ] Submit to developer discovery platforms (AlternativeTo, FSF Directory)

Responsibility: Project Lead and Program Director

Timeline: 180 days from v1.0.0 release

Approval: Board notification for significant institutional relationships

Section 8.5: Preservation and Long-Term Resilience (Ongoing)

Continuous maintenance:

• [ ] Quarterly verification of Software Heritage archival

• [ ] Annual Internet Archive uploads

• [ ] Maintain Zenodo DOI assignments for all releases

• [ ] Monitor IPFS pinning service health

• [ ] Evaluate blockchain archival for mature projects (v2.0+)

• [ ] Update all platform listings with new releases

• [ ] Respond to platform notifications and requirements

Responsibility: Project Lead (monthly), Secretary (quarterly audit)

Timeline: Ongoing throughout project lifecycle

ARTICLE IX: PLATFORM SELECTION DECISION MATRIX

Section 9.1: Required vs. Optional Platforms

MANDATORY (Must implement):

1. GitHub (primary repository)

2. Software Heritage (automatic archival verification)

3. GitLab (secondary mirror)

4. Digital Public Goods Alliance (if SDG-aligned)

5. Appropriate package registry (PyPI/npm/Docker Hub based on language)

6. Archive.org (backup and historical preservation)

7. Geographic platforms (2+ for Chinese regions if relevant, 1+ for other regions if localized)

STRONGLY RECOMMENDED:

1. Zenodo (DOI assignment)

2. IPFS (decentralized distribution)

3. Codeberg (European ethics-focused alternative)

4. Developer discovery platforms (AlternativeTo, FSF Directory)

OPTIONAL (Evaluate based on project needs):

1. Institutional repositories (if government/public sector application)

2. Academic repositories (if research context)

3. Blockchain archival (if long-term critical infrastructure)

4. Regional civic tech platforms (if civic tech focus)

5. Non-profit coalition platforms (if mission alignment)

Section 9.2: Platform Evaluation Criteria

When considering additional platforms beyond required set:

Evaluate based on:

1. Audience Reach: Does platform reach target user demographic?

2. License Compatibility: Explicit AGPL-3 (or project license) support?

3. Censorship Risk: Any government review or content restrictions?

4. Maintenance Burden: Time required for submission and updates?

5. Strategic Value: Credibility, visibility, or partnership opportunities?

6. Technical Integration: API or automation support for updates?

Decision Process:

1. Project Lead proposes additional platform with rationale

2. Evaluate against criteria above

3. Program Director approval for institutional platforms

4. Implement if benefits exceed maintenance burden

5. Document in project distribution matrix

Red Flags (Reject platform):

• Requires license modification or restrictions

• Mandatory government code review

• Censorship without transparent criteria

• Prohibits AGPL-3 or other copyleft licenses

• Requires exclusive hosting or distribution rights

• Violates NTARI principles or open-source values

ARTICLE X: COMPLIANCE MONITORING AND REPORTING

Section 10.1: Project-Level Responsibilities

Project Lead Responsibilities:

• Maintain current distribution matrix for project

• Execute implementation timeline (Sections 8.1-8.4)

• Verify license compliance on all platforms

• Update platform listings with new releases

• Report distribution status in quarterly project updates

• Alert Program Director to platform issues or opportunities

Documentation Requirements:

Maintain project wiki page or repository document with:

• Distribution platform matrix (platform name, URL, status, last updated)

• License verification record for each platform

• Platform-specific credentials and access (secure storage)

• Geographic reach summary

• Preservation verification dates

• Outstanding implementation items

Section 10.2: Organizational-Level Oversight

Secretary Responsibilities:

• Maintain master NTARI projects distribution database

• Conduct quarterly distribution compliance audits

• Verify Software Heritage archival for all projects

• Coordinate annual preservation verification

• Report compliance summary to Board quarterly

• Identify systemic issues or improvement opportunities

Program Director Responsibilities:

• Review and approve institutional platform submissions

• Evaluate strategic distribution opportunities

• Resolve platform access or partnership issues

• Report major distribution milestones to Board

• Coordinate multi-project distribution initiatives

Board Oversight:

• Receive quarterly distribution compliance summary

• Approve policy modifications

• Authorize new institutional partnerships

• Review annual distribution effectiveness

Section 10.3: Quarterly Reporting Requirements

All active projects shall include in quarterly updates:

1. Distribution Status Summary:

2. Number of platforms implemented vs. required

3. Geographic reach achieved (regions covered)

4. Package download/pull statistics (if available)

5. Notable platform additions or removals

6. Compliance Verification:

7. License compliance confirmed on all platforms

8. Software Heritage archival current

9. Backup archival current (Archive.org, IPFS)

10. Platform metadata accuracy verified

11. Outstanding Implementation:

12. Required platforms not yet implemented

13. Reasons for delays

14. Timeline for completion

15. Resources or assistance needed

16. Strategic Opportunities:

17. New platform opportunities identified

18. Partnership discussions underway

19. Community feedback on distribution

Template available: Projects shall use standard quarterly report template including distribution section.

Section 10.4: Annual Comprehensive Review

Conducted each October per policy review schedule:

1. Effectiveness Assessment:

2. Evaluate platform selection appropriateness

3. Assess geographic reach achievement

4. Measure preservation redundancy

5. Analyze download/usage statistics

6. Platform Landscape Changes:

7. Identify new platforms emerged

8. Assess deprecated platform migrations

9. Evaluate emerging technologies (e.g., new blockchain storage)

10. Update platform recommendations

11. Policy Refinement:

12. Propose policy updates based on experience

13. Adjust implementation timelines if needed

14. Modify platform requirements based on effectiveness

15. Incorporate community feedback

16. Resource Planning:

17. Assess distribution workload impact

18. Identify automation opportunities

19. Plan translation and localization resources

20. Budget for paid services (pinning, archival)

Output: Annual distribution policy review report with recommendations for Board approval.

ARTICLE XI: RESOURCES AND SUPPORT

Section 11.1: Documentation and Templates

NTARI shall maintain and provide:

• Platform distribution matrix template

• GitHub repository configuration checklist

• Package registry submission guides (PyPI, npm, Docker Hub)

• Multilingual README template

• DPG Alliance nomination guide and templates

• Zenodo metadata template

• IPFS distribution instructions

• Quarterly report template with distribution section

Location: NTARI organizational repository and website (http://NTARI.org )

Section 11.2: Automation Tools and Scripts

NTARI shall develop and maintain:

• GitHub to GitLab auto-sync configuration templates

• GitHub Actions workflows for package publishing

• Docker multi-architecture build scripts

• IPFS pinning automation scripts

• Distribution verification scripts

• Compliance audit automation tools

Location: NTARI tools repository on GitHub

Section 11.3: Translation and Localization Support

For multilingual distribution requirements:

• Coordinate volunteer translators for priority languages

• Maintain translation memory and terminology glossaries

• Provide translation verification process

• Support machine translation with human review for scale

• Prioritize translation resources based on strategic value

Process:

1. Project identifies translation needs

2. Secretary coordinates with volunteer translator community

3. Translators provide translations with quality review

4. Project incorporates translations into distribution materials

5. Maintain translation credits in CONTRIBUTORS file

Section 11.4: Paid Services Budget

Projects may request organizational support for:

• IPFS pinning services (Pinata, Web3.Storage) - $5-50/month

• Blockchain archival (Filecoin, Arweave) - One-time costs $10-100

• Domain names for project websites - $10-20/year

• Paid CI/CD minutes if free tier exceeded - Variable

Request Process:

1. Project Lead submits request to Program Director with justification

2. Program Director evaluates strategic value and available budget

3. Approval for amounts under $100/year, Board notification for larger

4. Secretary coordinates payment and tracks as organizational expense

ARTICLE XII: POLICY EVOLUTION AND MAINTENANCE

Section 12.1: Review Schedule

Annual Review (October):

• Comprehensive policy effectiveness assessment

• Platform landscape evaluation

• Implementation timeline assessment

• Resource requirements review

• Policy updates based on experience

Quarterly Check-ins (January, April, July, October):

• Compliance status across all projects

• Platform changes or issues

• Immediate policy clarifications needed

• Sharing best practices across projects

Ad-hoc Updates:

• Emergency updates for platform shutdowns or major changes

• License compliance issues requiring immediate attention

• Critical new platforms requiring rapid evaluation

Section 12.2: Amendment Process

Policy Amendments:

1. Proposal:

2. Any Project Lead, Program Director, or Board member may propose amendments

3. Proposal includes rationale, impact assessment, implementation timeline

4. Circulate to all Project Leads for feedback (14-day comment period)

5. Review:

6. Program Director evaluates technical merit and strategic alignment

7. Secretary assesses compliance and administrative impact

8. Compile feedback and revise proposal

9. Approval:

10. Minor amendments (clarifications, platform additions/removals): Program Director approval with Board notification

11. Major amendments (fundamental approach changes, significant new requirements): Board approval required

12. Implementation:

13. Update policy document with version tracking

14. Communicate changes to all Project Leads

15. Update related documentation and templates

16. Provide transition timeline for existing projects

Version Control:

• All policy versions maintained in Git repository

• Semantic versioning: MAJOR.MINOR.PATCH

• Changelog documenting all amendments

• Board approval documented in version history

Section 12.3: Emergency Updates

For urgent situations (platform shutdowns, critical security issues, license compliance problems):

1. Program Director may implement emergency policy updates immediately

2. Emergency rationale documented in policy update

3. Board notification within 48 hours

4. Retroactive community review within 14 days

5. Normal amendment process for permanent adoption or reversion

Section 12.4: Success Metrics and Continuous Improvement

Policy Effectiveness Measured By:

1. Coverage Metrics:

2. Percentage of projects meeting required platform implementation

3. Geographic reach across target language regions

4. Preservation redundancy achievement

5. Impact Metrics:

6. Downloads/pulls from package registries

7. Repository stars/forks across platforms

8. DPG certifications achieved

9. Institutional partnerships established

10. Compliance Metrics:

11. License compliance rate across platforms

12. Archival verification success rate

13. Quarterly reporting completion rate

14. Efficiency Metrics:

15. Time to complete required implementation (average)

16. Distribution workload burden (hours/project/month)

17. Automation adoption rate

Continuous Improvement:

• Annual metrics review with trend analysis

• Identify bottlenecks and optimization opportunities

• Share successful strategies across projects

• Invest in automation and tooling based on common needs