Open Stack

> On Apr 6, 2020, at 4:16 PM, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
> 
> ---- On Mon, 06 Apr 2020 11:23:10 -0500 Nikolla, Kristi <knikolla at bu.edu> wrote ----
>> Hi Ghanshyam,
>> 
>> Unfortunately, OpenStack is still for the most part corporate in terms of developer resources. It sort of makes sense, it's a cloud platform, and you need a certain scale to justify the costs for learning, adopting and operating. I probably wouldn't be contributing now if my first introduction to OpenStack wasn't as part of my job operating and developing a cloud.
>> 
>> I don't see a clear path to solve that, but I see a few potential ways to help.
>> 
>> 1. Advertising and marketing the viability of specific OpenStack projects as standalone tools. I can see value for someone needing a volume service, and if Cinder: a) fits the requirements b) is easy to deploy and learn (eg., well documented standalone use case and tested) c) brings a minimum set of cruft with it. This might encourage more people to use it and encourage wider adoption of the other OpenStack projects if their experience is a good one, with OpenStack becoming a trusted toolbox.
> 
> +1 on this. If someone seeing OpenStack as all 52 projects together then they will just go way from it. ONAP was one of good example to learn from it in term of modularity on use cases side.
> 
>> 
>> 2. Making sure we invest more time and effort on documentation. Especially with regards to information on getting started, best practices in terms of architecture, configuration and deployment, and of course contributors guides. We're already a very friendly and welcoming community.
> 
> Contributors guide has been improved a lot and Upstream training, mentorship program, FC SIG doing the continuous effort for many years to get new people
> onboard but that only not solving this issue. Do you think we still lack on helping new contributors onboard or something more interesting idea to attract them? 

With regards to non-corporate: You can't really contribute to a project effectively (or even feel the motivation to) if you're not using it or integrating with it in some form. All the documentation in the world is not going to help with that. That's why I think the other 2 points that I mentioned are important.

With regards to corporate developer resources: I guess more outreach to sponsoring companies and being more persuasive. But, I'm not at all versed in the business-y side of things, so I defer to other folks on that one.


> 
>> 
>> 3. Investigating and working on integrating OpenStack much more closely with other cloud tools. We're great for IaaS, but clouds today are not only IaaS and we need to evolve and play nice with everything else that someone might encounter in a datacenter. Mohammed brings a great point about integrating with Kubernetes. All these integrations need to be well documented, including best practices, and part of our testing infrastructure.
>> 
>> To summarize, I would like to see OpenStack scale better. From homelabbers or small businesses who only need a few services, to large datacenters who may be running multiple OpenStacks, multiple Kuberneteses/OpenShifts, monitoring tools, billing systems. This may result in an increase in adoption, which in turn, should result in an increase in contributions.
>> 
>> I can see the above becoming community goals and the TC doing outreach to document the process and help out.
>> 
>> 
>>> On Apr 4, 2020, at 9:09 PM, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>>> 
>>> This topic is a very important and critical area to solve in the OpenStack community.
>>> I personally feel and keep raising this issue wherever I get the opportunity. 
>>> 
>>> To develop or maintain any software, the very first thing we need is to have enough developer resources.
>>> Without enough developers (either open or closed source), none of the software can survive.
>>> 
>>> OpenStack current situation on contributors is not the same as it was few years back. Almost every
>>> project is facing the less contributor issue as compare to requirements and incoming requests. Few
>>> projects already dead or going to be if we do not solve the less contributors issue now.
>>> 
>>> I know, TC is not directly responsible to solve this issue but we should do something or at least find
>>> the way who can solve this.
>>> 
>>> What do you think about what role TC can play to solve this? What platform or entity can be used by TC to
>>> raise this issue? or any new crazy Idea? 
>>> 
>>> 
>>> -gmann