Sensorica and Pearce

Paper

• Article - good study of critical elements of effectiveness in 'open' collaboration - [1]

Lessons For OSE

• Work open source. Lack of open source brand identity in the Open Value Network, and lack of open licensing in the Peer Production License - create a culture that veers away from true, open collaboration
• However, while Sensorica’s open value network is designed to sustain open, collaborative and decentralised modesof production - this does not appear to be entirely true, as open here does not mean open source in the technical sense
• For example, whilethere was an explosion of creative design solutions (due to thediverse backgrounds of participating affiliates), this also created asignificant amount of additional work to cull the core design downto a single concept. - this can be addressed by the Second Toyota Paradox, which does not appear to be included in the Sensorica methodology.
• sustaining community participation were also a challenge, as many of the initial participants dropped out of the project after the ideation phase (see Figure 6 for a graph visualising project engagement). - solution - MTPs only, please
• These two factors (above) added to the difficulty of fully documenting the finalised design. - solution - make documentation and Generative Collaboration a core of the development work, so the project gains Development Immortality
• Difficulty of accounting value and alienation for compensation - the collaborators did not have alignment of value, as in dogfooding of product. All in all, the only solution is dogfood interest and open source. Lack of dogfood interest is an implicit admission of alienation for compensation.
• MJ interpretation - lack of open source backbone among all parties is a fundamental conflict of interest.
• Commons-based peer production - and product - are a conflict of interest - because expectation of sale to a development 'partner' sets up an automatic conflict of interest in goals. One wants a product, one wants to get paid for work. That is a fundamentally wrong assumption for monetization - in that monetization should occur more downstream. But both parties need to have their own monetization/value creation methods downstream - not directly in the development process. If the value capture occurs only during the process for any party (Sensorica here), then that is a conflict of interest.
• Process vs product - since Sensorica values process and client values product, that is a conflict of interest. If the product involved is a process, then nobody should get paid.
• Good distinction - Le Dantec and Disalvo (2013) have characterised the differences between these design approaches as ‘design as infrastructuring' (or design-for-future-use), and design of a practical or useful system, or ‘design-for-use.
• Elephant in the room on lessons learned - start with clear and unambiguous open-source centrism, not an ill-defined open-whaddever follows the word open. Part of that process involves voluntary contribution with downstream monetization - as in Linux.

Suggestions from Paper

• Clarify goals - Mainly - is it product? is it process?
• Onboard collaborators properly. Give them the doctrine.
• Use a central repo.
• Value Accounting will always be unfair. Don't even try it - that would be reinventing the wheel of open source. - MJ suggestion.
• Develop an R&D mechanism.
• Measure engagement.
• Create an open call. MJ sez - by MTP - otherwise is is open but not really inclusive.