...
- Tech lead roll is important to continue on with
- Need someone coming in after Fedora 6 to help guide roadmap
- Also recognize that there is need for heads-down development AND engage with community
- Ie bringing in new committers
- Concern about burn-out is real, and there is a need to secure this
- Personality geared toward building community
- Feel like there is saturation in the field of people who have time or have capacity to help
- Institutions don’t necessarily want to invest in persistence layer like Fedora
- Consider this opportunity to use Fedora 6 as a
- Need a combo of leadership/technical expertise
- Is there a possibility to explore options like one-time contractors for specific partners?
Group 3 (Tim’sTim)
- (Rosy) - book about open-source: What is Fedora as an Open-Source project in the context of this book? - https://project-types.github.io
- Where do we fit? And what would this mean for employment?
- If we fall in one category, how can we pivot to be in a different one that we would like to be in
- Vast majority of all open-source projects are “stadiums” - handful of contributors but a large number of users
- Institutions are struggling enough to find developers, so why would they then hand over their people to projects?
- Do we just embrace our “stadium-ness” and hire to support this need because we may never be able to overcome this set up therefore hire senior developer to just write code and develop products
- (Tim) maybe this changes the direction of Governance and their responsibilities
- Challenges of employment - competing with salaries, and the available people
- Really important to take care of the software, and those that curate it because it’s valuable and critical
- (Maurice) “membership” sounds too much like a club, and clubs are not as big a sell anymore
- There needs to be tech underneath the sales piece
...
- 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