[tc] [election] Candidate question: growth of projects
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
* More projects as required by demand. * Slower or no growth to focus on what we've got. * Trim the number of projects to "get back to our roots". * Something else.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914.... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
Hola,
Thanks for this question.
On Thu, Feb 21, 2019 at 12:19 PM Chris Dent cdent+os@anticdent.org wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
IMHO, the size is never a problem. The real question is rather about whether all of them are going to the same direction (and I'm trying hard to not make a parallel with geopolitics). Oh, I'm not saying we don't have problems with 63 teams, right? At least, having this number of teams is a bit difficult because it's more difficult to know about all of them but just a small number (say 12) It also means that it's somehow difficult to work on the same page of course.
So, what to do with those problems ? Maybe the TC should be more governing this list, by at least making sure that all projects run at the same page. We have a maintenance tag. It's a very difficult tag to assign, right? Maybe it's time for us to be discussing about what it means for a project to be 'maintained'.
If you had to make a single declaration about growth in the number
of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
My statement would be "focus on the existing projects, define a common set of attributes that would necessarly be more strict than today and see if and how all the current projects can fill the gaps for all of them". Somehow tied to the 2nd proposal you make, but not by principe, just pragmatism in order to help our users to have a decent experience. That said, I'm not opposed to accepting new candidates if those are able to cope with all the necessary tasks. We had an incubation process early in OpenStack, that could be an idea for those new projects to get approved.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Not really. I don't see this as a threat for OpenStack and I think it's good for the Foundation to evolve. But it will come with challenges, the first being the integration process with the approval checklist. The only problem I see is that while granting a project is easy, calling the cut is very hard. The more we are clear on the requirements, the less we could be disappointed in the future.
Do you think the number of projects has any impact (positive or
negative) on our overall ability to get things done?
I'll restate here what I already said in another thread : I just don't think the TC role is about to drive architectural designs. Getting the shXt done is the matter of projects and individuals that are able to get some time for this. What the TC is good at is to make those projects and contributors to communicate. We're far away from a BDFL model where a couple of people decide for all the community. If we really want to have things done, just make people discussing and act as a mediator.
Recognizing that there are many types of contributors, not just
developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
Good question. I don't think that people claiming to be "Project X developer" misconsider other projects, so it's not really a qualitative aspect. It's more the fact that most of the day-to-day work is made within a single project, so most of the social traction is made there. Also, I don't think forcing developers to consider themselves "OpenStack developers" will change anything. We should rather ask ourselves "How can we make the larger community of developers to share the same vision and pace ?".
-Sylvain
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914.... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 21/02/2019 11:13, Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
I don't think the number of projects is an issue - I think that the key point is "does this project help OpenStack fufil its mission".
That should be judged on several criteria:
1. Usefulness for OpenStack Users / Operators / Developers? 2. Is it "OpenStack-y" - does it follow our normal models? 3. Is the team engaged with the rest of the community? 4. Is the project maintained to suitible standard that we think it is something that can be used?
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- Something else.
I have no preference on number of projects - as long as they meet the above list.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
I think we are still too early for us to see what (if any impact) this will have on the OpenStack sub-projects. I do think that Open Infrastructure Projects (OIPs) will end up a lot smaller that OpenStack, and this may encourage teams to split out like Zuul has.
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Yes - the more projects we have, the harder it is to make large community wide changes, like API References, quota standardisation, or healthchecking. But, this cost has to be wieghed against what a project brings to the project.
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
We should encourage people to think outside of their traditional "team", but we should also recognise that a lot of our contributors are paid to work on a specific segment. In some of those segments, keeping context for just that project is hard enough, and trying to get people to learn about the layout and structure of another project can be a large ask.
We do need more "OpenStack Developers", who help drive larger community efforts, but we do need to understand that not all people can step into that role (for many reasons).
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914....
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
Well hello again!
As always, inline below:
On 21/02/2019 11:13, Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
I think it's safe for me to say that isn't a single person in our entire community that could honestly say they know what all those 63 projects are and how they function. We are all specialists in our own right and that's how our community works together.
I do not believe it is my place to determine via a standalone number if our project list is too big, too small, or just right. I could very easily say that we only require "the main 5 projects" for OpenStack to work, but part of the beauty of OpenStack as an open source product is we allow freedom of development (within technical guidelines, as discussed) and that is one of the things that draws developments and their projects to integrate and grow with OpenStack.
That also being said, there has been duplication of efforts in certain areas. Projects that are eerily similar, yet not working together. I think these are areas that we could potentially be reviewing, in the sense of encouraging teams to collaborate more.
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
My answer is: Something else (ha, what a surprise).
I think all those options are applicable. If there is room and movement for growth, we should be encouraging of that. If there is a slow down, we should not be pushing the community to grow when it clearly is stablising. I believe we should always be looking at ways to trim - if you do not cut back, there is no room for improvement. If a stable, yet unattended project is left to expire on its own does not open up for new change and new ownership. We've seen this happen before.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
The OIP has mostly changed the way I think about your questions in the sense that it isn't just "us" anymore. And we need to be looking more towards future development. We needn't have such a focus on OpenStack projects alone but where the revised community is going and how we're going to get there. As I said in my email to Doug: Don't fix what's broken, let's move forward and focus on that.
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
I'd be lying if I didn't say: Sometimes. I think ensuring you are considering the needs and wants of 63 projects is an enormous task. And often that means what could be a cut and dry is not because you need to ensure you're considering every angle.
But, this isn't necessarily a bad thing.
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
To reiterate my first answer to your question: There is not one person who understands the intimidate details of every OpenStack project. While I encourage anyone to identify as an OpenStack developer, I can see why someone would prefer to refer to themselves as a Nova developer on the OpenStack product. Being an OpenStack developer can often imply that you know everything about the entire ecosystem - which I believe many to have very in-depth knowledge on several projects, but not the entire product.
That being said, there are those that are core contributors on several projects and identifying as an OpenStack developer is an easier course than saying they are core developers on Keystone, Glance, Cinder and the Potato project (so be it).
While you address this question to developers and recognise that there are many different types of contributors, I think documentation sits in a weird loop hole here. We are often considered developers because we follow developmental workflows, and integrate with the projects directly. Some of us are more technical than others and contribute to both the code base and to the physical documentation. Risking a straw man here: How would you define the technical writers that work for OpenStack? We too are often considered "OpenStack" writers and experts, yet as I say, we are not experts on every project.
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914.... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
Looking forward to your response to my question :)
On Thu, 21 Feb 2019, Alexandra Settle wrote:
Well hello again!
Hello!
While you address this question to developers and recognise that there are many different types of contributors, I think documentation sits in a weird loop hole here. We are often considered developers because we follow developmental workflows, and integrate with the projects directly. Some of us are more technical than others and contribute to both the code base and to the physical documentation. Risking a straw man here: How would you define the technical writers that work for OpenStack? We too are often considered "OpenStack" writers and experts, yet as I say, we are not experts on every project.
I'd hesitate to define anyone. Technical writers, developers, users, deployers and all the other terms we can come up with for people who are involved in the OpenStack community are all individuals and do things that overlap in many roles.
I was reluctant to use the term developer in my original question because it's not a term I like because it is so frequently used to designate a priesthood which has special powers (and rewards and obligations) different from a (lesser) laity. Which is crap. Not as crap as "software engineer" but still crap.
But I used it to try to forestall any "who do you mean" and "who does the TC represent" questions, which, upon reflection, might have been good questions to debate.
Technical writers, and developers, and everyone else who is involved in the OpenStack community are co-authors of this thing which we call OpenStack. From my standpoint the thing we are authoring, and hope to keep alive, is the community and the style of collaboration we use in it. The thing that people run clouds with and companies sell is sort of secondary, but is the source of value that will keep people wanting the community to exist.
The thing people who are active in the community and want be "leaders" should be doing is focusing on ensuring that we create and maintain the systems that allow people to contribute in a way that sustains the style of collaboration, respects their persons and their labor, and (critically, an area where I think we are doing far too little) makes sure that the people who profit off that labor attend to their responsibilities.
We have to, however, make sure that the source of value is good. Different people are interested in or have aptitudes for different things (e.g., writing code or writing about what code does); enabling those people to contribute to the best of their abilities and in an equitable fashion makes the community and the product better.
On 25/02/2019 11:24, Chris Dent wrote:
On Thu, 21 Feb 2019, Alexandra Settle wrote:
Well hello again!
Hello!
Hello!
I'm going for hello-inception. Unsure if it will catch on or not.
While you address this question to developers and recognise that there are many different types of contributors, I think documentation sits in a weird loop hole here. We are often considered developers because we follow developmental workflows, and integrate with the projects directly. Some of us are more technical than others and contribute to both the code base and to the physical documentation. Risking a straw man here: How would you define the technical writers that work for OpenStack? We too are often considered "OpenStack" writers and experts, yet as I say, we are not experts on every project.
I'd hesitate to define anyone. Technical writers, developers, users, deployers and all the other terms we can come up with for people who are involved in the OpenStack community are all individuals and do things that overlap in many roles.
+1
I was reluctant to use the term developer in my original question because it's not a term I like because it is so frequently used to designate a priesthood which has special powers (and rewards and obligations) different from a (lesser) laity. Which is crap. Not as crap as "software engineer" but still crap.
I actually laughed at this, you're quite right. Developers are often still seen as magical beings with strange powers that make the fun screen go bright. There's an air of *mystery* surrounding developers.
But I used it to try to forestall any "who do you mean" and "who does the TC represent" questions, which, upon reflection, might have been good questions to debate. Technical writers, and developers, and everyone else who is involved in the OpenStack community are co-authors of this thing which we call OpenStack. From my standpoint the thing we are authoring, and hope to keep alive, is the community and the style of collaboration we use in it. The thing that people run clouds with and companies sell is sort of secondary, but is the source of value that will keep people wanting the community to exist.
Agreed and thank you. Without sounding like the forgotten bird who sang all summer, it's nice to see it recognised that OpenStack is not just built on code, but it's supporting foundations such as documentation.
But most importantly, that what we're trying to keep alive is actually the community and style of collaboration. Being a boomerang Stacker, I can't even tell you how much I appreciate coming back to a community who is so welcoming, and interested in working on cool new projects.
The thing people who are active in the community and want be "leaders" should be doing is focusing on ensuring that we create and maintain the systems that allow people to contribute in a way that sustains the style of collaboration, respects their persons and their labor, and (critically, an area where I think we are doing far too little) makes sure that the people who profit off that labor attend to their responsibilities.
I don't think I can add anything more to this than a +2. I can't agree enough and I hope to continue to foster and encourage this behaviour on or off the TC.
We have to, however, make sure that the source of value is good. Different people are interested in or have aptitudes for different things (e.g., writing code or writing about what code does); enabling those people to contribute to the best of their abilities and in an equitable fashion makes the community and the product better.
Thanks for responding Chris, I appreciate you taking the time to break this down.
Obviously, the safe answer for these questions is number doesn't matter, we should focus on the core/mission of OpenStack. But as Alex said, not much people can know all of those 63 projects. And given some companies are reducing their investiment on OpenStack, we don't have much resources like before(say 2014-2015). So I do think we need more focus.
On 22/02/19 12:13 AM, Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914.... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
On Thu, Feb 21, 2019 at 6:14 AM Chris Dent cdent+os@anticdent.org wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
I haven't formed a strong opinion on the above, but I'll answer this.
I don't think the number of projects has made a significant impact on our ability to get things done overall. If something is important to a certain amount of users or operators, I believe it will somehow get done eventually (with the caveat that the number of people it is important to scales with the effort required to get it done).
But I do think it makes a negative impact on the ability to keep things consistent. The projects with fewer contributor-hours, so to speak, will have a hard time finding sufficient time to keep up with the large number of things we attempt to make consistent between projects. Between python versions, the PTI, docs structure, rolling upgrades, stable policy, API versioning, API "feel", client consistency, etc.etc.etc., there's a lot to keep up with that seems to change fairly frequently.
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
Yes. Or maybe just anything other than "$project developers". Ideally I like to think that we would organize ourselves more around classes of features or layers of the stack. I'd like to see more "compute node developers", "networking developers", "REST API developers", "quota developers", etc. I think this would allow us to get important things done consistently across a wider number of projects, eventually making OpenStack a more coherent thing.
That said, our culture is so ingrained as-is (both here and inside our supporting employers), that I'm not sure how to make this change. I'd love to talk with others and figure that out.
// jim
Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
I would say it's slightly too big.
It is easy to add a project, it is more difficult to remove one. It is not that much of a problem, because it's not a zero-sum game (removing projects won't magically add resources to the remaining ones). However, sometimes we get people to step up to "save" a project -- they end up working on it mostly by themselves, because "someone has to". In some cases maybe the right call would have been to let that project disappear and apply those resources to ensure long-term sustainability of a more strategic project (think one that everyone else depends on).
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
I'd say a combination of the first 3 :)
We should be able to add new projects as required by demand -- capture the energy where it appears. At the same time, I'd like us to think about cutting dead branches rather than maintaining them forever just because that is what we always did. At one point, if the very few users of that service do not really step up to work on it, maybe we should reconsider heroic maintenance by one-person teams.
[...] Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
I'm a strong believer in the "OpenStack developer" -- I think we are stronger as a coordinated framework than as separately-developed compatible pieces of technology. Conway's law plays against us as we are organized in project teams. I see SIGs and Popup teams as ways to encourage that "OpenStack" thinking.
On Thu, Feb 21, 2019 at 7:14 PM Chris Dent cdent+os@anticdent.org wrote:
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
Too big, because we actually contain some dead projects IMO. We should contain those projects in some place until someone is ready to take over.
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
* Something else. I prefer we thinking about restructuring in long-term. Projects don't make much sense to me now a day. SIGs/WGs to making cross-project development might be a better approach in the feature.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Not really, we could have multiple foundations trying on multiple projects. To have a single Foundation willing to take over the part and evolved to something else is pretty amazing.
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Yes, you need extra time to check with projects. And since we're doing community goal approach, the bigger the number, the more complex the goal will be.
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
To named with Open Infra developer might be even suitable IMO, to allow people to think and plan on a higher level.
Thanks.
[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914....
[2]
http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
-- May The Force of OpenStack Be With You, Rico Lin irc: ricolin
On 21/02/19 6:13 AM, Chris Dent wrote:
This is another set of questions for TC candidates, to look at a different side of things from my first one [1] and somewhat related to the one Doug has asked [2].
As Doug mentions, a continuing role of the TC is to evaluate applicants to be official projects. These questions are about that.
There are 63 teams in the official list of projects. How do you feel about this size? Too big, too small, just right? Why?
I have mixed feelings about this.
On one hand, AWS launched 30+ services at their conference *last year alone*. (For those keeping score, that's more services than OpenStack had in total when people started complaining that OpenStack had too many services and users wouldn't be able to cope with the choice.) I'm sure many of those are pretty half-baked, and some will eventually amount to nothing, but I look at that and can't help but think: that should be us! With the power of open, we can have any developer in the world behind us. We should be able to out-innovate any one company, even a big one. It makes me sad that after 10 years we haven't built the base to make OpenStack attractive as *the* place to do those kinds of things.
On the other hand, many of those services we do have are only lightly maintained. That's not hurting anybody (except perhaps the folks stuck maintaining them), but in many cases we might just be delaying the inevitable. And some of those services are a feature masquerading as a separate service, that operate as a separate team because they couldn't find another way to get code into where they needed it (usually on the compute node) - those might actually be hurting because they paper over problems with how our community works that might better be addressed head-on.
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
I don't think I can pick one. It's all of the above, including the 'Something else'.
How has the relatively recent emergence of the open infrastructure projects that are at the same "level" in the Foundation as OpenStack changed your thoughts on the above questions?
Not much, TBH.
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Not really. People will work on the problems they have. If OpenStack doesn't have a project to solve their problem then they won't work on OpenStack - they're not going to go work on a different OpenStack project instead.
To the extent that the number of projects has forced horizontal teams to adopt more scalable ways of working, it's probably had a positive impact. (e.g. the release management automation tools are great, and I don't know if they'd ever have been written if there were still only 6 projects.)
Recognizing that there are many types of contributors, not just developers, this question is about developers: Throughout history different members of the community have sometimes identified as an "OpenStack developer", sometimes as a project developer (e.g., "Nova developer"). Should we encourage contributors to think of themselves as primarily OpenStack developers? If so, how do we do that? If not, why not?
I think that's to be encouraged. And it's worth noting that in our guiding principles we require community members to put the needs of OpenStack as a whole above those of their individual projects (and both of those above the needs of their employers)[1]. But I also think it's natural for folks to sometimes identify with the stuff they are directly working on. We all wear many hats in this community, and ultimately everyone will have to learn for themselves how best to juggle that.
cheers, Zane.
[1] https://governance.openstack.org/tc/reference/principles.html#openstack-firs...
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002914....
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002923....
On 26 Feb 2019, 22:59 +0700, Zane Bitter zbitter@redhat.com, wrote:
We should be able to out-innovate any one company, even a big one. It makes me sad that after 10 years we haven't built the base to make OpenStack attractive as *the* place to do those kinds of things.
+1
On the other hand, many of those services we do have are only lightly maintained. That's not hurting anybody (except perhaps the folks stuck maintaining them), but in many cases we might just be delaying the inevitable. And some of those services are a feature masquerading as a separate service, that operate as a separate team because they couldn't find another way to get code into where they needed it (usually on the compute node) - those might actually be hurting because they paper over problems with how our community works that might better be addressed head-on.
I think we need to be very careful with the definition of “lightly maintained”. IMHO, the number of patches isn't always a good indicator. I can tell about my project, Mistral. Yes, we haven’t had an impressive number of patches merged in the last 3 months, but mainly because the key contributors (mainly from Nokia, Red Hat, NetCraker and OVH) were focused downstream tasks around it. There were also some internal changes in the companies from which we have contributors and now we’re trying to deal with that and find a new contribution model that would keep moving the project forward. But that all *doesn’t* mean that the project is not needed anywhere. Several huge corporates and lots of smaller companies use it in production successfully. They make money on it. I didn’t want it to sound as a commercial though, I wanted to deliver the message that “lightly maintained” thing can really be subtle.
If you had to make a single declaration about growth in the number of projects would you prefer to see (and why, of course):
- More projects as required by demand.
- Slower or no growth to focus on what we've got.
- Trim the number of projects to "get back to our roots".
- Something else.
Just want to clarify this. What’s our main criteria to make this decision upon? What’s the main pain point that triggers thinking about that? Has the (subjectively) big number of projects made it hard to maintain infrastructure (CI, releases etc.), i.e. it led to technical issues and labor costs? Or it’s just image, or discomfort that not all of these projects are well maintained anymore?
Do you think the number of projects has any impact (positive or negative) on our overall ability to get things done?
Not really. People will work on the problems they have. If OpenStack doesn't have a project to solve their problem then they won't work on OpenStack - they're not going to go work on a different OpenStack project instead.
+1.
Renat Akhmerov @Nokia
participants (10)
-
Alexandra Settle
-
Chris Dent
-
Feilong Wang
-
Graham Hayes
-
Jim Rollenhagen
-
Renat Akhmerov
-
Rico Lin
-
Sylvain Bauza
-
Thierry Carrez
-
Zane Bitter