-
Notifications
You must be signed in to change notification settings - Fork 0
Home
- Background
- Model Organizations
- Chosen model organizations / projects
- Preserved from original for now - this needs merged
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, how do the users of these projects perceive.
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.
What is it that would make for a good role model? We should not look just at what was done well. We must also consider what has not gone well - there are still things ( likely more ) to learn.
The order of these rules is not necessarily ordered - certainly could be.
- We must always welcome feedback
- Reference The three ways as discussed in The Phoenix Project - the second way.
- Issues
- Pull Requests
- Email / other
- Forum / Slack?
- Communicate Roadmap
- All application / project features must be publicly visible
- The projects coming from the Smart Columbus OS should have a clearly defined roadmap
- The community, to a certain degree, should have input on this roadmap
- Will be difficult to address a number of different issues
- Feature not needed by project owners
- Similarity to in-progress work but conflicting direction, code etc
- Too difficult to integrate
- ... etc not necessary to enumerate all scenarios here / now
- Will be difficult to address a number of different issues
- Clearly licensed
- This is being discussed in greater detail in issue #3
- All issues related to each project is public
- This could be via github issues or some other issue tracker
- Full transparency is a must to build / maintain trust
- Provide clear and concise documentation
- Full documentation of any / all features
- Clear and accurate code / api documentation
- Preferably auto-generated as part of the build / release process
- implementation, administrative and operational documentation
- May not always be appropriate
- Document usage of tools etc
- Maintain Contributors for each project
- Contributors.md in the code repo
- Release notes reference
- ... etc
- We must clearly convey a process for contribution
- This is being discussed in greater detail in issue #4
- We should weigh having a code of conduct
- There is reasonable concern this could deter contributors
- This is being discussed in greater detail in issue #5
- We should weigh having a Contributor License Agreement
- This is being discussed in greater detail in issue #6
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.
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
- They follow the open core
- They have code-generated documentation
- They have clear contribution documentation
- elasticsearch
- kibana
- beats
- elasticsearch-ruby
- ... etc not going to enumerate all of them
- Clearly licensed source code at the top of each project repository
-
elasticsearch
- including additional licenses
- etc not going to enumerate all
-
elasticsearch
- Very active external Contributors
- elasticsearch has 1107 at this time
- kibana has 295
- beats has 311
- etc, not going to enumerate all
- 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
- Public Issues
- nice use of tags / labels
- bugs are public!
- They have a contributor license agreement
- They have a contributor license agreement
- listed again as a con, some view this could be deter contributions
-
x-pack is open source however use of certain features requires a support contract / subscription
- Features like ssl and authentication/authorization require a subscription ;(
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.
Redhat has been around for a very long time. What started as an open source linux distribution back in 2004 has since grown into a multi-billion dollar company ( most recently being acquired by IBM ).
Redhat, as a commercial organization, has gone on to acquire a number of other companies. A non-exhaustive list:
Many(need citation) of these acquisitions have resulted in closed source applications being released under an open source license.
We need specific projects which fall under the Apache Software Foundation. It may be better to replace this section with a section each for the projects
We need specific projects which google has launched. It may be better to replace this section with a section each for the projects
... summary ...
... summary ...
... summary ...
... summary ...
... summary ...
... summary ...
... summary ...
Who engages the community well? Who has the best quality and security? And stuff like that.
Reference issues #2 and possibly others
This post from WAY BACK in 2003 has some great stuff in it: A Group Is Its Own Worst Enemy
It's long, but it gets down to: Three Things to Accept
- You cannot completely separate technical and social issues
- Members are different than users
- The core group has rights that trump individual rights in some situations
And Four Things to Design For
- Handles the user can invest in (stable identity, reputation)
- A way for there to be members in good standing
- Some kind of segmentation of capabilities (some barriers to entry)
- Find a way to deal with scale