The document discusses challenges that organizations may face when adopting an open source way of working. It notes that transparency of work can be difficult due to embarrassment, increased responsibility and accountability. However, it also enables feedback and learning. It also discusses difficulties with resource availability when community work is not aligned with business or team goals. Additionally, shifting to an open and collaborative mindset from a closed one can be challenging. The document emphasizes that going open requires cultural, organizational and process changes over time through inclusion, leadership by example, and viewing community as extended team members.

1. JOHAN LINÅKER, PHD
The Open Source Way of Working

2. aka. How do you create and
collaborate with a community?
https://hbr.org/2020/01/when-community-becomes-your-competitive-advantage

3. Community <> Ecosystem

4. A Shared Mission
and Purpose
• Communicate where you want to go and ”Why are we
coming together?”
– Vision, Mission, and Goals
• Communicate how you want to get there
– Roadmap
• Foster a sense of belonging among community
members and anchor vision and roadmap with them
– Ask for input and feedback
• Listen to community’s feedback and join discussions
– React quick and friendly
• Evangelize, Advocate, Market!
– Define target audience and identify channels
– Plan and produce content
– Optimize Social Media
– Attend, arrange and present at events,
meetups, conferences, hackathons...

5. Enable easy and effective
consumption of data & SW
• Accessible APIs and code repositories
– Accessible and user-friendly landing pages
and infrastructure (Gitlab/Github)
• Up-to-date and easy-to-follow documentation
– Dedicate time, think about target audience
• Time-to-Hello-world minimized
– Let externals trial-run documentation
• Open, transparent and searchable ticket, support and
communication channels
– Synchronous (e.g., IRC) – cf. Slack!
– Asynchrounous (e.g., Discourse)
– Issue-tracker (e.g., Github, Jira, Bugzilla)
– What channels are needed for what
conversations? Don’t overcomplicate!
• Physical meeting opportunities
– Meetups, DevSummits, Hackathons

6. Enable easy and effective
contribution to data & SW
• Collaborative development = Collaboration on development
– E.g., Assign issues, tag beginner-issues, include
community in debugging processes, invite to
discussions and decision-making
• Understandable and simplified contribution process
– Common infrastructure for all projects
– Inclusive contribution guidelines for both
technical and non-technical contributions
• Possibility to report, discuss and act on issues like bug
reports and feature requests
– Issue-tracker (e.g., Github, Jira, Bugzilla)
• Discussions and conversations on backlog and community-
relevant topics done via open, transparent and generally
accepted community communication channels
– Synchronous (e.g., IRC) – cf. Slack!
– Asynchrounous (e.g., Discourse)
– Dedicated time in budget for teams
– Internal training in infrastructure

7. Intrinsic and extrinsic
incentives and rewards
• Identify and consider how to satisfy different motives
– E.g., influence, feedback, meet use-cases
• Contributions and accomplishments are highlighted
and applauded openly
– Proactive and reactive mindset in teams
• Swag can be a personal and easy sign of
appriciation
– E.g., T-shirts, hoodies, stickers
• Contributors should be given a sense of satisfaction
and recognition
– Community members as extended team
members
• Both technical and non-technical contributions
should be considered
– Active tracking of all types of
contributions

8. Carefully crafted
accountability
• Clear and easy-to-follow process for code review
and contributions
– Accessible and understandable
contribution guidelines and process
documentation
– E.g., Step-by-step process for
submitting a PR via Github, Information
on what is expected in a Pull
Request/Contribution
• Information on decision process and governance
of community
– Project documentation of governance
hierarchy (e.g., boards, committees,
working groups)
– Community charters and statuts
– Open meetings, minutes or meeting
digests

9. Healthy, diverse participation
driven by good leadership
• Exercise Leadership before Control
– Default to open (where appropriate)
– Be inclusive and active
– Lead by example and set expectations
• Code of Conduct clearly stated and how it is enforced
– Needs to be advocated and enforced
• Open and inclusive discussions in communication
– Community members as extended team
members, i.e., more than end-users
– Continuous reflection
• New users are made welcome and presented to
community resources
– Onboarding process and/or welcoming
message
– Mentor and support newcomers
– Reactive mindset among teams

10. Open, objective,
governance and evolution
• Community members feel that they have an active
part and say on the development
– Define and publish open governance
model
– Don’t overcomplicate or overgovern
– Formalize groups where community
members can have a say (e.g., working
groups, user committees) – if needed
• They are given a sense of ownership and
responsibility
– Delegation of tasks and issues
• Requires an inclusive leadership
– Mindset among teams
• Opportunities for community members to provide
feedback
– Active and inclusive discussions on
communication channels

11. Open and goal-driven
metrics and evaulations
• Have a clear and common understanding of goals
and what value means
– Talk to community members, i.e., end-
users and stakeholders
– Define goals and value per use-case
• Create chain of logic from contribution to impact
– Link operational and impact metrics
• Focus on the whole picture
– Don’t zoom in on single metrics
• Consider qualitative knowledge about community
– Use metrics as input to discussions
• Iterate and optimize
– Refine and validate metrics
• Analyze, evaluate and react
– Analyze changes and react if needed

12. Challenges with going Open

13. Transparency of Work
• Showing up one’s work openly and transparent
for knowns and unknows may imply...
– Sense of embarresment
– Sense of responsibility
– Sense of accountability
• On the other hand…
– Opportunity to get feedback and learn from
others
– Sense of pride
– Quality often becomes better
– Public and personal CV
– OSS Licence → Use at own risk
• Management and organizational support pivotal

14. Resource Availability
• Time for community work,
– Community work not seen as a
part of business goals by
managers
– Community work not seen as a
part of team goals by
developers
• Management and developers need to
set community goals aligning with
business and team goals

15. Creating an Open Mindset
●
Switching from a closed to an open
and collaborative mindset
– ”Not what I signed up for”
– ”Why should I answer that
question?”
– ”I’m busy”
●
May feel as unnessecary overhead
doing discussions online with
colleagues sitting on other side of
table
●
Striking a balance on what to do online
and offline
●
Consider community members both as
customers/end-users and collegues

16. ●
People and organizations from
outside the company are
prioritizing your work
●
Customer-driven and
collaborative development!
●
External opinions does not have
to imply the final say
●
Part of an overall requirements
engineering process
External Impact on
Priorities

17. Sum-up
• Going open requires cultural,
organizational and process change
– I.e., not done over one night
• Be inclusive and welcoming
• Exercise leadership before control
• Lead by example
• Default to open (when appropriate)
• View community members as team
members and end-users
• Design for accessability,
understandability and simplicity