Skip to content

Latest commit

 

History

History
99 lines (82 loc) · 8.73 KB

notes-2019-10-11.md

File metadata and controls

99 lines (82 loc) · 8.73 KB
Raw

Plain text for posting during interviews

Infrastructure vs non-infrastructure software

JACKIE: As a user of other packages, I never really looked at sustainability because I always looked at it as, well, if this doesn't continue or this somehow fails, I can fork it. In the worst case, I can fork it and fix the things that I need to fix to make it work.

FOSS vs non-FOSS infrastruture

  1. Infrastructure is “magical plumbing.” FOSS infrastructure lets you look behind the curtain if you so choose; non-FOSS infrastructure likely does not.
  2. Infrastructure requires technical effort for operations (as well as development). FOSS infrastructure may begin as a pet project and then “accidentally” go into production; non-FOSS infrastructure is more likely to be deliberately planned as a product launch.
  3. Infrastructure requires development capacity (people-time). FOSS infrastructure is likely to have some or all of this development capacity come from self-directed volunteers, but that effort is also more likely to fade out during the “last mile.” Non-FOSS infrastructure is more likely to have its development resources known, managed, and allocated in advance.
  4. Infrastructure requires bureaucratic/organizational work. FOSS infrastructure is likely to have this set up late, during the “last mile” or the “sticking point.” Non-FOSS infrastructure is more likely to have this infrastructure (legal, organizational, financial, managerial, marketing, etc.) be set up early.
  5. Infrastructure user data and usage patterns are important for determining future resource needs. FOSS infrastructure maintainers are less likely than non-FOSS infrastructure ones to have complete and reliable access to that data because of intentional cultural choices to prioritize user freedom and access over it.

Aggregated definitions of "well-maintained"

  1. There are people there to triage and address issues that come up in a timely manner.
  2. There are people to make sure a project is keeping up with changes in the ecosystem (ex: maintaining compatibility when dependencies are updated, etc.)
  3. The project is following best practices regarding software development (tools, code style, tests, etc.)
  4. The project cares about backwards compatibility.
  5. The review process is clear. New changes can be evaluated effectively and merged if appropriate, and standards/expectations are clear to contributors.
  6. The review process is pleasant; maintainers are friendly when contacted.
  7. The project values inclusion and is visibly trying to be welcoming to a wide variety of contributors.
  8. The project is regularly updated and has activity happening, AND this activity is fully and easily visible to outsiders.

Aggregated definitions of "sustainability"

  1. There are resources (donated services or money to pay directly) for ongoing operating costs, including computing resources, people for operations, people for development, and people for “management.”
  2. Will the resources needed for the project continue to be provided in the future?
  3. The “bus factor” is high.
  4. Sustainability relies on maintainability; what is the overhead to the project continuing to exist in the world?
  5. Continued improvement of maintainabilty; keeping a project “up to date”
  6. Computing resources, either donated or via the fiscal means to afford them
  7. Interest in its existence from users (“existence sustainability”)
  8. Sustainability is a sort of artifact of people and an extension of their time; do people have enough time to dedicate to this, or are they spread too thin?
  9. There are new people onboarding.
  10. There are clear entry points for new contributors so they know how to get started.
  11. Maintainers are not burning out in silence or unexpectedly decreasing their contributions for some other reason (moving, new child, new job, health, etc.)
  12. Contributions are not bottlenecked at one person, a single point of failure, with no clear pathway to engage the community otherwise.
  13. Various people taking on roles, not just one person.
  14. Sustainability is hard to define with numerical metrics; you can try to count how many PRs there are, or average time for an issue to get fixed, but there are always more complicated reasons than that.

With github markdown for transcripts

Infrastructure vs non-infrastructure software

Source(s): Jackie-1

JACKIE: As a user of other packages, I never really looked at sustainability because I always looked at it as, well, if this doesn't continue or this somehow fails, I can fork it. In the worst case, I can fork it and fix the things that I need to fix to make it work.

FOSS vs non-FOSS infrastruture

Source(s): notes-11-10-2019.md

  1. Infrastructure is “magical plumbing.” FOSS infrastructure lets you look behind the curtain if you so choose; non-FOSS infrastructure likely does not. Source(s): notes-11-10-2019.md

  2. Infrastructure requires technical effort for operations (as well as development). FOSS infrastructure may begin as a pet project and then “accidentally” go into production; non-FOSS infrastructure is more likely to be deliberately planned as a product launch. Source(s): notes-11-10-2019.md

  3. Infrastructure requires development capacity (people-time). FOSS infrastructure is likely to have some or all of this development capacity come from self-directed volunteers, but that effort is also more likely to fade out during the “last mile.” Non-FOSS infrastructure is more likely to have its development resources known, managed, and allocated in advance. Source(s): notes-11-10-2019.md

  4. Infrastructure requires bureaucratic/organizational work. FOSS infrastructure is likely to have this set up late, during the “last mile” or the “sticking point.” Non-FOSS infrastructure is more likely to have this infrastructure (legal, organizational, financial, managerial, marketing, etc.) be set up early. Source(s): notes-11-10-2019.md

  5. Infrastructure user data and usage patterns are important for determining future resource needs. FOSS infrastructure maintainers are less likely than non-FOSS infrastructure ones to have complete and reliable access to that data because of intentional cultural choices to prioritize user freedom and access over it.

Aggregated definitions of "well-maintained"

Source(s): notes-11-10-2019.md

  1. There are people there to triage and address issues that come up in a timely manner.
  2. There are people to make sure a project is keeping up with changes in the ecosystem (ex: maintaining compatibility when dependencies are updated, etc.)
  3. The project is following best practices regarding software development (tools, code style, tests, etc.)
  4. The project cares about backwards compatibility.
  5. The review process is clear. New changes can be evaluated effectively and merged if appropriate, and standards/expectations are clear to contributors.
  6. The review process is pleasant; maintainers are friendly when contacted.
  7. The project values inclusion and is visibly trying to be welcoming to a wide variety of contributors.
  8. The project is regularly updated and has activity happening, AND this activity is fully and easily visible to outsiders.

Aggregated definitions of "sustainability"

Source(s): notes-11-10-2019.md

  1. There are resources (donated services or money to pay directly) for ongoing operating costs, including computing resources, people for operations, people for development, and people for “management.”
  2. Will the resources needed for the project continue to be provided in the future?
  3. The “bus factor” is high.
  4. Sustainability relies on maintainability; what is the overhead to the project continuing to exist in the world?
  5. Continued improvement of maintainabilty; keeping a project “up to date”
  6. Computing resources, either donated or via the fiscal means to afford them
  7. Interest in its existence from users (“existence sustainability”)
  8. Sustainability is a sort of artifact of people and an extension of their time; do people have enough time to dedicate to this, or are they spread too thin?
  9. There are new people onboarding.
  10. There are clear entry points for new contributors so they know how to get started.
  11. Maintainers are not burning out in silence or unexpectedly decreasing their contributions for some other reason (moving, new child, new job, health, etc.)
  12. Contributions are not bottlenecked at one person, a single point of failure, with no clear pathway to engage the community otherwise.
  13. Various people taking on roles, not just one person.
  14. Sustainability is hard to define with numerical metrics; you can try to count how many PRs there are, or average time for an issue to get fixed, but there are always more complicated reasons than that.