Liveblogged at HOPE X.
James Vasile, Open Internet Tools Project
Infrastructure is any mechanism that helps developers and users engage. OpenITP believes that community infrastructure should come from the community. We’re used to infrastructure like roads: someone else builds and maintains it. A lot of FOSS projects build their own infrastructure and wind up repeating efforts and not doing a great job of it.
OpenITP tries to find a middle ground between building infrastructure and everyone fending for themselves. They do this by coordinating between projects with similar needs.
Projects need more than just code to succeed:
- Localization
- Documentation
- Code auditing
- Codebase management
- Modern, usable interfaces
- User support
- Secure distribution
James likes to build infrastructure, but came from a centralized architecture background. He’s worked to design service providers for the FOSS community, for example, working on GPLv3. The expertise to provide these services is not widespread in the FOSS community, which makes it difficult to scale capacity up.
Two years ago, at HOPE 9, James vowed to fix UI and localization in FOSS. The talk brought in a lot of volunteers, but without a roadmap it wasn’t possible to fully leverage those volunteers. In other communities, he wasn’t able to get volunteers to focus on UI rather than coding.
He’s been experimenting with building structure across projects. The first was a peer review board. We like to say that free software is more secure because many eyes make all bugs shallow, but we’re not using our eyes. Heartbleed is an example of why this is a problem, and why we need peer review. Security audits are hard, and take time and expertise.
They realized you can’t just crowd-source auditing, so OpenITP brought in paid experts. They also created a process to manage the audits. The process worked and they did a successful audit, but ran out of the money to do it. This means that projects need to fund their own audits, and most don’t.
Lessons learned. They would have been better with a quick and dirty approach. Top-down approaches are less stable than building community from the beginning.
The second experiment OpenITP did was a localization project. There’s a huge gap between the makers and users of tools because not everyone is a native English speaker. Whenever he talks to users from the Middle-East, the language barrier is always one of the first things mentioned, even when they do speak English. It was easy to get volunteers for this project, mostly by one-on-one recruiting at conferences. They got a donated license to Transifex, a proprietary localization tool, which helps them, but locks them into software that could become very expensive later.
The process worked by setting milestones and deadlines. There was a constant sense of urgency that burned out volunteers. Continuous work-flow is more desirable. They’ve made dozens of major releases, so it’s been a success, but they need to do things to move forward. James would like to build a stronger community that makes its own decisions. Communities like that start doing spontaneous, important work.
Moving forward. The bottlenecks are central managers. They’ve started Secure User Practices to build a community around user experience, which is more like expert auditing than localization.