Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On Tue, 16 Feb 2016, Doug Hellmann wrote: [lots of reassonable stuff snipped] I think we should be looking for ways to say "yes" to new projects, rather than "no." I think the opposite is worth thinking about. Maybe we should be defaulting to "no". Not because candidates are bad, but because unconstrained growth is. OpenStack is already big enough and resources are limited. Maybe we should only add stuff that explicitly adds value to OpenStack. For the example of Poppy, there is nothing that requires it be a part of OpenStack for it to be useful to OpenStack nor for it to exist as a valuable part of the open source world. -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
Excerpts from Chris Dent's message of 2016-02-16 19:47:11 +: > On Tue, 16 Feb 2016, Doug Hellmann wrote: > > [lots of reassonable stuff snipped] > > > I think we should be looking for > > ways to say "yes" to new projects, rather than "no." > > I think the opposite is worth thinking about. Maybe we should be > defaulting to "no". Not because candidates are bad, but because > unconstrained growth is. OpenStack is already big enough and resources > are limited. Maybe we should only add stuff that explicitly adds value > to OpenStack. If we want to do that, we should change the rules because we put the current set of rules in place specifically to encourage more project teams to join officially. We can do that, but that discussion deserves its own thread. > > For the example of Poppy, there is nothing that requires it be a part > of OpenStack for it to be useful to OpenStack nor for it to exist as > a valuable part of the open source world. Nor is there for lots of our existing official projects. Which ones should we remove? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On Tue, 16 Feb 2016, Doug Hellmann wrote: If we want to do that, we should change the rules because we put the current set of rules in place specifically to encourage more project teams to join officially. We can do that, but that discussion deserves its own thread. (Yeah, that's why I changed the subject header: Indicate change of subject, but maintain references.) I'm not sure what the right thing to do is, but I do think there's a good opportunity to review what various initiatives (big tent, death to stackforge, tags, governance changes, cross-project work) are trying to accomplish, whether they are succeeding, what the unintended consequences have been. For the example of Poppy, there is nothing that requires it be a part of OpenStack for it to be useful to OpenStack nor for it to exist as a valuable part of the open source world. Nor is there for lots of our existing official projects. Which ones should we remove? The heartless rationalist in me says "most of them". The nicer guy says "this set is grandfathered, henceforth we're more strict". A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that and it is hard to experience positive progress in a fog. Many people react to this fog by focusing on their specific project rather than OpenStack at large: At least there they can see their impact. This results in increasing the fog because cross-project concerns (which help unify the vision and actuality that is OpenStack) get less attention and the cycle deepens. [1] Other people, some reasonable, some not, will have different opinions. Yay! -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > On Tue, 16 Feb 2016, Doug Hellmann wrote: > > > If we want to do that, we should change the rules because we put > > the current set of rules in place specifically to encourage more > > project teams to join officially. We can do that, but that discussion > > deserves its own thread. > > (Yeah, that's why I changed the subject header: Indicate change of > subject, but maintain references.) Ah, my mailer continued to thread it together with the other messages. > I'm not sure what the right thing to do is, but I do think there's a > good opportunity to review what various initiatives (big tent, death > to stackforge, tags, governance changes, cross-project work) are trying > to accomplish, whether they are succeeding, what the unintended > consequences have been. > > >> For the example of Poppy, there is nothing that requires it be a part > >> of OpenStack for it to be useful to OpenStack nor for it to exist as > >> a valuable part of the open source world. > > > > Nor is there for lots of our existing official projects. Which ones > > should we remove? > > The heartless rationalist in me says "most of them". The nicer guy > says "this set is grandfathered, henceforth we're more strict". Right. Poppy has been around longer than some of those, so it hardly seems fair to them to do that. > A reason _I_[1] think we need to limit things is because from the > outside OpenStack doesn't really look like anything that you can put > a short description on. It's more murky than that and it is hard to > experience positive progress in a fog. Many people react to this fog > by focusing on their specific project rather than OpenStack at > large: At least there they can see their impact. I've never understood this argument. OpenStack is a community creating a collection of tools for building clouds. Each part implements a different set of features, and you only need the parts for the features you want. In that respect, it's no different from a Linux distro. You need a few core pieces (kernel, init, etc.), and you install the other parts based on your use case (hardware drivers, $SHELL, $GUI, etc.). Are people confused about what OpenStack is because they're looking for a single turn-key system from a vendor? Because they don't know what features they want/need? Or are we just doing a bad job of communicating the product vs. kit nature of the project? > This results in increasing the fog because cross-project concerns (which > help unify the vision and actuality that is OpenStack) get less > attention and the cycle deepens. I'm not sure cross-project issues are really any worse today than when I started working on OpenStack a few years ago. In fact, I think they're significantly better. At the time, there were only the integrated projects and no real notion that we would add a lot of new ones. We still had a hard time recruiting folks to participate in release management, docs, Oslo, infra, etc. The larger community and liaison system has improved the situation. There's more work, because there are more projects, but by restructuring the relationship of the vertical and horizontal teams to require project teams to participate explicitly we've reduced some of the pressure on the teams doing the coordination. Architecturally and technically, project teams have always wanted to go their own way to some degree. Experimentation with different approaches and tools to address similar problems like that is good, and success has resulted in the adoption of more common tools like third-party WSGI frameworks, test tools, and patterns like the specs review process and multiple teams managing non-client libraries. So on a technical front we're doing better than the days where we all just copied code out of nova and modified it for our own purposes without looking back. We also have several new cross-project "policy" initiatives like the API working group, the new naming standards thing, and cross-project spec liaisons. These teams are a new, more structured way to collaborate to solve some of the issues we dealt with in the early days through force of personality, or by leaving it up to whoever was doing the implementation. All of those efforts are seeing more success because people showed up to collaborate and reach consensus, and stuck through the hard parts of actually documenting the decision and then doing the work agreed to. Again, we could always use more help, but I see the trend as improving. We've had to change our approaches to dealing with the growth, and we still have a ways to go (much of it uphill), but I'm not prepared to say that we've failed to meet the challenge. Doug > > [1] Other people, some reasonable, some not, will have different > opinions. Yay! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.ope
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that and it is hard to experience positive progress in a fog. Many people react to this fog by focusing on their specific project rather than OpenStack at large: At least there they can see their impact. I've never understood this argument. OpenStack is a community creating a collection of tools for building clouds. Each part implements a different set of features, and you only need the parts for the features you want. In that respect, it's no different from a Linux distro. You need a few core pieces (kernel, init, etc.), and you install the other parts based on your use case (hardware drivers, $SHELL, $GUI, etc.). Ah. I think this gets to the heart of the matter. "OpenStack is a [...] collection of tools for building clouds" is not really how I think about it, so perhaps that's where I experience a problem. I wonder how many people feel the way you do and how many people feel more like I do, which is: I want OpenStack to be a thing that I, as an individual without the help of a "vendor", can use to deploy a cloud (that is easy for me and my colleagues to use) if I happen to have >1 (or even just 1) pieces of baremetal lying around. It's that "vendor" part that is the rub and to me starts bringing us back into the spirit of "open core" that started the original thread. If I need a _vendor_ to make use of the main features of OpenStack then good golly that makes me want to cry, and want to fix it. To fix it, you're right, it does need a greater sense of "product" "instead" of kit and the injection of opinions about reasonable defaults and expectations of some reasonable degree of sameness between different deployments of OpenStack. This is, in fact, what much of the cross-project work that is happening now is trying to accomplish. This results in increasing the fog because cross-project concerns (which help unify the vision and actuality that is OpenStack) get less attention and the cycle deepens. I'm not sure cross-project issues are really any worse today than when I started working on OpenStack a few years ago. In fact, I think they're significantly better. I agree it is much better but it can be better still with some reasonable sense of us all working in a similar direction. The addition of "users" to the mission is helpful. Architecturally and technically, project teams have always wanted to go their own way to some degree. Experimentation with different approaches and tools to address similar problems like that is good, and success has resulted in the adoption of more common tools like third-party WSGI frameworks, test tools, and patterns like the specs review process and multiple teams managing non-client libraries. So on a technical front we're doing better than the days where we all just copied code out of nova and modified it for our own purposes without looking back. History is always full of weird stuff. We've had to change our approaches to dealing with the growth, and we still have a ways to go (much of it uphill), but I'm not prepared to say that we've failed to meet the challenge. I fear that I gave you the wrong impression. I wasn't trying to imply that we are doing poorly at cross project things, rather that if we had fewer projects we could do even better at cross project things (as a result of fewer combinations). Also that growth should not be considered a good thing in and of itself. -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
Excerpts from Chris Dent's message of 2016-02-17 17:00:00 +: > On Wed, 17 Feb 2016, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like anything that you can put > >> a short description on. It's more murky than that and it is hard to > >> experience positive progress in a fog. Many people react to this fog > >> by focusing on their specific project rather than OpenStack at > >> large: At least there they can see their impact. > > > > I've never understood this argument. OpenStack is a community > > creating a collection of tools for building clouds. Each part > > implements a different set of features, and you only need the parts > > for the features you want. In that respect, it's no different from > > a Linux distro. You need a few core pieces (kernel, init, etc.), > > and you install the other parts based on your use case (hardware > > drivers, $SHELL, $GUI, etc.). > > Ah. I think this gets to the heart of the matter. "OpenStack is a > [...] collection of tools for building clouds" is not really how I > think about it, so perhaps that's where I experience a problem. I > wonder how many people feel the way you do and how many people feel > more like I do, which is: I want OpenStack to be a thing that I, as > an individual without the help of a "vendor", can use to deploy a > cloud (that is easy for me and my colleagues to use) if I happen to > have >1 (or even just 1) pieces of baremetal lying around. > > It's that "vendor" part that is the rub and to me starts bringing us > back into the spirit of "open core" that started the original > thread. If I need a _vendor_ to make use of the main features of > OpenStack then good golly that makes me want to cry, and want to fix > it. > > To fix it, you're right, it does need a greater sense of "product" > "instead" of kit and the injection of opinions about reasonable > defaults and expectations of some reasonable degree of sameness > between different deployments of OpenStack. This is, in fact, what > much of the cross-project work that is happening now is trying to > accomplish. You don't need a vendor to use OpenStack. The community has deployment stories for, I think, every possible automation framework. Packages are available for distros that don't have license fees. It is entirely possible to deploy a cloud using these tools. The challenge with deployment is that everyone wants to make their own choices about the cloud they're building. If we were going to give everyone the same sort of cloud, all of OpenStack would be a lot simpler and no one would want to use it because it wouldn't meet their needs. If some of the existing installation mechanisms don't meet simplicity requirements, we should figure out why, specifically. It's quite likely there's room for a "fewer choices needed" deployment tool that expresses more opinions than the existing tools, and is useful for some simpler cases by removing some of the flexibility. > > >> This results in increasing the fog because cross-project concerns (which > >> help unify the vision and actuality that is OpenStack) get less > >> attention and the cycle deepens. > > > > I'm not sure cross-project issues are really any worse today than > > when I started working on OpenStack a few years ago. In fact, I think > > they're significantly better. > > I agree it is much better but it can be better still with some > reasonable sense of us all working in a similar direction. The > addition of "users" to the mission is helpful. > > > Architecturally and technically, project teams have always wanted > > to go their own way to some degree. Experimentation with different > > approaches and tools to address similar problems like that is good, > > and success has resulted in the adoption of more common tools like > > third-party WSGI frameworks, test tools, and patterns like the specs > > review process and multiple teams managing non-client libraries. > > So on a technical front we're doing better than the days where we > > all just copied code out of nova and modified it for our own purposes > > without looking back. > > History is always full of weird stuff. > > > We've had to change our approaches to dealing with the growth, > > and we still have a ways to go (much of it uphill), but I'm not > > prepared to say that we've failed to meet the challenge. > > I fear that I gave you the wrong impression. I wasn't trying to imply > that we are doing poorly at cross project things, rather that if we had > fewer projects we could do even better at cross project things (as a > result of fewer combinations). OK. Speaking as someone heavily involved in "cross project things" when we had only a very few projects, I can report that at that time we did not do as well at cooperation even as we are doing today. That's not to say you're wrong about the future, sin
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
To use the parallel of the Linux OS again, what Linux user doesn't use a vendor (distro) to deploy their machine? Sure, you can linux from scratch it, but who does but for education/entertainment purposes? Yes, its important to be able to do it without a vendor. The same way its important to be able to do linux from scratch without a vendor. But "easy" is not a requirement to be open. Easy thought would be nice. Just saying it isn't a requirement. Flexibility in Open Source has often trumped ease. :) Thanks, Kevin From: Doug Hellmann [d...@doughellmann.com] Sent: Wednesday, February 17, 2016 9:36 AM To: openstack-dev Subject: Re: [openstack-dev] [all] [tc] unconstrained growth, why? Excerpts from Chris Dent's message of 2016-02-17 17:00:00 +: > On Wed, 17 Feb 2016, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like anything that you can put > >> a short description on. It's more murky than that and it is hard to > >> experience positive progress in a fog. Many people react to this fog > >> by focusing on their specific project rather than OpenStack at > >> large: At least there they can see their impact. > > > > I've never understood this argument. OpenStack is a community > > creating a collection of tools for building clouds. Each part > > implements a different set of features, and you only need the parts > > for the features you want. In that respect, it's no different from > > a Linux distro. You need a few core pieces (kernel, init, etc.), > > and you install the other parts based on your use case (hardware > > drivers, $SHELL, $GUI, etc.). > > Ah. I think this gets to the heart of the matter. "OpenStack is a > [...] collection of tools for building clouds" is not really how I > think about it, so perhaps that's where I experience a problem. I > wonder how many people feel the way you do and how many people feel > more like I do, which is: I want OpenStack to be a thing that I, as > an individual without the help of a "vendor", can use to deploy a > cloud (that is easy for me and my colleagues to use) if I happen to > have >1 (or even just 1) pieces of baremetal lying around. > > It's that "vendor" part that is the rub and to me starts bringing us > back into the spirit of "open core" that started the original > thread. If I need a _vendor_ to make use of the main features of > OpenStack then good golly that makes me want to cry, and want to fix > it. > > To fix it, you're right, it does need a greater sense of "product" > "instead" of kit and the injection of opinions about reasonable > defaults and expectations of some reasonable degree of sameness > between different deployments of OpenStack. This is, in fact, what > much of the cross-project work that is happening now is trying to > accomplish. You don't need a vendor to use OpenStack. The community has deployment stories for, I think, every possible automation framework. Packages are available for distros that don't have license fees. It is entirely possible to deploy a cloud using these tools. The challenge with deployment is that everyone wants to make their own choices about the cloud they're building. If we were going to give everyone the same sort of cloud, all of OpenStack would be a lot simpler and no one would want to use it because it wouldn't meet their needs. If some of the existing installation mechanisms don't meet simplicity requirements, we should figure out why, specifically. It's quite likely there's room for a "fewer choices needed" deployment tool that expresses more opinions than the existing tools, and is useful for some simpler cases by removing some of the flexibility. > > >> This results in increasing the fog because cross-project concerns (which > >> help unify the vision and actuality that is OpenStack) get less > >> attention and the cycle deepens. > > > > I'm not sure cross-project issues are really any worse today than > > when I started working on OpenStack a few years ago. In fact, I think > > they're significantly better. > > I agree it is much better but it can be better still with some > reasonable sense of us all working in a similar direction. The > addition of "users" to the mission is helpful. > > > Architecturally and technically, project teams have always wanted > > to go their own way to some degree. Experimentation with different > > appro
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On 02/17/2016 09:28 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that and it is hard to experience positive progress in a fog. Many people react to this fog by focusing on their specific project rather than OpenStack at large: At least there they can see their impact. I've never understood this argument. OpenStack is a community creating a collection of tools for building clouds. Each part implements a different set of features, and you only need the parts for the features you want. In that respect, it's no different from a Linux distro. You need a few core pieces (kernel, init, etc.), and you install the other parts based on your use case (hardware drivers, $SHELL, $GUI, etc.). Yes. This. Are people confused about what OpenStack is because they're looking for a single turn-key system from a vendor? Because they don't know what features they want/need? Or are we just doing a bad job of communicating the product vs. kit nature of the project? I think we are doing a bad job of communicating the product vs. kit nature of OpenStack. This results in increasing the fog because cross-project concerns (which help unify the vision and actuality that is OpenStack) get less attention and the cycle deepens. I'm not sure cross-project issues are really any worse today than when I started working on OpenStack a few years ago. In fact, I think they're significantly better. At the time, there were only the integrated projects and no real notion that we would add a lot of new ones. We still had a hard time recruiting folks to participate in release management, docs, Oslo, infra, etc. The larger community and liaison system has improved the situation. There's more work, because there are more projects, but by restructuring the relationship of the vertical and horizontal teams to require project teams to participate explicitly we've reduced some of the pressure on the teams doing the coordination. Architecturally and technically, project teams have always wanted to go their own way to some degree. Experimentation with different approaches and tools to address similar problems like that is good, and success has resulted in the adoption of more common tools like third-party WSGI frameworks, test tools, and patterns like the specs review process and multiple teams managing non-client libraries. So on a technical front we're doing better than the days where we all just copied code out of nova and modified it for our own purposes without looking back. We also have several new cross-project "policy" initiatives like the API working group, the new naming standards thing, and cross-project spec liaisons. These teams are a new, more structured way to collaborate to solve some of the issues we dealt with in the early days through force of personality, or by leaving it up to whoever was doing the implementation. All of those efforts are seeing more success because people showed up to collaborate and reach consensus, and stuck through the hard parts of actually documenting the decision and then doing the work agreed to. Again, we could always use more help, but I see the trend as improving. We've had to change our approaches to dealing with the growth, and we still have a ways to go (much of it uphill), but I'm not prepared to say that we've failed to meet the challenge. Agreed on your points above, Doug. -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: > On 02/17/2016 09:28 AM, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like anything that you can put > >> a short description on. It's more murky than that and it is hard to > >> experience positive progress in a fog. Many people react to this fog > >> by focusing on their specific project rather than OpenStack at > >> large: At least there they can see their impact. > > > > I've never understood this argument. OpenStack is a community > > creating a collection of tools for building clouds. Each part > > implements a different set of features, and you only need the parts > > for the features you want. In that respect, it's no different from > > a Linux distro. You need a few core pieces (kernel, init, etc.), > > and you install the other parts based on your use case (hardware > > drivers, $SHELL, $GUI, etc.). > > Yes. This. > > > Are people confused about what OpenStack is because they're looking > > for a single turn-key system from a vendor? Because they don't know > > what features they want/need? Or are we just doing a bad job of > > communicating the product vs. kit nature of the project? > > I think we are doing a bad job of communicating the product vs. kit > nature of OpenStack. Yeah, I tend to think that's it, too. > > >> This results in increasing the fog because cross-project concerns (which > >> help unify the vision and actuality that is OpenStack) get less > >> attention and the cycle deepens. > > > > I'm not sure cross-project issues are really any worse today than > > when I started working on OpenStack a few years ago. In fact, I think > > they're significantly better. > > > > At the time, there were only the integrated projects and no real > > notion that we would add a lot of new ones. We still had a hard > > time recruiting folks to participate in release management, docs, > > Oslo, infra, etc. The larger community and liaison system has > > improved the situation. There's more work, because there are more > > projects, but by restructuring the relationship of the vertical and > > horizontal teams to require project teams to participate explicitly > > we've reduced some of the pressure on the teams doing the coordination. > > > > Architecturally and technically, project teams have always wanted > > to go their own way to some degree. Experimentation with different > > approaches and tools to address similar problems like that is good, > > and success has resulted in the adoption of more common tools like > > third-party WSGI frameworks, test tools, and patterns like the specs > > review process and multiple teams managing non-client libraries. > > So on a technical front we're doing better than the days where we > > all just copied code out of nova and modified it for our own purposes > > without looking back. > > > > We also have several new cross-project "policy" initiatives like > > the API working group, the new naming standards thing, and cross-project > > spec liaisons. These teams are a new, more structured way to > > collaborate to solve some of the issues we dealt with in the early > > days through force of personality, or by leaving it up to whoever > > was doing the implementation. All of those efforts are seeing more > > success because people showed up to collaborate and reach consensus, > > and stuck through the hard parts of actually documenting the decision > > and then doing the work agreed to. Again, we could always use more > > help, but I see the trend as improving. > > > > We've had to change our approaches to dealing with the growth, > > and we still have a ways to go (much of it uphill), but I'm not > > prepared to say that we've failed to meet the challenge. > > Agreed on your points above, Doug. > > -jay > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: I think we are doing a bad job of communicating the product vs. kit nature of OpenStack. Yeah, I tend to think that's it, too. I'll concede to that and agree we can and should do better. If it's "kit" not "product" I think the newly proposed[1] mission statement doesn't convey the right message, to me: To produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds. The ambiguity is in "platform" which I would read as "a thing I can use to do some stuff" not "bits I need to put together first before I can do some stuff". I might be coming at this from a non-enterprise standpoint (with regard to "platform"). I realize I'm being annoyingly pedantic here, but it seems while we're on the topic and have identified a problem we may as well beat it to death...If people aren't into doing so, that's cool, I mean these comments merely as observations, with good intent and in good humor. [1] https://review.openstack.org/#/c/281463/ -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] unconstrained growth, why?
On Wed, 2016-02-17 at 13:25 -0500, Jay Pipes wrote: > On 02/17/2016 09:28 AM, Doug Hellmann wrote: > > Are people confused about what OpenStack is because they're looking > > for a single turn-key system from a vendor? Because they don't know > > what features they want/need? Or are we just doing a bad job of > > communicating the product vs. kit nature of the project? > > I think we are doing a bad job of communicating the product vs. kit > nature of OpenStack. I think that might because OpenStack is both an upstream and effectively a distribution (which you're attempting to control via trademarks and defcore). What you're seeing is natural schizophrenia because it's really hard to think of upstream and distribution at the same time (upstream tends to think of pure implementations and distros tend to think about what their specific customers need and problems). I'm not saying don't do this ... effectively Mozilla does this as well, but it is the source of the confusion, I think. James __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
