Visit UNICEF Global
This page documents the workplan requirements for the Bridge Fund cohort of the UNICEF Venture Fund. These graduation expectations are in place for UNICEF grantees receiving follow-on funding from UNICEF. See the table of contents for navigating.
Bridging humanitarian Open Source works and communities to the wider Open Source ecosystem.
To support innovative Open Source solutions in their path to becoming Digital Public Goods.
The UNICEF Bridge Funding cohort is more than just a portfolio of software. The cohort represents cutting-edge innovations and a community of contributors from around the world, who work with each other to advance the interests of children. Unlike most Venture Capital incubators, we invite the world to participate with our projects too. A key benefit of the Work Open, Lead Open model is the accelerated feedback cycle by opening up Bridge Funding projects with the wider community. We are software engineers, designers and artists, system administrators, web designers, writers, speakers, translators, and more.
We believe that all contributors should be excellent to each other. By creating an environment for constructive contribution, we can more effectively and successfully compare and challenge different ideas to find the best solutions for advancement, while building the size, diversity, and strength of our community.
Verify graduation requirements are still satisfied since previous round:
READMEs in relevant repositories that include how developers can get started developing, prerequisites, and instructions on local configuration/set-up, and details about how the open source community can engage;
Deployment Instructions that include how and where the software is hosted;
Verification that source code is public and licensed with Free and Open Licenses;
If unit test coverage is measured, must be above 80% on average across all tested repositories.
If needed: Achieve updated Open Source standards and expectations for 2021 Venture Fund graduate companies.
Map key stakeholders and their roles. Create documentation that maps Open Source works to key stakeholders and their method of participation in the community.
Define a project charter. The project charter defines the project, a mission, a vision, and the community.
If a new community: Build a public product roadmap, highlighting the next one month of planned development.
If a new community: Establish a public chat for developers and contributors. Add links/info to project charter, READMEs, and other documentation as needed.
If participating in an upstream: Send individual or a team introduction on the upstreamβs community chat or discussion platform.
If participating in an upstream: Identify key areas of work/contribution in an upstream, and open a discussion in upstreamβs community discussion platform (e.g. mailing list, forum, issue tracker, etc.).
Submit an application to become certified as a Digital Public Good.
Open a community discussion with key stakeholders about governance models and decision-making frameworks for the Open Source works.
Identify and adopt a governance model. Implement it into day-to-day decision-making and development work.
Document governance model in project charter.
If a new community: Create a community publishing channel (e.g. a company blog or mailing list). Write one article explaining how the community arrived at the chosen governance model and why.
If participating in an upstream: Explore outreach outlets of the upstream community. Check documentation or ask a maintainer how to share new content or add to the upstreamβs existing outreach efforts.
Periodic project charter review.
Periodic Digital Public Good review.
Adapt workplan as needed to accommodate changing circumstances and community engagement.
Develop a targeted Open Source outreach plan. Evaluate potential upstreams, related communities, conferences, forums and mailing lists. Identify a subset as most relevant for your product.
Participate in an external outreach event. This means packaging your product and taking it to other relevant Open Source community conferences and events. This looks different from team to team; seek guidance from Open Source Mentor for more details.
Build community mindshare. Invite others to participate. Invite key stakeholders to be more active participants in project governance. Interview community contributors to better understand what they enjoy and what they do not.
Establish 6-18 month objectives. Integrate into public product roadmap and project charter.
Continue execution of targeted Open Source outreach plan (Q3).
Final project charter review.
Final Digital Public Good review.
Growth planning, contextual analysis, and tailored support with Open Source Mentor.
Mission and Foundation, fedoraproject.org
Mission vs. vision statements: definitions & examples, atlassian.com
Updated on 08 Aug 2024