Supporting External Open Source Projects from Your Local Community

I’d like to know if other brigades have experience interacting with pre-existing, open-source projects in your local community that are seeking support from your brigade. To clarify, this does not apply to homegrown brigade projects, but rather an external project that meets our project requirements (civic mission, open source, not for profit, etc.).

Do you have any guidelines as to how you support these types of projects? For instance, promoting them internally (hack nights, among members), promoting externally (allowing use of brigade branding, website/newsletters), or overseeing their work.

3 Likes

I often try to engage with these projects by pitching them adding themselves to our projects directory and using us as a community for feedback and recruiting. I generally take the view that nothing is really “a Code for Philly project”, rather we’re just indexers of projects meeting certain criteria and a suite of resources to support them. From that POV it matters little where/when a project originated. Some brigades use their GitHub organization as a list of projects but I personally feel strongly that it’s better to run a directory that’s independent of any particular code owner.

1 Like

Thanks Chris, I appreciate sharing your viewpoint. One concern I’ve had with taking this stance is that in a hypothetical situation, a project owner would come to you and receive regular support for months while we’re promoting the project as something the brigade is involved in.

What would happen if that owner one day sees a path to profitability and decides to leave to turn it into a for-profit endeavor? It’s something that Hack for LA is really concerned with because (to this point in our hypothetical situation) it could potentially put our partner orgs in a bind.

Again, thanks for sharing. I’m interested to see if you’ve come across this scenario as well!

1 Like

Our core two requirements for projects are that they are released under an OSI-approved open-source license and support the public interest.

If someone builds a for-profit business on top of a project, that’s great! It’s a legitimate path to sustainability. They can’t revoke the rights already granted for the open source releases up to that point and there’s no reason the brigade can’t keep supporting contributions to the open source code base. Based on the license selected, everyone has the option to build a business on top of the work supported by the brigade, or to keep building on and using it in the public space.

If a proper license is in place, the worst that can happen is a private fork carries on work that night not otherwise get done. If a project wants to protect against even that, the AGPL requires that any users of the project have access to its code.

This scenario can arise with home grown projects too though just the same as adopted ones. When code is released under an open-source license certain rights are granted for whoever wants to come along and exercise them

Great thread! Thinking about sustainability and opportunities to resource this work, Idea why isn’t there a philanthropic micro-foundation for mini-grants to support the development of open source projects? Our merry band of Argonauts recently forked the nifty DataMade census_area repo to dev on developing aggregate census stats for arbitrary polygons (key given many administrative boundaries like water utilities don’t line up nicely with census blocks). See here:

Right now that’s a volunteer investment on behalf of our core team and some great CUSP grad students though as we look to mature civic tech there’s a key need for financial sustainability. Why not something like an Apache software foundation to provide micro-grants to support a project?

Small 4-5 figure funds can be transformational for open source work. Makes such a difference for the long term sustainability and keeping people engaged after the initial zeal of a new project wears off.

In terms of developing said funds, see here for an IDEA about a no-lose lottery to provide capital. My bias is that California can and should lead the way here:

1t1d

2 Likes

Totally agree, the brigade network should be equipped to award stipends for volunteers that are already working on a promising project to go hard on it for a spell.

It would need to be a very agile system though that could react to emerging opportunities quickly and meet volunteers where the schedules in their life afford the commitment. I don’t think traditional grant/fellow programs with rigid cycles give us access to most of the innovation out there.

For example, if interest starts ballooning in a project and one of the core contributors has a potential 5 week gap in their schedule coming up, the network needs to both recognize that and deploy support for it swiftly. “Spend a month applying to X 6-month program next spring” won’t cut it

2 Likes

Yeah I actually think this could be a great role and evolution for the NAC. Imagine say a budget of $100k (just throwing a number out there) a year to distribute in low-bono grants.

Thesis is that there’s a bunch of small civic tech / data consulting shops (like datamade, compiler etc) and people willing to moonlight.

Idea is a project based stipend with a specific deliverable. That low bono model aligns incentives so that there’s a clear expectation to deliver the work and also makes the work more sustainable.

Could also learn from the 18f micro-purchase marketplace which was $1-5k ish though think that one fizzled from the difficulties from federal contracting which this would avoid.

2 Likes

Also you might enjoy some of these examples of civic tech / data projects outside the Brigade network from ARGO’s work with NYU CUSP grad students (where we went to grad school):

Why not redeploy the incredible micropurchase marketplace for open source software that 18f pioneered. What else? Why not in CA?