UNICEF Blockchain Cohort Preliminary Phone Call Interviews

[whenbellstoll]

Summary

Contact each blockchain team to get a general idea of where they are in integrating FOSS into their projects.

Background

As of now, it's unclear where the teams are in the process, generally it's assumed that they're still early on, but we need direct communication to get a clear idea.

Details

• Identify what the teams have done so far.
• Where they think they need help.
• Start brainstorming next steps*

Outcome

We get a better idea of the progress and needs of the blockchain teams.

[whenbellstoll]

Coinsence.org
11 repos
5 repos seem active (updated within 10 days)
humhub modules xcoin is the most recently updated repository
Xcoin:

• Readme.md just has the word README and nothing else
• taking pull requests (unknown if these are external users or just people on the project, likely the former)

Looking at the main project github.coinsence.io:

• Readme.md is much better than the one in Xcoin, explains the project more and guides a user through installing and usage.
• Has a changelog, seems comprehensive of all the content added so far.
• https://coinsence.org is the address, readme states it's blog.coinsence.org this needs changed
• Posting guidelines look good
• No pull requests in this repo
• Updated 26 days ago

Looking at humhub modules tasks

• Read me is bare, doesn't explain anything and just points to itself "For more informations[sic]"
• I have no clue what this repo does, how to contribute, or where to get more information.

Looking at coinsence monorepo

• Deploy, Manage, and Issues guidelines on the repo looking good
• No explanation of the apps listed in the readme. No documentation in the /apps folder and subfolders either
• 1 pull request in this repo, again likely from an internal member, but still encouraging to see.

[justwheel]

Utopixar call notes - 2019-05-14

Current situation explained by team

• Focusing on product integration challenges
  • Ethereum smart contract support into Humhub
• All code found Coinsense GitHub organization
• Utopixar works on a Humhub modules to extend Humhub
  • Will not be accepted by upstream because it is a standalone plugin
• Few developers on team with prior open source experience
• Some contributions were made by Humhub upstream developers and from Ethereum ecosystem
  • Still hard for new people to get started and understand what the repos are, what the code in each repo does, etc.

Testing / automation

• Developers writing unit tests, but need more coverage
• Using Chef to provision infrastructure
• Using Travis on some repositories; needs review for effectiveness

Project management

• Using custom Agile/kanban workflow (adapted for team)
  • Mostly uses a Trello board, uses some GitHub issues
  • Weekly stand-ups in Slack

Docs

• One README written with most documentation
• Not much else documentation
• Few things infra-related are not public (e.g. credentials)

Miscellaneous

• Team is at a beginner-level of experience with open source
  • Team management trying to provide resources and guidance for developers, citing good examples, etc.
• @whenbellstoll and I will try to develop a reading list to send to all teams by next Monday as a short-term way to get the teams working on something while we work on UNICEF Identify Success Criteria #85 + UNICEF Create Rubric for FOSS Strategy #86

[Nolski]

Hi all,

Thanks for these notes! I know the FOSS is kind of being pushed on to these teams by UNICEF but did you discuss what these teams hope to achieve by open sourcing their code? (collaboration with other orgs in the sector, less development overhead with contributors, better quality code, etc.)

[justwheel]

@Nolski No, we did not ask but we should. This is what we communicated when we presented in NYC, but I am not sure the cohorts fully understand how to obtain these outcomes by open sourcing. I'll make a note to ask this in future interviews to at least get an idea of where each cohort is in this thought process.

[whenbellstoll]

Atix Labs

Current Situation

• Concerned about Intellectual Property rights in Open Source
• Trademarks of their logos, private information that they've acquired
• Afraid making their project open source will only help their competitors
• Planning on releasing first Open Source repo by the end of the month.
  • No repository currently online.

Testing

• Unit Tests are being written
• CI tool being used already, Jenkins

Project Management

• Didn't get a chance to ask, team had to leave.

Documentation

• A long ways off from thinking about it.

Any additional notes from Mike or Justin are greatly appreciated.

[Nolski]

Thanks for the notes @whenbellstoll!

Some additional notes on my end.

Current Situation

Atix Labs seems concerned that by open sourcing their web application that a competitor may use that code to build a competing product. I explained how it would be difficult as given they license it under the AGPL, the competitor would also have to be a FOSS product (given they forked/used their code) and therefore, they could just pull back any changes if they felt worthwhile.

Note: Are there any instances of someone doing this? I've heard of forks due to disagreements of product strategy but never specifically to compete and drag customers away like that.

Existing Community

They seem to be doing a good job of publicizing their product by going to conferences and such. This could be a good in for attracting new contributors, we should keep this in mind when prioritizing community building tools.

[justwheel]

Note: Are there any instances of someone doing this? I've heard of forks due to disagreements of product strategy but never specifically to compete and drag customers away like that.

This reminds me of the Nextcloud fork from Owncloud. Even though the fork was motivated by product strategy disagreements, both companies behind each product offer a product in direct competition to each other, competing for the same customer base.

On Thu, May 16, 2019 at 12:16:45AM -0700, Mike Nolan wrote: Thanks for the notes @whenbellstoll! Some additional notes on my end. Current Situation Atix Labs seems concerned that by open sourcing their web application that a competitor may use that code to build a competing product.

Seems to me that ultimately is a question they should take up with their funder, since freeing the code is the funder's requirement, not ours. Our role isn't to advocate for their freeing the code, but rather to help them better to do it. That said ...

I explained how it would be difficult as given they license it under the AGPL, the competitor would also have to be a FOSS product (given they forked/used their code) and therefore, they could just pull back any changes if they felt worthwhile.

And on this sort of point spins the tremendous heat around when and if and if so how to carry out copyleft license enforcement. Some of the more constructive and level-headed outcomes of these discussions are noted in: https://www.fsf.org/blogs/licensing/red-hat-leads-coalition-supporting-key-part-of-principles-of-community-oriented-gpl-enforcement Beyond that, though, some other points include noting that, all other things being equal, the company that provides their customers a FOSS product is providing their customers more value for money than a competitor that provides only a proprietary product, since the FOSS product comes with more accountability and future-proofing. The company might do better to consider that what they are providing is not so much the code, but expertise in the field and expertise with and around the code. That should be their differentiator, rather than as gatekeepers to one-off builds of a proprietary codebase. When they are the original authors of the code, they have first-mover advantage, regardless of whatever happens to their code downstream. By the time a competitor has come up to speed on the code base to repackage it, the original team should already have moved on to better code (for whatever value of "better" they want to emphasise: More features, fewer bugs, more efficient, better API, better integrations, etc). This is why it's so important for them to lead well when they free their code: If they just throw it over the wall without successfully building and leveraging community participation, they leave an opening for a competitor to do that better and to capture that value on behalf of customers (customers, mind, who might also be participating in other roles in the community, submitting bug reports, feature requests, contributing code or configurations, documentation, case studies, etc).

Note: Are there any instances of someone doing this? I've heard of forks due to disagreements of product strategy but never specifically to compete and drag customers away like that.

Oracle's distro is largely downstream of Red Hat's. The jostling that has gone on between the two is legend since they pretty directly compete. Less directly competitive but also well known of course are the various other distro forks: CentOS is now fairly comfortably within the Red Hat fold, but that wasn't always the case. Similarly with Fedora. Scientific Linux is on the way out, but it too is downstream of Red Hat. To name just a few. I make no claims that it is in any way comprehensive, but you might rummage around in the fork-drawer, or add examples: https://gitlab.com/deejoe/fork-drawer I think I'll add an entry for Oracle-Red Hat real soon, now that it's come up again.

[justwheel]

One Smart / OS City (Mexico) - 2019-05-17

Overall I thought this call went well. Seems like we got them to think about open source specifically for their project in a way they weren't thinking about it before.

Current situation

• Open source milestones: Active coding efforts, not focusing on open source yet
• Extending Blockcerts (MIT License) for project
  • Mostly back-end project
  • OS City building an interface and extending back-end
  • Most engagement in upstream community forums; upstream code base is lagging in contributions
  • Some communication to upstream but not much to development team; mostly with business leaders of projects
• Not thinking much about if open source practices are great; thinking to “beautify” it at the end of the funding process
• Two open source repos: one for back-end and one for front-end
  • Later: One repository only with proper documentation
  • No proprietary repositories
• Team experience: Occasional contributions but not leading a project

Project management

• Methodology:
  • One back-end developer, two front-end
  • Weekly sprints
  • Mix of agile methodologies
• Asana (https://asana.com/)
  • Scrum-based with sprints and separated tasks (“sections” in Asana)
  • Assigned to different people

Testing / code health

• Not writing frequent unit tests; not thinking about it yet
• No review process for code; depending on user front-end testing
• No automation tools used to deploy
  • Using Google Cloud Compute Engine
  • Snapshots of GCE images to reshare and redistribute images of software
  • Using Docker / containers where upstream uses it already

Documentation

• READMEs: Three repos, one is an aggregate
  • Master repo with project metadata
  • Front/back-end READMEs probably need work; not thorough
• Yes; devel environment instructions exist but could be improved

Miscellaneous

• Cash flow is biggest focus and also distraction
  • Need to deliver on other deliverables so open source aspects are neglected
  • Need better ways to make FOSS accessible to their workflow