...
- Gap is tech lead, to help shape what happens post 6. It's nice to have software developers come in, if we're not clear what we're asking them to develop, not the best use of resources. Having someone come in to help shape the future is most needed.
- Also someone able to work with implementers, understand gaps that haven't been previously identified. And help implementers with issues - lean toward tech lead role as priority.
- If we have major technical needs down the road with more implementations, we may need intensive technical development for issues that arise. 75% tech leadership, 25% technical work
- Concern about only three committers - we need the community to be bulked up more, to avoid burnout/job changes
- How to characterize building community aspect - recruiter? People capacity, that portion of the role is important. Needs to be included in the job description.
- Want to rely on committers more for building code - role of leadership in building this.
- Balance between what you ask the community to do and what you have staffing for? Struggle to identify members in the community to contribute
- Fedora 4 was really community led - given the testing and engagement in Fedora 6 has been a positive sign of community engagement - ride on crest of Fedora 6 wave to get more people involved.
- Challenge of attracting volunteer committers? Can't justify involvement in Fedora as much because it isn't as visible to users - application layer isn't visible, it is a utility. It's hard to drum up developers even at the application layer. Saturation in the field - are we setting up the role for struggle/challenge? Will we even be able to get more committers?
- We also need to be able to train new committers - that ties into someone's role. Can't rely on committers to train new committers.
- Someone with ability to do both leadership and hands on work and judgment about when to shift between the two.
- What about a model of using contract work on a regular basis - do we need to allocate all of the position funds to a position/use it now?
Tim's Group Discussion/Perspectives on Strategic Planning
The group talked extensively about open source projects through the lens of the author Nadia Eghbal from her book: "Working in Public: The Making and Maintenance of Open Source Software"
A useful chart can be found here.
https://project-types.github.io/
The group discussed which descriptor best fits Fedora (likely "stadium") and how that influences how we might think about how to staff the project.
Additional topics of discussion largely centered on things that influence contribution to valued open source projects:
- Individual, institutional, and other motivations for open source participation. One archetype from our communities is the "popular," but not always productive, effort. For a variety of reasons an idea takes off (reach of the proponent's voice, jockeying to participate in the next thing, a compelling story, career aspirations, funding) but may not provide a good return on investment.
- The challenges of a tight labor market. Competition for developers is high. This leaves not-for-profit employers (such as academic institutions) challenged to work on their own projects. And leads to additional challenges in the capacity to provide those developers time and focus to work on open source projects when it is hard enough to resource local development efforts...to get strong software engineers.
- Reasons a developer might work on an open source project. Passion for it and capacity (some times self-generated capacity). An entrée into the profession. Because the institution has decided to contribute time to the project (developer who's not necessarily drawn to the project but is being "spent" on it as an intuitional asset).
Action Items
- Community to continue to add list of specific requirements for performance and scale for their institutions - Fedora 6.0 Performance and Scale Criteria
- Outreach to Leaders for more members to join sub-groups