Last updated by paddypatpat on Fri, 2014-01-17 19:45
The Plan
The purpose of this document is to describe the requirements for an open community of web developers, themers, designers, accountants, server admins, marketers and customer-sales'n'support-friendly-angels to work with, not for, customers of a website.
(Crap, does this count as a "recruitment job posting"??)
This is not a discussion of all the theory and research behind how this works. There is plenty but writing it up is taking a while. Instead, where there are questions, justification will be forthcoming. In most cases much of the deal should be common sense.
The differences from normal company methods
The overall setup is similar to some of the principles of other cooperatives, but there are a few differences, mainly to take into account the varying workload between open-source contributors.
- It takes a team to make most drupal projects work. Teams have to be able to work together. They also need to have a clear agreement on what they're trying to achieve.
- Rather than treating 'employees' like children, removing much of their ability to make decisions, while they buy houses and change governments away from work, treat each other as adults.
- Most companies are like buses, to be owned and driven by the driver, leaving everyone else to sit and follow. Rather, treat companies as children, something to be nurtured and grown, but not owned.
- You are paid based on the impact of your contribution. Where your contribution is part of a group effort, the group will split the reimbursement based on range voting. It's been used by bees for millions of years so it must be good :).
The result is that you build a library of efforts, each of which pay you back over time. Don't work on things you don't believe will be worth your while. Assuming that it works (it's a good assumption) it could be good for other things too (hmmm module maintainers et al). - Customers are volunteers. They volunteer their money. They contribute "customer service" for others. If you serve them well, they also become your salespeople. They may find bugs or suggest features. They're not that different from a part time employees. Customers and full-timers are all part of the same continuum. Each have just chosen a different level of involvement and different areas of contribution.
The Purpose
All groups exist to solve a problem, and while there can be many projects, the first is to create an alternative to Gmail. Yup, I'm serious.
The Problem
Even if despite Google's amazing ability to close down good projects isn't a concern (hello Google Reader), Google has managed to cultivate a pretty shoddy reputation for being trust-worthy with people's data. Add to this Edward Snowdon's NSA revelations. While citizens of the United States still have legal rights, citizens of any other country with their data in the U.S. have no legal protection at all.
With this in mind, take an example.
Which internet browser would you pick if you were worried about not supplying or even just supporting this current setup:
- Internet Explorer
- Chrome
- Safari
- Firefox
- Opera
The difference between Firefox and the others is that it is built by an open company. Anyone can see what is going on within the company and its code. This makes it pretty hard for some manager somewhere to decide to help boost the bottom line at the expense of their customers. In other words, they're trust-worthy because their work can be checked.
The Vision
The vision is to do the same for providing an email service.
An open-source community of people of a wide variety of professions and interests, contributing their efforts to creating a trust-worthy email service. The outcome is a service created for everyone involved. The greater scope is to prove a model for funding open-source community problem solving.
Constraints
Constraints on a project are a property of the people involved. Thus, they change depending on who is contributing to the group.
Some principles can help define some basic constraints though.
Bootstrap, rather than finding investment funds.
Rather than grabbing investment money, the work should be done off our own backs. Really, there isn't a great deal of investment in resources required to start the project. When we do see a need for money, then there's no point doing it if we can't sell the service to enough people to cover the costs and time of creation to others anyway. This is where crowd-funding would be an option.
Treat the company as a kid
This means that no-one can own it. A group's work should not require a benevolent dictator (e.g. Wikipedia's Jimmy Wales) that must be relied on for the work to be safe. Rather there are other legal methods. One option (the best I've found so far) is to tie up the cooperative using a trust. Trust law (NZ Trust law anyway... and thus probably Australia and the U.K. too.) requires that decisions are made by trustees that are in the interests of the beneficiaries. The trustee can be any legal entity which in our case would be the cooperative. The beneficiaries would be any one signed up with the service. This means that unlike companies where the goal of the company becomes to make money for owners, here the trust and it's cooperative must be run so that the decisions are made in the interests of the creators and customers of the email service.
You raise a kid; you don't own them.
Open Accounting
While people love to make accounting difficult, an organisation needs enough money coming in to cover the money going out. The more people understand about how their organisation's money is being used, the better both their arguments and decisions can be on what is to be done.
Goals
First goal is to decide what we each need to agree on in order to be able to start work on this. This means fleshing this document out. The requirement is to get to the point where combined we have said to each other "You can do anything you want as long as...". This is the basis from which we can work together. It requires less writing than you'd imagine.
The second goal is to have laid out our options for piecing this service together. Email services are based on a series of different open-source projects. For this, Drupal will be just one. Others include Postfix, Dovecot, EncFS, opendkim, spamd, z-push....
Strategy
A strategy is a description of what you wont do, not what you will. Strategies exist to allow you to pick between new opportunities as they arise. You never know what the world will bring, but a strategy that describes what you wont do means that you can filter through these opportunities and not have to change the strategy in order to choose which ones to do.
This doesn't mean we can't change the strategy whenever we want, but it will require discussion and agreement.
Conclusion
That's a start.
Done well, a large array of skills and professions could start something special so if you know of someone outside of the Drupal community, share the URL with them.