Open Tuition Payments
changing payment to change hierarchy
I recently spent the day co-working and chatting with @whit537 about his hopes for Gittip and my hopes for the Saxifrage School. We imagined what it would look like for a school like ours to begin funding some of its work via Gittip. We discussed what the open company model would look like for a school. There’s a lot of tricky ramifications that need to be sussed out. Let the sussing begin.
In the Fall of 2014 we are beginning our first year-long program, Dev.Year. After a lot of iterating we have decided that the ultimate goal is to help incoming learners “yearn for the sea”. If we are going to equip them to be self-driven learners, we have to move away from a teacher-run program full of didactic content and courses. One of our advisors wisely noted that he disliked all of his Computer Science courses in college. The only valuable thing about the program was the time spent working side-by-side with other programmers in the dingy computer labs. The best part of his school was a poorly-resourced accidental community where people were building stuff. Our plan is to create an intentional, well-resourced community.
So, in building Dev.Year, what would it look like to run it as an “open company”, as an open school? One of the three tenets of open companies is that its employees are not compensated by the company and, therefore, anyone can be employed to any degree they wish. This is perfect for our community-first model. We plan to put out an open invite to the local web developer community, asking them to consider joining our school community: help us encourage and equip the next generation of developers to build the open web.
The community then, will have both old and new members, developers and beginners. We hope to have 100 developers commit to being part of this community in some way, large or small. In a way, inversely, it is also us asking them to let us join their community. Developers could join us for one meal to give a brief talk about their work, joining us for a series of day-long co-working sessions, or mentoring a team of new members. The commitment could range from 1 hour to 100 hours.
In order to thank and compensate developers for their time working and learning alongside us, we have set aside about $40,000 to distribute to them. Gittip makes perfect sense for this. Developers can easily join a Team on Gittip and have money divvied up amongst them depending on their contributions to the community. If someone is interested in working more with beginners, they can go for it and their contributions will increase as a result. The most open way to go about this would be for students to contribute directly via Gittip, not through the Saxifrage School. To do this, they would have to commit to contributing $125/week for the duration of the program.
Setting up this direct transaction between the teacher and the student is a powerful act. In today’s colleges, students rarely have any clue where their money is going. The transparency of this open school platform places a serious responsibility on the relationship between both parties. One question I do raise is whether experienced community members (teachers) would be compensated more accurately if there was accountability on both sides.
Right now, Team members define their own self-worth and social control + guilt + “first-in, last-out” logic controls the contributions. What if Team members and Team supporters could vote on how much Team members ought to receive. This way learners could nominate members of the developer community who had served them best, just as developers could claim the percentage they deem appropriate.
This alteration seems to work within a face-to-face community in which the supporters are part of the community and know the developers personally. It may not, however, work in a setting in which the community is being supported at large by people far and wide who don’t know them individually. To allow for this, each Team could have the option to turn this setting on/off. If it is on, a distant supporter who has no knowledge of the Team’s specifics, could opt-out of the ability to choose. It seems like there has been some work done on this front by a fellow named Bayle Shanks. Maybe he could assist Gittip in implementing the algorithms needed to make this function work.
Not only does this contribution model drastically improve the transparency of costs, it also changes the power dynamics within the community. Instead of “teachers” and “students” we have old and new community members. Even new members, if they share skills with their fellow learners, could be part of the Dev.Year Team that is supported on Gittip.
The one place where we got really stuck was whether or not to include administrative staff in the Gittip compensation concept for Dev.Year. It seems obvious that “hard costs” i.e. rental space, supplies, insurance, etc. (about $1000 upfront per new member) should not be included, but what about the four staff? One of them will be exclusively devoted to the Dev.Year program, the other three to varying degrees.
It feels safe to “hire” the developer community via Gittip, because we’re not relying on any single one of them to make the program run and they won’t be relying on our salary for their primary income. They’re not going to plan their lives around us. We will, however, rely on hiring one key facilitator for the year. This person will start 3 months in advance of the program and will be the glue that holds everything together. It seems really difficult to “hire” this person via Gittip, if only because we would need to pay them months before our cohort arrived to support them.
Another advisor wisely noted that when innovating, it makes good sense not to try and innovate in every area at once. For this reason, it may be best to run compensation for the developer community via Gittip, and leave compensation for administrators to run in traditional ways. We could take up the issue again in subsequent years, once the Gittip team is more established. Perhaps we can think of this one staff facilitator as the traditionally hired person who kick-starts the open school community. Possibly, we could hire them traditionally and leave it up to them if they wanted to move to being supported by the Gittip “Dev.Year” team instead.
Interestingly, it might be more feasible to include our other 3 administrators in the Gittip “Dev.Year” team because their salaries rely on it only slightly, due to it being only a small percentage of their work. Myself, for instance, as the main Saxifrage School staff, expect to spend just about 25% of my time on Dev.Year while it’s running, our Community Partnerships staff as little as 5%. It may be feasible to expect that portion of our incomes to come from Gittip and then ask less from our organizational salaries.
Of course there are additional technical issues when concerning moving staff into the Gittip system: taxes, withholding, and unemployment.
What am I missing? It’s a crazy idea all around, but one that has really exciting ramifications.
