Dealing with Contributor Overload Holden Karau
- Developer Advocate at Google
- Apache Spark, Contributor to BEAM
Some people from big projects, some from projects hoping to get big
- Remember it’s okay to not fix it all
- The fun of a small project
- Simple communication
- Aligned incentives
- Easy to tell who knows what
- Tight community
- The fun of a parge project
- More people to do the work
- More impact and people thanking you
- Lots of ideas and experiences
- If $s then fun conferences
- Get paid to work on it.
- Is my project on Fire? or just lots of people on it.
- Measurable
- User questions spike
- issue spike
- Lesss measurable
- Non-explicit stuff not being passed on
- Measurable
- Classic Pipeline
- Users -> contributors -> committers _> PMC
- Each stage takes times
- Very leaky pipeline, perhaps it leaks too much
- With hyper-growth project can quickly go south
- Committer:user ration can’t get too far out.
- Even without hyper-growth: sadness
- Same thing happens, but slower
- Overload – Mitigation
- You don’t have to answer everyone, this can be hard
- Stackoverflow
- Are your answers easily searchable
- Knowledge base – “do you mean”
- Take time and look for patterns in questions
- Find people who like writing and get to to write a book
- Don’t to for core committers, they will have no time for anything else
- Issue overload
- Try and get rid of duplicate tickets
- Autoclose tickets – mixed results
- How to deal with a spike
- Raise the bar
- Make it easier
- Get Perl to solve the problem
- Raising the bar
- Reject trivial changes – reduces the onramp
- Add weird system – more posts on how to contribute
- What can Perl solve
- Style guide
- bot bot bots
- make it faster to merge
- Improve PR + reviewer notice
- Can increase productivity
- Add more committers
- Takes time and effort
- People can be shy
- Make a guide for new folks to follow
- Have a safe space for people to ask questions
- Reduce overhead for contributing well
- Have doc on how to contribute next to the code, not elsewhere that people have to search for.
The Open Sourcing of Infrastructure Elizabeth K. Joseph
The recent history of infrastructure
- 1998
- To make a server use Solaris or NT. But off a shelf
- Linux seen as Cheap Unix
- Lots of FUD
Got a Junior Sysadmin Job
- 2004
- Had to tell people the basics “What is free software?” , “Using Open Source Web Applications to Produce Business Results”
- Turning point LAMP stack
- Flood of changes on how customers interacted with software over last
- Reluctance to be locked-in by a vendor
- Concerns of security
- Ability to fix bugs ourselves
- Innovation stifled when software developed in isloation
Last 10 years
- Changes in how peopel interacted with software
- Downtime un-acceptable
- Reliance of scaling and automation
- Servers as Pets -> cattle
- Large focus on data
Open Source is now Ubiquitous
- Even Microsoft is using it a lot and interacting with the community
Operations tools were not as Open Sourced
- Configuration Management
- puppet modules, chef playbooks
- Open application definitions – juhu charms, DC?OS Universe Catalog
- Full disk images
- Dockerhub
The Cloud
- Cloud is the new propriatory
- EC2-only infrastructure
- Questions you should ask beforehand
- Is your service adhering to open standards or am I locked in?
- Recourse if the company goes out of business
- Does vendor have a history of communicating about downtime and security problems?
- Does vendor responds to bugs and feature requests?
- Will the vendor use data in a way I’m not comfortable with?
- Initial costs may be low, but do you have a plan to handle long term, growing costs
- Alternatives
- Openstack, Kubernetes, Docker Swarm, DC/OS with Apache Mesos
Hybrid Cloud
- Tooling can be platform agnostic
- Hard but can be done
