The basic idea of this organization is to link up software developers with organizations (from here on out referred to as "partners") that need custom software development.
Developers may be interested for the following reasons:
- altruism: wanting to apply their talents to good causes (a feeling they may not be getting from their day job (
- networking: getting to know and work with others within the development community
- skill development: junior devs may be seeking more guidance through mentorship. senior devs may be seeking more experience providing mentorship and project management. developers of any skill level may interested in working outside of their typical arena (e.g. frontend developer wanting to gain more experience with backend development)
- portfolio expansion: a developer fresh out of school or a developer who only works on highly confidential closed-source solutions may be looking to build up a portfolio of publicly available code
- Access to free technical guidance and potentially free software development catered to their needs
- Partners must be legal non-profit status
- Partners are responsible for all operational costs (e.g. hosting)
- Code must be licensed under open source agreement
- Code must be publicly available on GitHub. This benefits the partner by ensuring that its history and codebase is availble in a easily accessed location. Additionally, this benefits the developer by ensuring that it is publicly available as a portfolio piece.
- Software should aim to be built against open standards and avoid vendor lock-in when possible. Reasonable exceptions can be made, for instance when looking for compute solutions it may be deemed that the cost advantage of serverless-based solutions outweigh the downsides of vendor lock-in by which they are accompanied. Another example may be authentication, something such as Auth0 may be a reasonable expense given the simplicity and security that it brings.
- Software should aim to optimize towards low costs and low management needs.
A project should:
- have a clear scope
- have a start and end date
- have a known budget
- be a software project (this is not an IT service, no "maintaining X")
- Discovery: Partner provides well-described needs, developers discuss, potentially bring questions back to partner, a team and work plan is formed through brainstorming and investigation
- Proposal: A proposed solution (UI mockups, cost estimations, description, time estimation) is provided to partner for approval
- Implementation: Developers sprint on solution over agreed upon timespan, ideally utilizing continuous integration and continual communication with partner
- Demo/Delivery: Developers demo and deliver solution to partner
Always:
- Point of Contact (from Partner)
- Project Lead (a developer)
- People often don't respect something when it is free. This could arise with Partners not tempering their requests, not giving project planning the attention it requires, and making last-minute or continual changes throughout the development process with little regard to the disruption that this brings. Solution: be very willing and ready to "fire" the partner if it becomes apparent that volunteers' time is not being respected.
- Developers or partners may abandon a project mid-way. Both parties must understand that they are making a commitment and that they must respect that.
The idea of this is organization is designed to scale remotely, however it remains to be seen how much in-person contact would be needed between a developer and partner. This should be observed and a determination can be made at a later date whether new chapters would be useful or if this could operate as a single chapter working with remote partners and volunteers.