History of the Open Food Federation

What follows is the original proposal for the OF Federation. While this is no longer binding, it provides a historical perspective on the reasoning and motivation behind it.


Following is a proposal to users of the Open Food Source and Local Food Co-op Software.


To ensure a framework for collaboration between users of Open Food Source software in order to empower participating organizations and provide for a long-term continuity of support.

Co-op principles:

Seven cooperative principles, taken from the National Cooperative Business Association:

  1. Voluntary and Open Membership
  2. Democratic Member Control
  3. Member Economic Participation
  4. Autonomy and Independence
  5. Education, Training and Information
  6. Co-operation among Co-operatives
  7. Concern for Community

Specific objectives:

  • Transfer oversight of software to participating organizations, irrespective of size (co-op principles 1, 2, 6).
  • Provide developers with autonomy to properly manage technical issues (co-op principles 1, 4, 5).
  • Maintain the software as open-source and freely available to anyone (co-op principles 4, 5, 7).
  • Generate sufficient revenue for ongoing OFS software development (co-op principles 2, 3, 6).
  • Provide limited support to non-participating organizations (co-op principles 4, 7).
  • Provide services to member organizations (co-op principles 1, 4, 5, 6).
  • Foster cooperation between participating organizations (co-op principles 2, 3, 5, 6).

Each of the objectives above is explained in more detail here:

Transfer oversight of software to the participating organizations, irrespective of size.

Until now, development has been managed by weighing the requests of many organizations and prioritizing work to be done. This transition to oversight by participating organizations can be accomplished in at least two ways.

One way is the formation of a committee of the participating organizations. In order to meet that objective, each participating organization would provide a liaison to the OF Federation. This group would act much as a board, discussing and weighing issues, and deciding where to apply resources. That “board” would be enjoined by developers interested in doing work, but in an advisory-only role.

A slightly different solution would be to allow each participating organization to “vote with their funds” for the tasks they would like to see accomplished. Here, again, it would be important to have one or more developers providing advice on the ramifications of requested solutions.

NOTE (reason for inclusion of developers in the process): While it may be possible to implement some arbitrary new feature, it is sometimes important not to do so because of the implications it will have on the overall system. This is often a source of tension between developers and customers, but it is an important role of the developer, sometimes, to say, “No.”

In addition to advising participating member organizations, any active developers will also coordinate with one another to seek the best possible solutions. This might be formalized as a developers board, or it might be done less formally in electronic discussions.

Provide developers with autonomy to properly manage technical issues.

Behind the scenes of the software are numerous little considerations that have no effect upon the obvious function. Developers need the ability to apply resources to ensure the overall integrity of the software, whether there is an evident result or not.

Examples of this sort of activity include:

  • Packaging the software for new releases
  • Preparing technical documentation
  • Rewriting inefficient routines
  • Formatting and commenting code
  • Refactoring the code as needed
  • Managing backups and demonstration data
  • Maintaining the software website

Maintain the software as open-source and freely-available to anyone.

There is a distinction between open-source software (OSS) and “free” software. In fact, it is okay to charge money for open-source software. However, in this case, we will commit to maintaining the software as both open-source and free so that it can be used by all who need it.

Generate sufficient revenue for on-going OFS software development.

The Open Food Source software is responsible for moving over a million dollars of food each year and deserves a commensurate level of professionalism. If food cooperatives expect to be taken seriously, they should not be treated as a hobby. Since most food cooperatives are not large enough to support in-house IT staff, it makes sense that they join together in a joint venture to meet those needs.

Provide limited support to non-member organizations.

As any new organization is reviewing the choices of software to serve their purpose, they will need to have questions answered. It is advantageous to provide a level of support to those new organizations. The scope of that support will need to be established.

Provide services to member organizations.

Beyond advances to the software itself, there are a number of benefits that can be obtained when member organizations work together. In some cases, these are things beyond the scope of what a local IT volunteer would be able to implement.

Examples of additional services that can be provided:

  • Shared or discounted web hosting
  • Managed updates and releases
  • Routine backups and restoration (when needed)
  • Catastrophic crash-recovery plan

Foster cooperation between participating organizations.

Among many other things, most of the participating organizations are cooperatives. Much joint benefit can arise from those cooperative values.

Examples of shared resources that can be coordinated:

  • Newsletter article sharing
  • Member transfer agreements or reciprocal memberships
  • Sharing of best-practices
  • Sharing of documentation
  • Sharing of news items related to local food
  • Advertising

Additional details:

The OF Federation will operate as an informal agreement between participants and will not be incorporated. It will serve to structure the relationships between participating organizations and software developers.

In addition to doing development work on the Open Food Source software, developers will maintain the infrastructure that runs the OF Federation itself, including membership management, accounting records, email lists, bulletin boards, wiki, and/or whatever other components are deemed desirable to meet the organization’s needs.

Participating organizations will provide a designated liaison to represent their interests and oversee the software development. They may provide any number of developers, if desired.

Financial considerations:

As a non-incorporated entity, the OF Federation will not possess a treasury. Instead, funds will be retained by participating organizations and managed as agreed “promise to pay” terms. Developers will work at the pleasure of participating organizations and will be paid directly by those organizations, according to agreed-upon terms.

Initially, participating organizations will be asked to set aside 2% of their gross revenue from sales to pay for on-going software development and general Open Food Source support. These funds will be utilized, as authorized, by developers to cover labor and expenses related to their support roles. As funds are used, the participating organizations will be billed directly by developers to cover costs.

One quarter of funds will be earmarked for the discretionary activities of developers to ensure continued function of the Federation as a whole.

NOTE: For tax purposes, it may be preferable to have the participating organizations make non- labor payments directly to a particular payee, rather than passing them through developers’ hands, but the accounting will be handled the same.

Rather than sending funds directly to the OF Federation, each participant would effectively make an IOU to the OF Federation as a promise to cover costs incurred, up to that amount.


Each participating organization would help build a “wish list” of developments for the Open Food Source software. As mentioned earlier, there are at least two ways to handle governance.

1) Allow the “board” of liaisons to vote and allocate certain development funds to particular projects, as they see fit. Then one or more developers would be authorized to do the work. When the work was done, the developers would be paid by the participating organizations directly. This structure would give each participant organization an equal vote.

2) Allow each organization to apply their IOU funds, in total or part, toward the projects they would like to see accomplished. They might prefer to allocate all of their funds to a particular project that is important to them, or they might choose to combine their funds with another organization to realize a quicker result on another project. Any authorized developers could begin work as soon as they felt the allocation to a particular project was sufficient to fund the required task. This would also allow any organization to fund a “pet project” with their own developer while still getting “credit” for participating fully in the OF Federation.

Remuneration for developers:

Developers will be required to participate and cooperate with their peers with regard to approved activities, best practices, and methods. Within that scope, they will be at liberty to work on any approved projects.

It might be desirable to set specific pay-per-hour rates for developers, or it might be better to let them participate when the value of a particular projects seems “worth it” to them – in a more market-oriented approach.

Setting accepted pay-per-hour rates for developers places all developers on an equal footing. It also allows for marketplace incentives to the participating organizations. For example, if development is set at $40/hour and support is set at $60/hour, there will be a strong incentive for participating organizations to fund development to address problems that most often plague them.

Either way, a reasonable – but low – pay-per-hour rate needs to be set for the developer’s autonomous activity, which will be drawn from participating organizations – regardless of approval. These funds will cover the necessary overhead tasks of website upkeep, Open Food Source management, releases, and so forth. The low rate of pay for these services is established in order to limit squandering.

A specific proposal:

As a starting point, the following is a specific proposal for the OF Federation.

Benefits and obligations for participating organizations:

  • Any organization using the Open Food Source software may join the Federation and participate while in good standing.
  • Member organizations will set aside 2% of their gross sales revenue for support of the OF Federation. Of that amount, 75% can be allocated to preferred projects and 25% will be earmarked for discretionary use by developers.
  • Member organizations have control over which developers they would like to contract with to do particular work.
  • Member organizations will make payments directly to developers or other entities as services are rendered.
  • Member organizations are not obligated to make payments until projects are complete or milestones are met (for larger projects).

Benefits and obligations for developers of Open Food Source software:

  • Developers will create and maintain facilities on the OF Federation website to provide for services necessary to accomplish member organization oversight needs such as tracking of obligations, prioritization of projects, approving developers, downloading software updates, etc.
  • Development of Federation services, not related to oversight, will be handled as software development projects. For example, the development of a forum to exchange agricultural data among member organizations.
  • Developers are accountable to work with other established developers for oversight and guidance and to conform to practices established by the body of developers.
  • Developers who are working on discretionary projects will earn no more than $15/hour.
  • Developers will maintain a non-public contact profile on the OFS website so they may be contacted by member organizations.

General practices:

  • Projects may be designated as contract with a specific earned payment, or they may be designated with an associated pay-per-hour rate.

Leave a Reply