You're doing it wrong. How to release free software so you'll get contributions.

From DevSummit
Revision as of 18:25, 5 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Evan told us how we are doing it wrong. It came out of the meeting that an updated book, or a book specific to non-profits, is needed.

  • Putting it on github and forgetting its broke is not a release.
  • Open sourcing components is often more easy and gets more contribution.
  • Open sourcing things not core to the mission of the organization is something that commercial companies do, that may be an applicable model.
  • (get rest of bullet points from Tomas).
  • Ushaidi did things wrong, but then turned around
  1. only skype
  2. no member list
  3. one had to submit form to get code
  4. no contribution process
  5. they read Karl Fogel's book
  6. open mailing lists ....
  7. once people made that transition, people showed up to produce code.

Points from the report-back:

  1. Maybe open sourcing the mission specific part of the stack isn'ft the right investment
  2. Start by contributoing back to the os tools that you use
  3. The process is more important than the license
  4. Think of the programmers as another community you need to organise. Community organising for non-profits
  5. We need to add to carl vogels 'producing open source software' to create a book for non-profits and funders who want to understand the issues.

Below here is the rest of the raw dump.

Some things are open sourced to fulfill grant requirements to funders(eg. to Knight Foundation). The code is thrown over wall as a tar ball, so this seldom works.

does make it easy to then close source it but get no benefits from contributors.

To do free software have

  • have to use irc
  • have to have open mailing list

Polymaps only way to communicate back is 'github issues' no indication that is how to communicate they delete the bug record no way to contact developer

with Drupal, there is a model

some academics develop it, get it paid for develop it, live in their own world.

Best talk, people at github developers at github always write the readme first write the code (as if it will be free software - internal collaboration when time to make it public, they just flip a switch 3 guys to 45 no hierarchy, no managers run internally as free software

knowing others will look at code, great way to improve.

Funder driven free software, they think its just a license.

funders starting to see that its not sustainable.

in commercial world most developers have a job that uses that software

open sms stuff - tiny community paid by somewhere.

companies can see a profit motivation.

Frontline SMS does everything wrong, but get contributions.

code developing and code they are delivering.

Sunlight foundation 2 people working months, code could not be merged in.

only helps if two people (?)

github project account consistent versioning etc. (see Karl's book) book needs updated - distributed version control making it github specific people need specific guidelines

Some projects will get contributions no matter what Som projects will get contributions if all done right Some will never get contributions.

non-profit sector more competitive that profit sector - can't grow the pie.

nothing funder driven that I have seen has helped.

commercial clients change the dynamic (civiCRM vs Drupal), not many pure civi does not relate to the mission. free software works better if its building blocks.

non-profits hiring corporate shops (ThoughtWorks, Pivotal, etc.) doing good open source work.

Evan, "Never hire a firm that does not push to do open source."

Things that you get community, etc.

community management, roadmap of simple contributions.

rails history, one guy, then a few more. Not open process. people protesting, code got forked, community forked, antagonistic communities,

eventually the companies (37 signals, etc.) said you will merge these projects.

Rails is much better for it.

first contributors won't be worth the investment, but will pay it back in the long-term. barrier: its good for the long-term, but non-profits live on short term grant cycles.

newsletter, weekly updates, etc.

One can share too early. Could not get to contribution part cause could not run.

need to release it and say clearly 'it won't work.'

Ubunto: looking for community organizers - watch the mailing lists: no one applied.

resource issue - did not have the people or time.

Final product is more useful than the parts to developers, but not to community.

Difference between open source code and proprietary code. Open source code is made to be extensible. They are different. People don't contribute to the core, they extend it to do things they want.

Need good extension architectures.

Maybe should contribute back to the community on those tools that they use. Open source everything not is critical to their mission.

Tomas says we should write a book: focused on non-profits.

Need to be able to do derivative works on books