I am a Cub Scout den leader and in my day job I run technology teams for highly regulated applications at web-scale. Platform engineering, security, the whole developer experience side of a software organization is my remit. That is my trade the way another parent in my pack is a nurse and another is an electrician. We all show up at our pack and pour whatever we are good at into the program so that the cubs can have an awesome experience while learning to be the best they can be. Which is why one thing has always struck me as odd: the nurse can handle our first aid, the electrician can rewire the camp shed… but if your trade happens to be software, there is no real way to help with the technology our units run on every week, outside of websites. We all use Scoutbook and hit the rough edges, and about all we can do is post about it and wait. I want to make the case for changing that.
Here is the gap I keep bumping into: there is no public roadmap aside from a rigid waterfall one that doesn’t seem to have updates, so we cannot see what is coming or help shape it. There is no public bug tracker that I’ve been able to find, so reports go into the void that is our discussion forum. There is no supported API for simple things like getting the program requirements, and the beta program is a small group under NDA. None of that is a knock on the folks doing the work, but it highlights the closed loop which leaves a lot of willing hands on the sideline and valuable feedback unheard.
And those hands are already busy, quietly. Think about the Feature Assistant extension. One volunteer built it, it got so useful that the official help site ended up documenting it, and now Scoutbook Plus is absorbing its features. That is a volunteer effectively contributing to the roadmap through the side door. Other volunteers have posted their own API documentation on GitHub because there was no official version. The commercial tools like TroopTrack and Troopmaster keep the lights on with file uploads because there is nothing better to plug into. The talent and the demand are not hypothetical. They are here today, working in the dark, with no security review and no youth protection guardrails around any of it. To me that is the strongest argument of all: bringing this into the open is safer than pretending it is not happening.
None of this would be inventing something new either. FIRST Robotics has run for years on an open source library that staff and community volunteers maintain together. The Scouts in the UK have a real GitHub presence. Wikimedia lets its community propose and vote on what gets built each year. Even federal agencies, handling far touchier data than we ever will, are required to publish a chunk of their code in the open. The recipe is well proven and fairly straightforward. The staff own the roadmap, review everything, and control what ships while Volunteers assist with writing code, docs, and tests. Nobody outside staff ever touches real member data and the brand stays locked down.
The easiest first step costs almost nothing: publish an updated roadmap with monthly update posts, and let units opt into beta builds without an NDA (feature flags per council/unit anyone?) That alone would buy a ton of goodwill. From there, put out real API docs and a sandbox that only ever holds fake data, and stand up a volunteer technology committee that looks exactly like the national volunteer committees we already have, with everyone registered and background checked like any other adult leader. The bigger step, whenever it makes sense, is an official GitHub organization that opens up the low risk pieces first. Report generators, import and export tools, docs, sample code, the program requirements in json format. The staff stay in charge as the maintainers and volunteers who pitch in get their service hours counted, same as a merit badge counselor.
I know the first worry, because it is my worry too. Youth protection and privacy come before anything else. That is the whole reason contributors would never get near production or member data. They work against fake data, and staff review every change before it goes anywhere. Liability is covered the same way every open source project covers it, and nothing ships without staff signing off. The brand and the official app label stay closed even when the code is open. This can be done carefully and plenty of organizations already do. There are Open Source Programs that are publicly documented everywhere for large organizations, but none of them have the one advantage that Scouting America has which is it’s huge base of committed volunteers. It won’t necessarily be easy to start, but I think the potentially huge advantage outweighs it.
We teach the kids to leave a place better than they found it. A lot of us would jump at the chance to do that for Scoutbook or any other piece of tech. I’m working on a reusable component library and design system for my pack because I want to share it more broadly. If anyone from National is reading, I would love to talk about piloting even the smallest piece of this, and I will put my hand up for that first committee right now. If you are another volunteer who works in tech, reply and say so. I’ve seen a bunch of folks in this forum ask to be more involved.
Thanks for reading, and honestly, thanks to the dev team and technology committee leaders. The progress this year is real and noticed. I’d just like to see it accelerated with the volunteers that we already have.
Sincerely,
-Derek Murawsky
Pack 199, Washington Crossing Council, Den Leader (Den 3, AOL)
