OER's Built-In Continuous Improvement

This week’s readings (here, here, and here) focused on the cycle of continuous improvement that is naturally built into OER use. One key tool used for continuous improvement of OER is the RISE tool. RISE stands for Resource Inspection, Selection, and Enhancement.

One of the most interesting things I read this week came from outside the educational realm, but it used the same idea of continuous improvement, beginning with a minimal viable product to eventually produce a key piece of email technology by programmer Eric Raymond. Raymond followed the Linux model of sharing his minimal viable product with a large group willing users who, after using the product, gave quick and helpful feedback that enabled Raymond to continually improve his product. They inadvertently became a team of co-creators that turned out a better product with less bugs in record time.

Also this week, quite unconnected from my studies, I listed to a podcast with Brene Brown interviewing sports psychologist Pippa Grange. The topic was performance and how it is enhanced with vulnerability and openness rather than ego, shame, and fear.

It struck me that Raymond’s continuous improvement embodies the same principles Pippa Grange credited with improving performance. To demonstrate this, below I have listed a few of my favorite of Raymond’s takeaways with Grange’s principles in italics following:

* Every good work of software starts by scratching a developer's personal itch. Sharing your personal ideas and thoughts is openness and vulnerability in action.

*Good programmers know what to write. Great ones know what to rewrite (and reuse). Ego and fear are set aside when we reuse other’s ideas.

* If you have the right attitude, interesting problems will find you . Staying open and curious to ideas instead of fearing and armoring up our ego helps everyone grow.

*When you lose interest in a program, your last duty to it is to hand it off to a competent successor. Letting go of ego and fear of losing power or control continues the cycle of learning and growing.

* Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. Staying curious as a learner rather than the expert is key in performing well. Fear, shame, ego and imposter syndrome creep in as an “expert”.

I am still chewing on Raymond's and Grange's words of wisdom, and relishing and resonating the joy, openness, and ease of sitting in curious learning mode rather than expert mode. The one question I am left with is:

How do we create an environment where sharing, vulnerability, openness, and curiosity remain and ego, shame, fear, power control, and armoring up are removed?