Open Stack

On Fri, Jun 24, 2022, at 11:39 AM, Ghanshyam Mann wrote:
>

snip

>
> No, it's not a defeatist attitude but instead a practical attitude and 
> move forward to progress the things rather
> than stuck on currently-not-working stuff. Being practical based on 
> facts and not being optimistic is not defeat.
>
> I think Artem also explained it what I meant by 'new contributor' in 
> this context. But let me elaborate on my statement.
> There are two different sets of new contributors 1. short-term: 
> outreach, intern or so 2. Long-term. I am talking about the 2nd
> one here as 1st one is anyways going after a short time and it is the 
> same for them to learn Gerrit or GitHub. 
> Long-term new contributors are someone we need to think that our 
> process/tooling are ok for them to sustain as
> long term or it is too complex/split to work. For example: "Hey, my 
> company is asking me to be a new long-term
> maintainer in OpenStack but I deny it because OpenStack uses more than 
> one set of tooling to develop the code or run
> the tests". In this example, before saying more than one tooling will 
> be difficult for new contributors we should answer
> two very practical questions:
>
> 1. How many of such new contributors do we have in OpenStack
> 2. If there is, do they need to learn two processes? I think they will 
> be contributing to a single project following a single
> process/tool. If we get some super contributor to all projects then it 
> is a different thing.
>
> And practical data is "we do not get new contributors helping us with 
> help needed things", Below points can justify it:
>
> 1. no help on our help needed (upstream investment opportunity) list 
> "because of fewer contributors". 
> 2. Many projects get retired in every cycle "because of fewer 
> contributors".
> 3. OpenStack Infra (OpenDev) is shrinking, many services are shutting 
> down "because of fewer contributors".
> 4. OpenStack Community is not able to finish user-facing features like 
> RBAC, OSC on time "because of fewer contributors". 
> 5. Most of our existing contributors are overloaded and slowly burnout 
> "because of fewer contributors". OpenDev maintainer
> overloaded is a good example. 
> 6. OpenStack supporting teams like QA, infra, requirement, stable 
> branch, and releases do not have enough maintainers
> that they require.
>
> I am saying what strategy or program will work to fix these but in the 
> current situation, we have to accept that these are
> problems because we do not get new contributors. If we cannot fix them 
> then we have to adjust ourself as per current
> situation even change the things which previously agreed or worked.  
>
> I am starting another discussion here to fix this new contributor 
> problem in this thread but I am saying that considering the
> new contributors criteria in this email thread context and not changing 
> the things is not relevant, 
>

While you didn't want to start a new conversation on this topic, I do think it is worthwhile to consider why we think this might help anything if that is the argument being made to justify these potential actions.

I think there are two main angles to look at this.

The first is does this reduce the burden on us? Potentially if you replaced self hosted services with services hosted by others that could be the case. This isn't risk free (think what happened with transifex or docker hub), but the risk may be worth the return. As mentioned elsewhere in the thread if we want to continue to uphold our community values it would be better to consider hosted open source options instead. You also have to accept the limitations of whatever the new platform is, because if you start doing a bunch of custom work around it you're back where you started and haven't reduced much burden.

The other is whether or not we're likely to infuse new blood by making a change. This is where things get a lot more murky for me. I don't think it is universally true that choosing to use github is going to magically create new contributors. You only have to look at gnocchi to see a historical example of this. Our projects need maintainers. Maintenance of software requires some non trivial involvement. You might get a few more drive by contributions, but that will only help the projects grow long term if you can convert some subset to maintainers. This is difficult. This is difficult regardless of the platform you choose to develop on.

I think that if the goal is attracting new contributors we should be explicit about why the actions we are taking are believed to help with that not just simply assert that it is the case.

Also, adding a new project like gophercloud won't automatically add contributors to openstack. Contributors to gophercloud will continue to be contributors to gophercloud. In fact you point out above it is unlikely they will contribute to other projects. For this reason I think it is also worthwhile to think about what benefits of such a change exist. Does openstack benefit in any way by adding gophercloud to openstack but not changing anything about their contribution methods? Does gophercloud benefit in any way? To me this is essentially the status quo only with new additional governance overhead.