OSD Fights the Tyranny of Structurless

Hey friends, it’s been a while since we’ve had this conversation, but I think it’s important and time and time again I’m seeing things happening that I wish could be run through some official process.

I’ve recently worked with a group that put together these by-laws, and I think they could work fairly well for us as well. I don’t see us really using the voting process yet, or something similar, but we probably should.

I’ve said this before but rules are important. I urge everyone to read The Tyranny of Structureless by Jo Freeman.

Our Bylaws

Google Doc with sample bylaws

A lot of this can be word-smithed, so feel free to have at it.


@jdittrich raised that it would be desirable to have solid requirements for a vote so that people can be informed before voting:

Clarification of goal. Ranked subgoals.
Pro and Con table

1 Like

Here actually 3 things, so…

Are bylaws bureaucratic?

When I look at the linked example bylaws, they seem to be very “bureaucratic” [1] or a bit laborious [2]. On the other hand, it fits what the word translates to in German. It feels like actual laws or algorithms to solve social problems. If that is correct, is it what we need?

Examples for lightweight structuring formats:

(if they are still considered bylaws, I don’t know)

  • Statement of: Mission , Values, Strategies,
    • including illustrations/scenarios to make them graspable. [3]
  • No-Goals, No-Values, No-Strategies…
    • Might help to get coherence. Also might help to inhibit intransparent power-structures [4] in open source projects (e.g. local or historical knowledge only accessible to long term members)
  • Ground Rules for communication or decision making.
    • I try to use “State this before meetings: Interest (…which I have)/Information (…I have or need)/Inferences (I make, which I need to check with others)”

An example (?)

I recently wrote some infos for contributing to my needfinding book, which might be an example for a very simple “structuredness”

[1] Which I don’t mean as a bad thing. B. gets a lot done.
[2] Which I mean as a thing we might want to avoid.
[3] …implicit Strategies (the ones never stated) are a kind of pet topic of mine… so if there is specific interest, ping me :slight_smile:
[4] Again, “power” itself is not bad, but there can easily be hidden, non-fun ways it is yielded.

These are super good thoughts Jan, and I think they get at what I’m trying to get at.

My throwing in of those by-laws was partially “food for thought”. I think there’s a lot we can strip from them and simplify them.

But like you say, I really want to avoid having non-transparent power-structures. I want OSD to empower, and not to have a “core group” that dictates things get in the way of getting stuff done. For that we need accountability and a way for anyone to say “no this is against our rules”. I think explicit is better than implicit, and would love to hear you elaborate a bit on what how you mean implicit are a pet topic ;).

I think having non goals might actually be very powerful. Would love it if someone took a stab at those? @core-group (hey, look at that ;))

1 Like

Yes – though if the rules are ones we don’t live and use in their elaborate form, it can easily happen that the rules don’t make sense (because we never actually tried them) and then somebody comes and says “it is against the rules”, then we have a strange kind of trouble.

I was reading Organizational Learning II by Argyris and Schön recently (Double Loop Leaning is a nice summary), and they had some interesting examples of how articulated and lived strategies can diverge. Also, they discuss how such differences are made not discussable by creating double binds e.g. by saying “We encourage you to be candid”, and if problems are brought up, the reaction is “sure, but that is your problem, not ours” or “Please take risks in your work, but do it responsibly”