How it works
In a stylized transaction flow, a Project leader puts up the road map or Fundable features for their project. The general contractor (OpenPartner) get the Fundable features road map and gets in touch with the organization (Funder). The requesting organization (Funder) allocates funds to a fundable feature. These funds are stored on the OpenTeams platform, which acts as an escrow to incentivize parties to act in good faith. OpenTeams will eventually distribute the funds after a set of predetermined conditions is met. Once the open source issue is funded, the OpenPartner will hire the team (Contributor) to work on the project. The OpenPartner solves the issue and claims the compensation. OpenTeams then settles the transaction.
Most people in the open source community are often willing to listen and help when you talk to them about supporting an open source project, especially the one they rely on. However, they almost always want to know in details exactly what will be done with the funds. This is true not only for companies but also for contributors. In addition, companies will likely want a written agreement and some form of reporting about the progress of the work. To meet this need OpenTeams came up with a concept of Fundable Features - agreements that outline what work will be done on a project (implementing new features, release management, improving documentation, etc.) and outlining a reporting mechanism. What makes a Fundable Features different from a consulting contract? Key differences are:
- It is work done on the open source project itself and not customization for the client.
- The developers have a reasonable amount of freedom to decide what to work on and what the technical approach will be, within the broad scope of the agreement.
- Deliverables cannot be guaranteed to end up in a project; instead, the funder gets the promise of the best effort of implementation and working with the community.
The third point above is particularly important because we respect how open source projects make decisions. When the project leaders decide that they don't want to include a particular change or new feature, that's their decision to make. Any code change proposed as part of work on a Fundable Features has to go through the same review process as any other change and be accepted on its merits. The argument "but someone paid for this" isn't particularly strong, nor is one that reviewers should have to care about. Now, of course, we don't expect it to be common for work to be rejected. An important part of the OpenTeams value proposition is that because we understand how open source works and our community members are leaders and contributors of open source projects already, we propose work that the community already has interest in and we open the discussion about any major code change early to avoid issues.
The principle is simple here. We are considerate to what the community wants and operate transparently so if we make honest mistakes we get feedback and can take corrective action quickly.
A project can also have
- Fundable Features with status (requested or approved)
- Associated proposal fragments with status (requested or approved)
To contribute to the funding of a project, please contact us for more information.Contact Us
SciPy is open-source software for mathematics, science, and engineering. It includes modules for statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, ODE solvers, and more.
SymPy is a Python library for symbolic mathematics. It aims to become a full-featured computer algebra system (CAS) while keeping the code as simple as possible in order to be comprehensible and easily extensible. SymPy is written entirely in Python.