OpenRover: A Security Report Before the 3.0 Release
OpenRover is a volunteer geospatial library with 2,400 stars, five maintainers, and a six-month release cadence. Three maintainers work full time elsewhere; one has been inactive for 11 months. In the week before the 3.0 release, a security researcher privately reports a path-traversal bug in the tile server that is reachable in the default configuration. A fix is ready but changes a configuration default and breaks two plugins. A large downstream user, a mapping company, says it will ship 3.0 the day it is tagged. Meanwhile, a two-year-old issue requesting a plugin API redesign has 180 thumbs-up and a contributor who has already written 4,000 lines. The project uses a mailing list for decisions, a code host's issue tracker for work, and IRC for chat; the 3.0 milestone has 41 open issues. The maintainers meet once a month and have no formal voting rule.
1. How should the maintainers sequence the security fix, the breaking default, and the 3.0 release?
Read the worked answer
The security bug outranks the release schedule. Do not publish the path traversal before a fix exists; follow coordinated disclosure, request a CVE, and prepare an advisory with a description and workaround.
The secure default and 3.0 can ship together if the maintainers own the communication. A major version is the right place for a breaking default, but two plugins break, so give their maintainers advance notice, a deprecation note, and, if cheap, a compatibility flag that restores the old default with a warning. Shipping an insecure default to avoid a plugin break is the wrong trade.
Practical sequence: fix, private notice to the reporter and the downstream mapping company, release 3.0 (or a 2.x security patch first if 3.0 slips), publish the advisory, update the docs. A security fix should never wait on a feature release.
2. Evaluate the decision process around the plugin API redesign and the inactive maintainer.
Read the worked answer
Three governance gaps are visible: no voting rule, a thumbs-up count treated as a mandate, and an inactive maintainer with no defined status.
For the redesign, thumbs-up is popularity, not consensus. Ask the contributor for a short design document and a migration plan for existing plugins, discuss it on the mailing list for a fixed period, and use lazy consensus (no sustained objection from maintainers) with a vote as fallback if consensus fails. Four thousand lines written before the design is agreed is a risk, not leverage.
For the inactive maintainer, adopt an emeritus status with a documented inactivity threshold, and archive or retain commit rights explicitly. With five maintainers, one inactive, and a low bus factor, the project should also document release credentials and recruit a maintainer. Write these rules into a short governance file so the next dispute is about the rule, not about who is loudest.
3. The project splits decisions across a mailing list, an issue tracker, and IRC. Is that workable, and where should the security discussion happen?
Read the worked answer
The split works if each tool has one job: mailing list for decisions and long-form proposals (archivable and searchable), issue tracker for work items and the milestone, IRC for quick chat. The failure mode is deciding in IRC and never recording it; any decision reached in chat should be summarized on the list.
The security report must not go to IRC or a public issue. Set up a private security address restricted to a small group and keep the reporter informed throughout.
The 41 open issues before 3.0 are a signal to triage, not necessarily to fix: separate release blockers from nice-to-haves and publish the criteria. With one monthly meeting, most decisions should be asynchronous - published minutes, a 72-hour comment window for proposals, and a rotating chair. This also raises the bus factor and makes the project easier for new contributors to join.