Building open source communities

12 participants: Introductions and questions

Question: Appeal of open source is that it is community lead. How do you deal with consensus? Governance - Depends on the audience - at what level are you trying to reach it - Also there are different levels so need to figure out what the level is - Depends on the output of the product - Backdrop CMS for everyone most stuff is self determined by the community --- set of principles to guide community / processes - getting people to agree on how to make decision before the merits - policies skipped over coming up with the process first; now going back and stepping back - also thinking about who's going to make the decision - technical architect commitment comes up with principles but anyone can contribute

Question: how do you attract group developers/contributors and keep them engaged? Or also how to separate them? - keeping ppl out of community when the license does not allow that; solution could be a code of conduct - if you are a member of x then you are not welcome in community will not accept etc. license will not prevent you but we won't assist (lerna) - Affero GNU Public License AGPL not required if used software in website same as distribution need to contribute code back; peer production license (P2Pfoundation.org) - Free/open source software licenses excludes political objectives; GPL required to publish any chance you make and creates ecosystem if business processes are not designed for that then kind of academic. Peer and free open source - Code of conduct helps to keep a community so there are guides; interested in other parts that can be added to make a code of conduct stronger

Question: Code of conduct - how do you make the contributions more diverse to draw in others to be inclusive? - Started as a community and code of conduct as the first thing; interview applicants and bring them into the community - Spend time to mentor to provide resources to those who may not be at the same level of contribution so they can pick up whats necessary to contribute - Spend time teaching others specific skillsets; - Implemented code of conduct after and difficult - Stack overflow blogs helpful in building a code of conduct on how specific it needs to be - OSM international org are there effective ways to empower all - Paid staff on the project; part of job is to mentor. Paid vs. volunteer always have different levels of accountabilities and requirements - If volunteers feel like they have the support, space, and time they will continue (on-boarding is the toughest) Getting that first feedback loop and making time go forward - Paid staff - ways CivCRM; shops who use to contribute financially. Do not necessary need to come from the org but can come from those who use

Free software movement: - Existing open source - define rights for certain groups of ppl right to use or right to fork? Very few address the right to be paid for work / time - who gets paid, who's staff and who's volunteers? Peer production license defines who will get rights to their work - Not everyone can afford to do that; scratching humanities itches!

Question: Starting a new or young project to build momentum and documentation. Any pro tips? - Design in a way to make it easy to only publish what is the "need to know" allows ppl to get involved in a relatively different way - User that wants to launch and launch it on a specific day and have a different team fix - Fork happens in community (example Drupal) people issue is most upsetting; technical different vs. name difference; consensus is tough - Can also be a negotiation tactic (open wrt ppl saw what they were doing and merged with LEDE principles) - Purely technical fork then code differences will be hard to find consensus - Consensus - squishy word. Consensus is not unanimity; "eh I don't hate it" at some point need to make decision. - Most communities not strict on consensus unless it's a BIG decision like a code of conduct! - Number of decision makers makes it more difficult - Decision makers and participation rate can be different and vary - Hard to get people to switch mindset - cons might look scary mitigations help make it better; also ends in a positive light - Holacracy - working group working on subject area and group meetings to decide on big things - teams setting own goals and share with whole group and rules about when things need to go to everyone 7 +- 2 is the number on when teams begin to become potentially less cooperative Dunbar's number (150 and as high as 350 at some corps) social science manageable data science numbers

Question: How do open projects grow? Is there a line between the types of open source projects between the big projects and the ones that are smaller? Add without doing a lot - high barrier to entry and hard to deploy. - There is a leadership issue need to have a scope requirement - feature request management - There are principles and if they don't pass then community will decide if it's in or out. Containing itself growth is limited on purpose bc of the principles. Self limiting project for the good of the project to stick to values - Different for library vs. application too - Library potentially easier to maintain the scope. BUT not necessary.