What categories of should we look at when looking at "Model Organizations"?

[rubberduck203]

Different organizations do different things well.
For example, Automotive Grade Linux does a wonderful job of getting people together in person once a year, and remotely for their monthly conference call, but they do a less than stellar job of openly tracking bugs/feature requests/issues.
We may want to offer them as a model for the prior, but not the latter.
I believe we should offer models for different areas of process, community engagement, etc.

Thoughts on this approach?
If we agree that this would be better than offering a single org to model after, which categories should we consider?

[jdenen]

I agree that we should choose model organizations for categories. Some categories off the top of my head:

• Communicating project direction
• Saying no
• Contribution feedback
• Mentorship
• Contribution process
• Generating buzz
• Managing GitHub issues

[bilsch]

I had never heard of Automotive Grade Linux - interesting ;) I'm curious if they are doing anything with OSHW - would be really nice if they were!

I have a few thoughts / ideas around how we would want to go about looking for model organizations:

The organization must meet X of Y (TBD) criteria as it relates to open source software

1. publicly viewable source code repository without restrictions to read the full repository
2. publicly viewable issues, fixes and contributors
3. clearly define which license(s) are in-use
4. clear documentation on how to go about contributing
5. Must have an active and healthy community presence
   • Yes, I know healthy is very generic here. We should expand this
   • I'm thinking about issues like the linux kernel code of conduct, SQLite which have been very public and rife with conflict

Many organizations follow an "open core". Special care and consideration should be employed when we look at these in the context of the platform. If we choose to employ an open core component but also at our leisure in Columbus make use of a licensed component we must decide how to treat defaults in the software. Would we require a feature toggle for this part of the application and what other considerations might we need to work through? At a minimum we must call this out very clearly somewhere in the project documentation ( README.md for instance ).

A few companies I feel would make for good examples:

1. RedHat
2. Elastic.co
   • Interesting example for open core: x-pack - its open source but requires a license / subscription to enable
3. Pretty much anything by Apache
4. Mozilla
5. google
6. microsoft
   • They have really changed over the last few years with respect to open source
7. Hashicorp
   • Another good example of an open core style company
8. Docker

[bilsch]

@jdenen I'm curious what do you mean by "saying no" here? Lacking context this could mean quite a bit could you please elaborate?

I agree that we should choose model organizations for categories. Some categories off the top of my head:

• Communicating project direction
• Saying no

[rubberduck203]

Google is not a good example of how to run an open source community.
They may have some individual projects that do some things well, but working with the Android Open Source Project is a nightmare.

That's why I don't want to limit ourselves to a single organization here.
I want us to determine which projects are doing particular things well.

For example, the .Net team has done a great job of automating Contributor License Agreements, the Rust community has established a very open RFC process on their forums, multiple companies are doing well with the "open core" model you keep mentioning.

It's in the project's best interest if we identify these things with more granularity rather than just a single organization to model after.

[rubberduck203]

I'm curious what do you mean by "saying no" here? Lacking context this could mean quite a bit could you please elaborate?

I'm assuming a bit here, so I expect @jdenen to correct me if this isn't what he meant.

Every successful open source project gets a lot of feature or pull requests that for one reason or another don't make sense for the project. My experience as a maintainer has been one mostly of saying "No." to people.

No. We're not adding support for Windows XP. That would mean rewriting a substantial part of the code base in order to add support for an operating system that hasn't been supported by Microsoft itself for years.

No. That sounds like a great feature, but it's simply out of scope for this project. Someone should definitely build that, it's just not us.

This is an extraordinarily hard thing to do without chasing community members away, but if you don't do it, the project will collapse under the weight of all those features you shouldn't have added.

[bilsch]

Every successful open source project gets a lot of feature or pull requests that for one reason or another don't make sense for the project. My experience as a maintainer has been one mostly of saying "No." to people.

I think being able to say no to an issue / feature request / pull request is absolutely fine. We should encourage as part of our code of conduct or some other document ( maybe, just my thoughts ) that by saying no is far more detailed than just no. We should give reasoning behind the no. I think this would break down into a ( again, non-exhaustive ) list:

1. We are already working on this feature
2. Please make changes
   • Add documentation
   • Add specs and/or unit tests
   • Code cleanup
   • ... etc. The idea behind to collaborate with, not just reject
3. The change is not relevant
   • un-related to the work
   • adds extra complexity which is better served in a separate work ( eg, extends the project in a way that is better-off in a different place )
4. Assuming we do some form of contribution requirements doc and it fails in some way
   • For instance if we require signing some kind of contribution agreement first
   • Goes against the code of conduct or other important doc

[bilsch]

Google is not a good example of how to run an open source community.
They may have some individual projects that do some things well, but working with the Android Open Source Project is a nightmare.

(...)

That's why I don't want to limit ourselves to a single organization here.
I want us to determine which projects are doing particular things well.

Good examples could also be examples of what not to do for the projects. Also I think saying no to Google over their practices for Android alone would be unfair. tensorflow, kubernetes, snappy and golang as examples of other projects either part of google or started as part of research / work from google.

[rubberduck203]

I think saying no to Google over their practices for Android alone would be unfair.

That is precisely my point. We should be modeling after what different projects are good at. So let’s real this in and figure out which categories we want to look into.

The proposed list so far:

• Communicating project direction
• Saying “No”
• Contribution feedback/mentoring
• Contribution process
• Generating “buzz”
• Managing bugs/feature requests
• Community creation
• Monetization

[bilsch]

Something else I think I missed in my prior responses. We should strive to have all software issues public. Any / all pull requests with links etc. IMO part of working on an open source community / project is visibility.

Sure not all things will matter to the public in general. If we are developing things in the public, tracking defects, releases and patches / changes etc this can only help promote a healthy and inviting project.

( And yes, I do mean to take what current issues there are in the jira instance and make it all public ;) )

[jdenen]

@rubberduck203 articulated what I meant by "saying no" correctly. By no means do I mean that we just say "no." We should absolutely explain why and have good reasoning. But we need to be able to say no.

( And yes, I do mean to take what current issues there are in the jira instance and make it all public ;) )

I would rather we move them to GitHub.

[rubberduck203]

Agreed, but that all really falls under the "Identify a process for code commit, core team membership, release pipeline" area. We'll need to find a way for the paid team to aggregate that work for metric tracking purposes, but that our problem, not the community's.

If everyone is good with the list above as a starting point, I'll move them into the wiki so we can move on and start identifying projects/orgs that do those things well.

[bilsch]

I would like to allow more time for other twg members to join in on this discussion before we call this issue closed/done.

I have no problem taking the list you generated so far and beginning to fill out wiki sections for it

[bilsch]

The proposed list so far:

Communicating project direction
Saying “No”
Contribution feedback/mentoring
Contribution process
Generating “buzz”
Managing bugs/feature requests
Community creation
Monetization

Can you explain what you mean about generating buzz? I'm not sure I follow this one.

I would rather we move them to GitHub.

Yes, can this be discussed internally and find a way to start opening up the process / issues list or is that too soon? I would like to see more transparency - even if this means an initial stance of no external contributions.

[skpy]

I wonder if defining categories and then looking for companies or projects that succeed of fail within those categories is really the right approach?

Are we trying to define actual operating guidelines? Or are we identifying aspirations?

Are we working to define a product, a project, or a community? Each of those will have different implications, and trying to define in advance a list of guidelines seems not to be a good use of our time.

Many of the successful projects and companies thriving with open source have full time community managers working to facilitate that success. Since we're all volunteers, working in our spare time, on a brand new project, it seems better to me to enumerate a small list of goals and principles, and ensure we have flexibility to adjust these as our work evolves. What works for our small group right now might not work well for a more robust body of contributors; but similarly what is required by a big, global community might unnecessarily slow us down right now. So we should have something loose to guide us now, with an ability to improve as we go.

For example, "saying no" implies a clear understanding of project direction, which is something we don't currently have. So defining how to "say no" right now may cause problems in the not-too-distant future. Saying no may also be naturally shaped by other defined communication norms: be nice, be explicit, be helpful, etc.

As such, I propose we close this issue in favor of concentrating on #4, #5, and #6. We should also work to embody and role model the kind of positive interaction we desire to foster from new participants when they arrive.

[rubberduck203]

I’m completely ok with closing this issue and taking another approach on finding model orgs for recommendation. I’m just slightly concerned that if we give the program a single org to model after, they’ll run with it instead of being critical about what it is that org is good at.

Closing this for now, at least.

[bilsch]

Adding a few to the list. Thanks for the suggestions @skpy !

Mozilla, Debian, Fedora, Wikimedia, and others all operate openly. They have established codes of conduct, lawyers, and reasonably healthy communities

[bilsch]

We should also look at Rust thanks @rubberduck203 for the suggestion

[bilsch]

I'm going to re-open this issue to allow for comments / reviews. Once we are done with that process. I'm not sure how long we should wait on this for feedback - my thinking is past next group meeting we can then call this resolved

[bilsch]

I have received no feedback from the model organizations wiki page. I consider this closed / finished