Presentation held at Open Knowledge Festival 2012. Discusses how to do open source and how NOT to do open source. Presentation has slight business focus although I'm community-driven person.
proactive community (Open and transparent communication and decisionmaking) • Adapt to changes faster (live inside open source) • Get innovative solutions and options (hacking is seen as positive) • Get quick profit (Use open source efforts only for profit) • Our internal work and teams are more creative than open source community • Sharing skills and information (outside company) is to be avoided If you prefer option 2, you can leave now and skip the following slides... 1 2
with open source values and communities ... has no history in open source development Get help! Don't jump into ocean without knowing how to swim! If your staff...
- Can be cumbersome - Can be a mesh (not clear cut) - At best combines two or more networks - Often requires organisational changes Instead try to live inside open source Company Company Community Mindset Contribute back to community
developers are not open source prone and your business is, time for HR replacements - 'turn' developers to open source in one night - give only one option in development - strict boundaries == no freedom - stick with one set op dev tools - hire open source people - educate existing developers - embrace freetime hacking - give credit for open source activities - enable dev tool selection
“9 to 5” -developer - does for the money - bind to office hours - does (internal) app development “Focused 24/7” -developer - not just for money - contributes to community - still in apps only “Spread 24/7” - developer - community as lifestyle - multiple areas (core, apps, tools) - contributes to community You need all types! + active users, hobby developers Commitment grows ->
source - 'turn' developers to open source in one night - give only one option in development - strict boundaries == no freedom - hire open source people - educate existing developers - embrace freetime hacking - give credit for open source activities - use community as dev pool - analyze (or buy) community - request 'Git' references
next quarter - Turn community efforts into cash - You shall not seek outside the box - Fixed plans and teams - Rely on internal skills - Fear of loosing control - Communities are bigger than individual companies - freedom, fun loving - Loves alternatives - make oriented - sharing (w/ altruism)
decisionmaking - Decisions in the background - Decisionmakers from company - Use only internal information flow - Only own (duplicate) bugtrackers - Code kept hidden and stall release - Dictate changes - Decisions in public - Involve all (relatively) - Use public methods - Use shared & public resources - Rely on discussion trust disbelief
policies - Neglects open communication - Fails to see values of transparency - Fails to adjust own organization - Fails to understand that communities need skillful community manager - Lives too much on it's own - In some cases ideological boundaries - Sometimes chaotic - Slow changes - Unpredictable (failure or not?) Both need to understand each other more Meet half way and discuss
staff Hire open source developers Evaluate communities constantly (outsource) Hire community manager from outside (acts as 3rd party) Engage staff to community Open up your communication and plans (regarding parts where community is involved) Company perspective Questions?
kyyberi
nextbeat
tbpgr
tokyo_metropolitan_gov_digital_hr
beglobal_document
kubell_hr
bicstone
lemonadegt
buyselltechnologies
recruiting
utosun
bcantrill
pauljervisheath
jrom
shpigford
sugarenia
csswizardry
orderedlist
jakevdp
jacobian
reverentgeek
jlugia
destraynor
