Model Organizations - UrbanOS-Examples/TechnicalWorkingGroup GitHub Wiki

Background

This is currently receiving updates - we are considering this a DRAFT for now.

As part of the endeavor towards developing an open source footprint for the SmartCity Columbus we have asked ourselves a seemingly simple question - How do we plan to interact with the community in the context of open source. Sure we plan to use plenty of open source software components ( open source, free software - nit pick for later - reference issue #1).

The Smart Columbus Operating system itself will be built with / around a number of open source software packages. It is certainly likely there will be contributions back to these communities ( pull requests, documentation, filing issues etc ). When it comes to building a community of our own we need to think very hard about what other organizations, communities and even individuals have done. What has worked well, what has not worked.

We have taken what felt like the right approach towards this end. We have opened up a github repo along with a number of issues to discuss the various aspects. This document is intended to combine the points as discussed in issue #2 around Model Organizations - we strongly encourage you to review the comments in this issue. With this said, the wiki document is intended to be a living document - just because we discussed something a particular way ( or did not mention something in the issue ) does not intend to imply we are done. This document should continue to be maintained as our project continues. Things change and that should be a good thing.

Please note this document is intended to focus on the what not the how. What ideals we should look look to adopt, what should we watch out for / look to prevent. There are other high-level issues such as license selection which will dive further into these key areas. This document is more or less a building block / foundation for future work.

Model Organizations

Qualifications for a "model organization"

Our goal is to build the foundation for a healthy open source community in/around Smart City Columbus. We must find out what other organizations and projects have done well and, when appropriate, look for characteristics of what not to do / avoid. We must ask ourselves a few questions about each project / community we intend to evaluate:

  1. How healthy is their community?
  2. Is there anything which makes this community welcoming or otherwise?
  3. Have there been situations which caused fractures in the community?
  4. If there were fractures, how bad - what happened and what, if any, were the warning signs

Please note, the order of these questions is not necessarily ordered or weighted - should they be?

  1. How does the project / organization take feedback?
    • Issues
    • Pull Requests
    • Email / other
    • Forum / Slack?
  2. Do they communicate a roadmap?
    • Are the application / project features must be publicly visible
    • Does the community have input on this roadmap?
  3. How is licensing handled?
    • Existing opensource license?
    • Some other license?
  4. Are the issues / bugs / enhancements publicly accessible?
    • May get too far into the how, what are they using for issue tracking
    • How transparent are they with bugs, exploits?
    • How do they prioritize bug fixes and security issues?
  5. What kind of documentation do they provide?
    • Is the documentation stored in a revision control system?
    • What about things like api / code-level documentation?
    • implementation, administrative and operational documentation?
  6. Do they publish / maintain contributors for each project
    • Contributors.md or equivalent in the code repo?
    • Release notes reference?
  7. What is their process for accepting community contributions
    • Do they require a Contributor License Agreement?
    • Pull requests accepted?
    • How is the communication during the review process?
      • simple yes / no
      • some form of mentoring / code improvement?
  8. Is there a code of conduct?
  9. How long as the project / organization existed?
    • If this is an organization are they solely focused on open source software / products?
    • Do they follow an open core model?

Chosen model organizations / projects

Please take these as they are intended - an honest view without bias and with the goal of educating ourselves to be better stewards to build a great open source community. The list of organizations / projects below are for reference and to inform ourselves of what to do, what not to do and things to watch out for to keep the environment healthy and inclusive.

For now the format is not in a form / chart layout as this would likely be far too difficult to read. Not sure if it would make sense for a change in the future or not.

Elastic.co

Elastic.co is a software development company which started with 3 main products - each of which were being developed separately at the time. The imfamous elk was comprised of these three open source projects - Elasticsearch, Logstash and Kibana. The main projects eventually combined forces via the elastic.co corporation. Their products have continued to have strong adoption and continued growth in other sectors with things like beats apm and others.

The elasticsearch and other components have been open source for some time, suggest reading up on their open source code page for additional context there as well as checking out their github org

Pros

  1. They follow the open core
  2. They have code-generated documentation
  3. They have clear contribution documentation
  4. Clearly licensed source code at the top of each project repository
  5. Very active external Contributors
  6. Clear release notes with details on changes
    • beats
    • elasticsearch
      • Nit-pick, I had to hunt around for the elasticsearch release notes vs having them linked in the release itself like beats has it
    • etc not going to enumerate all
  • Each release note found has clear references to issues resolved
  1. Public Issues
  2. bugs are public!
  3. They have a contributor license agreement

Cons

  1. They have a contributor license agreement
    • listed again as a con, some view this could be deter contributions
  2. x-pack is open source however use of certain features requires a support contract / subscription
    • Features like ssl and authentication/authorization require a subscription ;(

Misc final thoughts

Over-all I feel the elastic.co community is very healthy. There are a few aspects which could possibly be improved upon but looking at the number of contributors over time just on code is quite impressive. We could learn a lot especially when it comes to mixing open source / open core and having modules / plugins which allow for professional services and customized integrations and extensions.

Apache Software Foundation

Rather than focus on projects which are part of the [Apache Software Foundation] we should focus specifically on how the ASF itself works.

Note this is a copy/paste from how-it-works

The Apache Software Foundation (ASF) is a 501(c)3 non-profit public charity organization incorporated in the United States of America and was formed in 1999 primarily to:
   * provide a foundation for open, collaborative software development projects by supplying hardware, communication, and business infrastructure
   * create an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the public benefit
   * provide a means for individual volunteers to be sheltered from legal suits directed at the Foundation's projects
   * protect the 'Apache' brand, as applied to its software products, from being abused by other organizations

That's the dry fact, but how did all this come to be and what does it really mean in its details? We need to step back a little in history.

Pros

  1. Functions as a meritocracy - government by merit
    • As individuals contribute code, they are eventually given access to the code repository for a given project
      • this allows each project to scale up/down independent of any other project
      • purely voluntary
  2. by-product of meritocracy this prevents a top-down monoculture governing all projects
  3. Very effective structure
    • ( these are copy/paste from the how-it-works page as well )
    • Board of Directors (board) governs the foundation and is composed of members.
    • Project Management Committees (PMC) govern the projects, and they are composed of committers. (Note that every member is, by definition, also a committer.)
    • Various Officers of the corporation, appointed by the board, who set Foundation-wide policies in specific areas (legal, brand, fundraising, etc.)
  4. published bylaws
  5. published governance
  6. published project management communities
  7. Strong focus of independence from undue commercial influence.
  8. Great focus on philosophy to guide the projects
  9. Consideration for confidentiality balanced with public discussions
  10. Incubator for on-boarding of new projects
  11. published code of conduct
  12. Established roles *User *Developer *committer *PMC member *PMC chair *ASF Member
  13. Focus on project management
  14. Can be applied to our data governance and elsewhere
  15. Sponsor-backed

Cons

  1. Bootstrapping this type of committee is likely to need outside help
    • We really should reach out to ASF if we go this route
  2. Will require an investment of/in local individuals to build out

Misc final thoughts

This is likely the model we should look to follow. It will fit very well in a number of ways:

  1. We are planning to have our public software projects
  2. We are looking to have other cities adopt this software and extend
    • And we would have a natural way to build out a board - get people from across the implementations ( regardless of size )
  3. Having a format such as the how it works and encouraging for each project to self-manage has the potential to significantly reduce the over-all burden of any one city / user.

Debian Social Contract

Copy from Debian Social Contract page:

Debian, the producers of the Debian system, have created the Debian Social Contract*. The Debian Free Software Guidelines (DFSG) part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the Open Source Definition.

Pros

  1. committed to releasing 100% free software
  2. Commit to remaining a part of the open source community via contributes back
  3. committed to keeping issues public
  4. Allow software not specific to their software distribution to be made available via a "non-free" repository
  5. Allows for derived works
  6. requires updates to a software patch be distributed with un-altered source code and patches applied at build-time
  7. includes anti-descrimination against people, groups as well as against fields of endeavor

Cons

  1. Mostly deals with software licensing and not as strongly on community structure

Misc final thoughts

opensource.org

The opensource.org Open Source Definition licensing has been derived from Debian Free Software Guidelines document.

Pros

  1. Pretty much the defacto standard for open source software licensing
  2. Allows for software to be distributed in both source and binary form
  3. requires updates to the software be distributed via patch files to be applied at build time
  4. includes anti-descrimination against people, groups as well as against fields of endeavor

Cons

  1. This is mostly focused on the licensing of software and less on how to build a community

Misc final thoughts

We should look to using the Open Source Definition more around the licensing efforts vs as part of the model organizations / projects.

OpenStreetMap Foundation

OpenStreetMap (OSM) is an initiative to create and provide free geographic data, such as street maps, to anyone. The OpenStreetMap Foundation is an international not-for-profit organization supporting, but not controlling, the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data and to providing geospatial data for anyone to use and share.

Pros

  1. The data is shared under the Open Database License
  2. This is a very established and tested open-source infrastructure for geospatial-specific datasets. Cities around the world already use OSM for navigation and urban planning. As a majority of the data in the Operating System has some form of geospatial element, it seems in our advantage to explore more development of our infrastructure in ways that are compatible with theirs.
  3. There are several tutorials on contributing to the data.
  4. The OSM Foundation leads several fundraising efforts, and hosts a number of annual regional and international conferences to grow the community.
  5. Many for-profit mapping organizations have close connections with the OpenStreetMap community
  6. In partnership with Mapbox, a guide is available to outline how some relationships have already been created between cities and OpenStreetMaps.

Cons

  1. The content and community moderation is not as mature as other organizations such as WikiMedia.

Recommendations

The recommendations section for now is being written to fill out a powerpoint and is more summary in nature. More will be added here shortly

From the pptx:

  1. Downsides
    • What are the risks and issues?
    • List of downsides with potential ways to mitigate
  2. Who might we model after?
    • At least 1 organization to recommend to use as a model

Who might we model after?

Based on the research outlined in this document as well as the goals of the long-term support we recommend to model after the Apache Software Foundation.

Pros

  1. Started as a foundation to support the apache webserver project and has scaled to over 350 projects
  2. Steady growth year over year
  3. Focused on building structure to support projects
  4. Addresses adding core contributors via a meritocracy - based on contributions of individuals
  5. Allows each project to run independent of each other
  6. On-boards new projects via an incubator / mentoring process
  7. Less focus on specific languages or technologies
  8. Established roles
    • User
    • Developer
    • committer
    • PMC member
    • PMC chair
    • ASF Member
  9. Focus on project management
  10. Can be applied to our data governance and elsewhere
  11. Sponsor-backed via Levels
  12. This model would work very well for our data based needs and use-cases

For the model we have discussed at various points for the NGO / long-term support of this platform we need a good strong foundation. Building something along the lines of the Apache Software Foundation will check a number of the boxes for us. As we gain adoption in other cities, we will gain a number of key elements:

  1. Additional sponsorship opportunities
  2. Naturally allows for broader diversification of all resources
    • people
    • new contributors to existing projects
    • Opportunity for new committers to core projects
    • new projects based on the needs of a city - giving back to the benefit others
  3. We prevent a monoculture

Cons ( aka risks )

  1. Could be perceived as too heavy of a solution
  2. We will have a lot of bootstrapping work to do
  3. Initial board / roles will need special attention
    • We want to get the start done right
    • We should consider existing TWG individuals

Post TWG segment 3 recommendations

  1. Creation of an NGO or similar organization
    • As part of this organization consideration into funding / sponsorship needs to be researched
    • Further refine the roles as outlined in the Model Organizations wiki
  2. Consider bootstrapping of this org with existing members of The OS team as well as TWG members
  3. Select an existing software project to release as open source
    • This will force the creation of steps to releasing a project
    • Issue templates
    • Contributions guide
    • Etc