TC Elections October 2014
- 1 TC Elections October 2014
- 2 Officials
- 3 Election System
- 4 Timeline
- 5 Elected Positions
- 6 Electorate
- 7 Candidates
- 8 Results
- 9 Responses to TC Election Questions
- 9.1 Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?
- 9.2 Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission?
- 9.3 Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?
- 9.4 Topic: Rate of Growth: There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?
- 9.5 Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?
- 9.6 Topic: Communication: How would you describe our current state of communication in the OpenStack community?
- 9.7 Topic: Relationship with the Foundation Board: The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?
TC Elections October 2014
- Anita Kuno (anteaya) anteaya at anteaya dot info
- Tristan Cacqueray (tristanC) tristan dot cacqueray at enovance dot com
Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance/TieBreaking.
- October 3 - October 10, 05:59 UTC: Open candidacy for TC positions
- October 10 - October 17: TC elections
Under the rules of the TC charter, we need to renew 6 TC seats for this election. Seats are valid for one-year terms.
- Technical Committee member - 6 positions
The electorate for this election are the Foundation individual members that are also committers for one of the official programs projects over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC).
The electorate is requested to confirm their email address in gerrit, review.openstack.org > Settings > Contact Information > Preferred Email, prior to September 26, 2014 05:59 UTC so that the emailed ballots are mailed to the correct email address.
There is a resolution to the governance repo that all of the electorate is expected to follow: http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140711-election-activities.rst.
Any individual member of the foundation can propose their candidacy (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen). No nomination is required. They do so by sending an email to the email@example.com mailing-list, which the subject: "TC candidacy" by October 10, 05:59 UTC. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate.
- Anne Gentle
- Monty Taylor
- Zane Bitter
- Dean Troyer
- Russell Bryant
- Doug Hellmann
- Adam Lawson
- Eoghan Glynn
- John Garbutt
- Sean Dague
- John Griffith
- David Lyle
Newly elected TC members (6) for a one year term:
- Monty Taylor
- Sean Dague
- Doug Hellmann
- Russell Bryant
- Anne Gentle
- John Griffith
TC Election Questions
In order to help the electorate learn more about the candidates, a template of questions will be posted by September 26, 23:59 UTC on this wikipage for tc candidates to answer in their nomination email. As a way of encouraging voters, the election officials may take responses to the same question in candidate emails and compose a blog post in order to help voters inform themselves. Staying with a format of Question > Answer will facilitate this use of data should it be determined this is possible to do as well as helpful to voters.
These individual topics are selected to give a range of items for the electorate to compare candidates on similar issues. You are welcome to respond to the topic, to answer the question or to not respond. Your choice of response will be identified beside your name when the answers are organized by topic to help the electorate better understand individual candidates. This is the first time we are doing this so choices of where the responses are published might be decided after responses are received. Responses will be published on this wikipage by the electoral officials. Please include your responses in your candidate announcement email in a clearly defined section so the electoral officials can copy/paste with confidence. There is no guarantee your formatting will be preserved.
Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission?
Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission?
Topic: Contributor Motivation How would you characterize the various facets of contributor motivation?
Topic: Rate of Growth There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?
Topic: New Contributor Experience How would you characterize the experience new contributors have currently?
Topic: Communication How would you describe our current state of communication in the OpenStack community?
Topic: Relationship with the Foundation Board The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?
Responses to TC Election Questions
Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?
Russell Bryant To recap, the mission statement is “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.”
“ubiquitous” - I think the part we’re doing great here. OpenStack is growing like crazy and is being used all over the place. The list of supporting companies  is impressive. The number and diversity of our contributors is even more impressive. With that said, we shouldn’t get comfortable. There is a lot more to go.
“public and private clouds” - I think we do a nice job working to support both of these use cases.
“regardless of size”, “massively scalable” - This one probably depends on who you ask. :-) Our scalability depends on the project. In some areas we’re doing great. In all areas, we have more improvements to make. I think our biggest failure here has been how well we communicate what to expect to the rest of the community. Some people expect that they can take every component of the integrated release to large public cloud scale. That isn’t true and we’ve done a poor job of setting expectations here. This is something I’d like to improve on.
“simple to implement” - I think OpenStack is far from simple. It’s also a large scale distributed system that is very incredibly flexible so it can support a large number of different use cases. So, we should set expectations accordingly. However, I still think there is a ton of room for usability improvements.
Doug Hellmann I am amazed by what our community produces. We have some truly exceptional development teams building great software. We regularly add new components to the system, and our feature set is as diverse as the community. Our work is not perfect, but as we continue to refine it based on experience and input from users, we are continually improving the way we work and what we produce.
However, there are recurring themes in the user feedback after every release: We need to make OpenStack easier to operate, easier to use, and easier to debug. We are starting to build cross-project teams to work more directly on some of these areas, and it's important that we give priority to that work and consider usability and scalability as features.
Sean Dague Our mission statement is: "To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable." (http://www.openstack.org/blog/2010/07/introducing-openstack/)
I honestly feel like we're only doing an sort of OK job right now. I think that the current growth of services and they way we implement them (by bringing in a lot of new external dependencies) is not holding true to "being simple to implement". I think that's excluding the use of OpenStack at smaller institutions. If OpenStack is only in the toolchest for large sophisticated institutions, it will not become ubiquitous.
Linux was deployed in production first by small ISPs, entities with only a few employees. If OpenStack can only be deployed by having a very skill integrator come on board, it by definition can't be Ubiquitous.
My feelings around a smaller nucleus/layer/ring/zone/integrated release are largely shaped by my feeling that we're losing the smaller users of OpenStack. And that's something we can fix.
I think we all have a lot of work to do on several fronts: - "simple to implement" and "massively scalable" in particular. But I'm very optimistic that work will get done because we have built a healthy, thriving community to do it.
Adam Lawson *“To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.”*
The whole point of mission statements is merely to identify what we are striving to achieve or accomplish within the organization. With that said, I feel that technical leadership is the first step to accomplishing a technical goal. So to that end, the existence of the TC is a positive first step. But it's just one step or many more to come. Within this particular TC cycle, I'd like to see the TC demonstrate leadership to drive a reduction of lingering technical debt and address API and module standardization. Openstack in its current form has a number of challenges that are affecting our ability to scale and while some of this can be solved organizationally, technical debt and standardization are challenges that will not be easy to resolve and might not even be 100 percent solvable within a single release cycle. But I look forward to how the TC *will* shepherd improvements to both process and the product and help drive the mission. On a side note, "easy to implement" is still just a goal and the engineering requirement to deploy and manage Openstack is still a prohibitive hurdle for many organizations. But we have more than one tool in front of us that will help us to help others who want to use Openstack but .. can't. That's something I'd really like to see change soon.
David Lyle "To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."
I think this is a very broad mission. Breadth is not a problem, but there are a few implications in here. One OpenStack needs to be inclusive, to accomplish ubiquity we need to strive to allow deployers to meet their widely varied needs. So we need to support a large ecosystem. The ecosystem around OpenStack is certainly large, but there is a fairly sharp dichotomy between OpenStack and not OpenStack, recognizing larger parts of the ecosystem is important for ecosystem health. As to public vs private and massively scalable aspects, I think we have room for growth. Running a public cloud on OpenStack requires not insignificant changes, and OpenStack has room for improvement on the scalability front. We need greater feedback from the very large deployers to make sure we meet those scalability needs.
John Garbutt Its a bold mission, and I think it is still the right one.
"serve developers, users, and the entire ecosystem" I think we need to be better at the serving the entire ecosystem.
Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community, we should learn to embrace the diversity, where goals don't quite align. But we still want it to be easy for anyone to join in with any exiting effort people are working on. People invest in competing startups.
On the other side of the coin, its hard for our users to know what combinations of drivers give you are working system, and a system that solves the problems the user wants to solve. Distros and consultants are helping fix that. But I am not sure the Vendors always know what they need to participate in the most useful ways.
We need to better understand what "interoperability" means with this broader scope. But making it easy for people to use multiple different OpenStack implementations is important. Nova API should always behave like Nova API, Cinder API should always behave like Cinder API, etc.
Monty Taylor In case you haven't read it recently:
"to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."
If there is anyone out there who feels we've nailed "simple to implement" I'd love to meet them. I think we've been focusing on all of the other parts - I'd like to see more attention placed on "simple to implement"
Anne Gentle The technical community consists of a huge blend of people now, thank goodness, because the mission is a grand sweeping one for private and public clouds. Plus it has the word ubiquitous in it which makes it even more wide-reaching. We're making clouds for the planet and I feel we're tackling, blocking, clearing, and fighting hard to meet the Mission. We're struggling with the "simple to implement" but we have come a very long way.
Eoghan Glynn In all honesty, I would give us an A+ for effort, but more like a B- for execution. In our excitement and enthusiasm to add shiny new features, we sometimes take our eye off the ball in terms of what's needed to make the lives of our users easier. I'm as guilty of this as anyone else, perhaps even more so. But I think at this stage, it would be of much benefit to our user community if we swung the pendulum somewhat in the other direction, and shifted some focus onto easing the practical challenges of operating our stuff at scale.
Dean Troyer I think the rapid growth in the number of incubated/integrated projects has diluted the TC focus and attention and it has become clear that ignoring the natural strata of OpenStack projects is not working.
John Griffith Just as a refresh: "To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."
So I always find this one a bit challenging to digest to be honest. I think the "ubiquitous" part is coming along and is becoming a reality and I also think that there's a decent balance between public and private clouds and that the relative term "size" could be interpreted as something that's being addressed fairly well thus far.
Those are the good.... now for the not so good; "simple to implement"; I don't think deployment is quite as bad as it's made out to be at times, but it certainly leaves a bit to be desired. One thing that's always bothered me here is that it's always been "left to the distros" to provide their custom deployment tools and we've never been able to even provide a common deployment foundation as a community. I really think that's too bad, you can build the greatest software project there is, but if people can't comprehend all the pieces let alone install and configure it fairly easily it's really not living up to it's potential.
From the perspective of the TC, I'm really not sure what role the TC is playing in the overall mission to be honest. In my opinion the TC has really become mostly a committee relegated to voting on project incubation and proposals for things like project mission statements. It's really not very technical in my opinion and it's also not overly effective either.
In my opinion the TC needs to undergo some changes, it would be great as others mentioned to move away from just voting on incubation motions and mission statements or gap analysis efforts and actually focus more on technical decisions that impact OpenStack as a whole. For example I think it would be great for the TC to take a more active role in really having a deep understanding of how all of the various OpenStack projects are actually coming together, what they're doing that works, what they're doing that's not and perhaps provide some guidance and input as well as technical leadership and direction. I'm certainly not saying they should be an all powerful oversight group, but I do think the focus as it stands currently is wrong.
Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission?
Monty Taylor In case you haven't read it recently:
"The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project."
I think over the last year since we became all-elected, the TC has been doing a better and better job. Historically the TC has been a bit reluctant to own the words "technical leadership" Over the past cycle or two, the TC has consistently been stepping more up to the plate on this topic, and I think that trend needs to continue.
Anne Gentle I feel the TC is supportive of the technical contributors to all the projects that make up OpenStack. We're constantly seeking ways to improve and challenge programs. We began to hold programs accountable for their integration. We pushed the limits of the definition of OpenStack by defining all code that a project maintains as part of OpenStack (defined sections). Yes, it was a defense on the side of our Active Technical Contributor community base, but it was a statement about our ideals - Openness, Transparency, Commonality, Integration, Quality.
I'm not sure that given the current state of OpenStack and the number of projects and proposed projects the TC can be faulted for anything here. The fact is that it's become a full time job to just try and keep up to date on all the constantly changing projects in the ecosystem, not to mention all the newly proposed projects. I do think that it would be helpful if the TC was able to be adjusted and tweaked a bit such that it had a more active engagement in technical direction of the project; say for example driving things like making installation more of a community effort, providing HA options that really work and most of all pushing every project in OpenStack to be responsible for making the upgrade process better. I also think that the TC needs to make some really hard decisions about things; like projects that have been started, approved for incubation but maybe aren't really turning out as was hoped. In my opinion there are a number of projects like Neutron, TripleO and some others that I think we really need to figure out a way to get them to a point where they can graduate and be solid for use or revisit what their current status is. It just doesn't seem right to let the process go on for years in some cases.
I think that there are a number of folks on the TC currently that are in fact driving some of these initiatives pretty well, but I don't see that it's being driven from their roles on the TC but instead it's mostly just a result of a lot of hard work and dedication on their part and the fact that they've stepped up and proven themselves as leaders.
Adam Lawson *"The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project."*
I believe the TC has thus far done a pretty fair job given the team and its charter are both rather new. While the TC has been providing leadership for individual components, I would not characterize the TC today as providing highly visible leadership (necessary for openness and transparency) which I would like to see improved. Much of the TC's work today coalesces around providing a safe harbor for meaningful program integration and ensure challenges are resolved optimally but the TC needs to get better at identifying the good/poorly-defined boundaries of this kind of technical governance model. In other words, the TC needs to get better at being a good TC. The instantiation of a TC is a perfect first step but the pink elephant in the room seems to be around cross-project and architectural guidance; ensuring Openstack as a whole is moving in a direction that doesn't require accommodating things we shouldn't be doing in the first place. The lack of API standardization is a great example of moving in a direction without a big picture context.
Communications that have gone back and forth and debated about the big tent model, layers/cascading, scaling documentation, etc have been visible and the candor of opposing viewpoints have been awesome to follow. But we could really benefit from some structural adjustments so more decisions placed before the team are equally visible, a visible and transparent decision-making process enabling those who use Openstack understand the architectural perspectives shepherding it. Not just the decision that have 100+ replies on the mailing list
"Oversight over all the projects" is an area that I'm anticipating where we have some easy low-hanging fruit. Where we are today with regard to focus is understandable given the number of fires affecting individual programs that cannot be ignored. But we have a big opportunity (there's that word again) to get some traction on the larger architectural decisions that may require more work up front but produce some big wins over the long term. Customers who want to use Openstack have often played the "constant change = unstable" card for good reason; Openstack has a long way to go before it gets to Production-quality for the masses (i.e. without heavy re-development requirements). I believe the TC can and should influence that with better solution-level leadership.
- The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer to Production-capable but really shouldn't be optional. Doing something well shouldn't be optional. In fact, a Production context shouldn't be one option of many despite the prevalence of Openstack PoC and pilots; it should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be Production-worthy otherwise it is NOT good enough. That's ready for attention.
We might not be able to address all of these and some ideas could use a lot more cross-talk, but if elected I would like to champion improving how the TC approaches problems and vets their potential solutions.
John Garbutt TC is clearly aways striving to do better, and trying out new ideas, which is great.
Evolving the concept of the integrated release is clearly key to making the system scale. There seems to have been much friction over the incubation process.
Helping share what has worked well between all the projects, seems key to providing technical leadership at large scale. Thats starting to happen, which is cool.
Should the TC reduce its scope to some small number of projects? I am not sure. Maybe there needs to be a different group setup to deal with the specifics related to that group of projects? Maybe ttx's cross project meeting is already the beginnings of that group?
Zane Bitter (That one is here: https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)
I think the TC is doing a good job at encouraging the OpenStack ideals, but I think the size of the project as a whole has overwhelmed its capacity to provide _active_ technical leadership. We need to build up that capability.
Sean Dague The mission: The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project. (https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)
In the current TC, I'm one of the newest OpenStack community members. I was honestly surprised with how much TC time was spent evaluating new project requests (and this is growing over time). I think the TC mission for providing technical leadership and even understanding issues affecting multiple programs becomes very strained when the scope of that governance includes the whole OpenStack ecosystem. And I think it will limit the TC's effectiveness at having oversight when it is so far removed.
Russell Bryant The TC mission statement can be found in the governance repository . The current version is: “The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project.”
The TC is only two years old. If you look through our history, I think the TC has done a nice job evolving processes and structure as OpenStack has grown. The next evolution of process and structure has been the most dominant area of discussion lately. I am very optimistic that we can resolve those issues.
The ways that we could improve our technical leadership have received a bit less discussion. As OpenStack grows into more and more projects, I feel that leadership around standardization becomes more and more important. I’d like to see the TC bootstrap an effort around APIs to help improve our consistency and overall quality. We are also discussing having a cross-project specs repository. It makes sense for the TC to own this to help provide more structure to development efforts that affect many projects.
David Lyle "The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project."
The technical committee has spent much of the last cycle acting as gate keeper. I would like to see it take a larger role in overall architectural direction in OpenStack. I believe one of the greatest challenges we face is coherency of vision and direction. I think this should be the province of the technical committee to act as an arbitrar and architectural board. I don't hold that overall technical direction is to be dictated by the TC, rather the TC merely helps unify that direction and insures consistency. Obviously this is a herculean task, but I believe OpenStack needs more clearness in direction.
Dean Troyer I think this and the previous question are intertwined at this point and it is time to do a sanity check on where we are and where we want to go. This conversation has started and there is no clear answer yet.
Eoghan Glynn Well, to be honest, if I thought this couldn't be improved, I wouldn't be running for election.
On the one hand, I felt the gap analysis for already-integrated projects was a good and healthy thing, and certainly assisted in focusing resources over Juno on the areas where the TC saw deficiencies.
On the other hand, I was quite disheartened by how some of the TC discussions around project status played out. IMO there was a failure of due diligence and mentoring. If we continue to have the TC making important determinations about the future of projects (whether it be their integrated status or their "production readiness"), then I think we need to ensure that the TC keeps itself fully appraised from an earlier stage about the direction that the project is taking, and gives fair warning when it feels that a project needs a course-correction.
Doug Hellmann We're fulfilling most of the mission, but we can do better.
The Zaqar graduation discussion is a good example of an area where we need to rethink how we bring new project teams into OpenStack. There are several similar suggestions to drop our current incubation and integration process completely, and that is one option. Another is to set up the resources we would need to do an objective technical evaluation for projects. I favor a combination of those two ideas, evaluating projects on several criteria from the users' perspective, but deciding the "official" status of a team based on community considerations.
We have also recognized that we need some way to handle cross-project initiatives such as improving our logging to make debugging easier, but we do not yet have a formal structure in place to accomplish those goals. The way we set up working groups for those sorts of jobs is going to depend on the outcome of the bigger governance discussion, but I think they should be organized by the TC.
Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?
Eoghan Glynn Most of my prior opensource experience was on various Apache projects and in contrast it's striking that the OpenStack contributor community is on the whole more skewed away from pure volunteerism, and towards corporate contributors. By that, I mean contributors who are employed by major operators and distributors of OpenStack, where their day-job is to go forth and make it better. On balance, this is actually a strength in our community. It certainly aids in the continuity and sustainability of effort. It also helps ensure that less glamorous, but ultra-important, efforts such as stable-maint and vulnerability management get the attention they deserve.
However, despite this skew, I'm well aware that we're building a "broad church" here. I think we all benefit from active efforts to build diversity in our contributor community and harness the energy of contributors with all kinds of motivations. Not just because it's the right-on thing to do, but because it's the *smart* thing to do ... ensuring that we get access to all of the talents, especially from previously under-represented groups. Towards this end, I continue to support the efforts of programs such as the GNOME OPW and their recent moves towards extending their reach to a wider set of contributor backgrounds.
John Garbutt I feel we are a community of problem solvers, and wanting to collaborate and make an impact.
Many of us do this work as (some or all) for our full time jobs. That leads to people being put into a position where the problems they are able to work on can be constrained by their employer.
We need to get better at educating those who employ people working on OpenStack, on how they can get the best out of their investment. For example, not testing things upstream, is really going to hurt.
David Lyle Contributors are motivated to contribute for various reasons. People contribute for personal interest, corporate interest, academic interest, and any mix of all three. Corporate interest covers a lot, from users to operators, vendors to consumers. Many ideas from our great community of diverse contributors helps drive us forward and keeps us honest and progressing.
At the end of the day, OpenStack is cloud software that should be usable. We do need to temper the wouldn't it be neat if, with how will this work in real world application ranging from small test clouds to large public clouds. Services should strive to work across this spectrum. The difficulty is focusing these disparate motivations into a cohesive effort.
Dean Troyer I think at a high level this is one of the motivations to re-evaluate our existing structure. We are a corporate-driven project and in spite of individual efforts to remain independent the corporate influence is being felt in ways that the individuals may have not anticipated, ie, being 'Integrated' is the most valuable attribute for a project, and is the indicator for investment for many corporate managers.
At an individual level I see people who want to make a better cloud and make the tools and components to get us there. We have some procedural things to smooth out (CLA, etc) and some significant scaling issues to address (review backlogs) in order to retain and utilize the energy being brought to OpenStack by new contributors.
Anne Gentle Contributors are motivated in different ways, but we're all humans and behave like humans do. In Peter Kollock's study of online communities, he found these motivating factors for participating: reciprocity, reputation, sense of belonging, efficacy, and need. All of these make sense to me when put in the docs context, "why would anyone contribute to upstream documentation?" and I can also draw maps and correlations to the overall reasons why contributors work on upstream. We need to be aware of what happens when the "need" stems from corporate motivation, but I know that OpenStack is a great community to work within and that I can do my part to demonstrate which motivations I want to encourage in our community.
Adam Lawson I like what I read earlier today: "People want to do work that matters and enjoy doing it." This sums up Openstack contributors very well but it sums up a lot of us too though, doesn't it. Many of us are lucky enough to be able to work on Openstack full-time as a job. There are many others who work with Openstack in the context of Consumers, Users, Operators, Solutions Architects where it is not their full-time job but they participate with the Openstack community because of other reasons. Whatever the reason (philanthropy, my good looks), folks want to work on what matters and if it doesn't matter, there is no motivation to continue.
- I see friendly interactions within the community even when we disagree. That's motivating.
- I see members within the Openstack community soliciting and offering help to each other - even between companies who could technically be called competitors. That's motivating.
- I see the same people who earn a living on selling and supporting proprietary deployments of Openstack offering their assistance and perspectives to those who are not using their product and possibly never will. That's motivating.
The culture developed and nurtured by the Openstack community is nothing short of admirable and from someone who is socially-driven (despite my little shell), I have to say that so long as the TC adheres to and advances this culture, motivation will be easy to find for those who desire to get engaged.
For those who need a little help, I think the Upstream University is another place to encourage new contributors and get them motivated through empowerment via learning/knowledge and the satisfaction of watching their hard work being used and consumed by countless companies and individuals. John Griffith I believe this question is asking "what I think is the motivation for the people actually committing to OpenStack" so that's how I'll address it. It's interesting, there's most certainly a number of companies with what might be considered "armies" of folks working and contributing. The important part however when asking about motivation is what's motivating the contributors themselves; of course I think many of us our motivated by our employers and a pay check and there's no doubt that some of that influences our day to day decision making. That being said, at the end of the day most people I talk to just love working as a part of the community and having the opportunity to be an Open Source Professional. Regardless of how they end up there, it seems to me that most of the folks I work with regularly are motivated by OpenStack itself and the opportunity to be a part of something "big".
Russell Bryant People want to do work that matters and enjoy doing it. OpenStack is clearly a project making a huge impact. We also need to make sure it’s a pleasant community to participate in. There are a lot of things that make some communities more enjoyable than others. There are obvious things we want to avoid that are covered by the community code of conduct . I think feeling non-productive hurts motivation. We need to keep working to identify and resolve issues that get in the way of getting work done.
Sean Dague I'm not really sure the intent of this question, but I'll take a swing at what the author might have intended. A very large amount of OpenStack work today is sponsored. Some of it is very vendor oriented for very specific features those vendors want in the OpenStack changelogs, some of it is people that love this community, and have found entities that will support that. The fact that a huge number of our community leaders are not working at the same company as when they started with OpenStack (including myself) speaks to that passion.
I'd honestly like to see more small contributors, and more people feeling like they could make an impact to OpenStack even if the don't have the privilege to work on it full time.
Doug Hellmann I don't know if we have numbers, but my impression is that most of our contributions come from people employed at least in part to work on OpenStack. Their commitment to the project as a whole, outside of their area of specialty, varies for a lot of reasons. We want everyone to have a strong commitment to the whole project, but that's not always realistic, because it's not always up to the individual to decide how much time or effort they can put into working on OpenStack, or into a given area. That's perfectly normal and OK. We can, and do, welcome contributions from all sorts of people for all sorts of reasons.
Zane Bitter I wouldn't, but since you ask... OpenStack is not a hobbyist project. No major open source project is. The vast majority of contributors are able to contribute because it is benefiting their employer somehow - either because they have a problem to solve directly with OpenStack, or because they are selling something complementary to OpenStack. We need to make contributing as easy and pleasant as possible, so the first group will contribute at all and so the second group will contribute as much as possible in their long-term interests and not only in their short-term interests.
Monty Taylor I'm pretty sure the majority of our contributors are doing so as part of their jobs. I think this makes our dynamic a bit different than a "traditional" Open Source project.
That said - I think we see a very strong set of people who are passionate about what we're doing evidenced by the number of people who have worked for multiple companies while working on OpenStack.
I can't speak to everyone's motivation - but I can tell you what mine is.
Cloud is taking over as the way we think about how IT works. It's not an if, it's a when. But even with that, Cloud is an idea more than a destination. When we started, there was one legitimate definition for "Cloud" and it was Amazon. Amazon is a closed-source company run by a ruthless dictator. I do not want to live in a world where I need his permission to use a computer.
Over the last four years, we've made significant inroads in redefining what Cloud can be. Containers and bare-metal are now legitimate building blocks and I think it's becomming understood that you can use cloud to effectively run things other than scale-out ephemeral compute based patterns.
That direction and that transformation are the things that must happen for the Internet to keep both open and operational. I think it's essential that people make them happen. I'm lucky enough to be in a position where I can contribute to that - so I hack on OpenStack.
Topic: Rate of Growth: There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?
Dean Troyer As I wrote above, we have lost focus as we have attempted to widen the scope of integrated projects. Rather than do a smaller number of things very well the pressure is to do a lot of things.
Anne Gentle Hopefully by now you've seen me represent the cross-project ramifications of this growth rate over the years I've served on the TC. The docs program has had to adjust the expectations and educate incoming programs about how OpenStack documentation is not just project-by-project but an umbrella effort. People come to docs.openstack.org for OpenStack docs, not just nova or glance docs. I hope I have shown bravery in the face of the rate of growth and also pragmatism.
Monty Taylor There are people who are core reviewers who I do not know. That's awesome.
Some of the consequences are that we have to continually reassess how we're doing things. I'm sure this drives people nuts - but we've reworked how we organize and govern ourselves several times as each previous system reaches a scaling point. The introduction of programs is an example of that - they were not needed in 2010, but in 2013 they solved a problem. It's possible that they, as an organizational structure have outlived their time, or it's possible that they still serve a purpose in helping us get our job done but need to be tweaked in scope. The big-tent-targetted-gate discussions point to fragility in our monolithic integration story - again caused by scale, and incidentally caused by us actually meeting and not shrinking away from the challenges of doing captive integration at scale.
Sean Dague The rate of growth has very much meant that most contributors to projects only contribute to their one effort. The cultures in each project have grown quite different over time as to what's acceptable patch culture for each project, acceptable review culture, how bugs get handled, what's validated, and many more things.
When I joined the projects one of the mantras for no non python OpenStack projects was that common language and common tooling would mean that developers and operators would have an easy time moving from one project to another to address an issue.
I think the explosive growth we've seen, and the challenges with coherent integration of all these moving parts, has shown that there is a lot more to unified experience than common language and tooling.
I think it has also very concretely strained the Horizontal efforts past their capacity points. Docs, QA, Stable Maint, Security, all very much have to now pick their battles and leave a lot on the cutting room floor.
Take this example: I recently started working on the final Nova fixes for a cross project security issue that was made public 14 months ago - https://bugs.launchpad.net/keystone/+bug/1188189. It's honestly unclear if this has been completely addressed in other projects.
Adam Lawson I believe Openstack is on the cusp of experiencing growth pains like it never has before. I don't think we've even touched on what those pains will look like when we hit some of our long-term adoption goals/milestones. But pain drives change and change that drives improvement is good. So we can all tell change is on the horizon.
One of the consequences of rapid growth can be disproportionality between different areas of the Openstack and its community. Code might get ahead of docs, the need for process might get ahead of the definition of those processes and scale requirements might reveal all of those unsightly warts we've been content to ignore for the last year.
I don't see growth as having consequences per se. Without wanting to sound cliché, I see Openstack as approaching growth-related challenges that we need to treat as real opportunities. So long as we focus on the task at hand and not lose sight of the 'why' not allow overwhelm-ment (is that a word?) from affecting the measure of correction that may be needed to resolve a challenge, I think we'll continue to land on our feet from cycle to cycle.
Doug Hellmann Growing so quickly is forcing us to think about how we organize our selves and make changes explicitly, and more rapidly, rather than allowing for a slower evolution. We've had a lot of blog posts and mailing list threads talking about ways to handle the growth through governance model changes to the project. These are important decisions for us to make as a community, and we need to weigh both sides of each issue carefully.
For example, we want to be more inclusive and bring more project teams into OpenStack, but doing that further strains our cross-project teams' capacity to help us all with documentation, infrastructure, and release management. More creative independence for projects can increase complexity for deployers and users as we drift away from consistent patterns. Providing incentives for creating new projects may take away incentives for collaborating on existing projects, ultimately hurting both projects. In each of these cases we want some aspects of both sides of the equation, but we need to strike a balance.
Working out the changes we need to our existing set of policies will take more thought and discussion , as we try to predict the consequences of the proposed changes and craft new policies that are flexible enough to continue to maintain a healthy community.
Eoghan Glynn It's clear that we're nearing an inflection point in our growth path, where the ability of our cross-project concerns to continue scaling up to meet the growing demand can no longer be taken for granted.
My instinct on this is to first examine how we organize those cross-project concerns to see if the scalability ceilings can be raised, before going down the route of rationing these cross-project resources across a smaller set of projects.
John Griffith There is indeed no arguing that the growth has been phenomenal. There's also no arguing that there are consequences. My statements earlier about the current role and function of the TC (more precisely my criticism) is a direct result of that phenomenal growth. The model that we started with just flat out does not scale to the level we've grown to.
I think that things start to break down, starting with effectiveness of our current governance model; but worse I think we discourage the "casual" contributor. Personally when I first contributed to OpenStack three years ago it was very discouraging for me when a patch update I submitted sat idle for two whole days without somebody reviewing it. Currently two days would be considered by most a rapid turn around. The point is there are people with good ideas and good contributions that get lost in the shuffle, and they don't come back.
John Garbutt Yes, its hurting, and it touches everything. But thats fun, and brings new ideas, and challenges, which keeps us evolving and adapting. We need to take care to unlearn things that get in the way too.
Russell Bryant Just like any organization with growth, we have growing pains. I’d say identifying and working on these growing pains has always been a core part of what the TC does. I expect that to continue to be the case. The coming cycle appears to be no different.
David Lyle The phenomenal growth rate is our greatest asset. It's also our largest pain point. We need to reevaluate our processes to cope with this increased strain. I think we need to remain inclusive, but temper how much the ecosystem taxes the cross-project resources of OpenStack.
Zane Bitter The biggest and most important consequence is that we have lots of talented contributors working hard on solving real problems that our users have, and doing it in the open, the OpenStack way. Another is that we've outgrown some of the centralised shared resource structures that made sense in a smaller project. We'll need to work on decentralising and building communication paths.
Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?
Anne Gentle As an admin for the GNOME Outreach Program for Women for the last two years, I have helped with on-boarding new interns who have to have a patch in order to complete their application. Really, though, the previous interns do a lion's share of the work in on-boarding newcomers to our community. I think this is because their eyes are freshest to the difficulties you'll encounter while figuring out our unique processes. I'm also amazed at how a wonderful small community has grown up out of helping others learn, and that's been the best part about seeing new contributors coming in. We've done a lot to make installing git review easier and specifically setting up the gerrit remote. So the very first on-boarding experiences can get better. Now, the experience of those of us a few years in isn't great either as reviews are harder and harder to get through and our gate is stuffed full with patches wanting in. I think we can work on both experiences at the same time to make it better for all contributors.
Doug Hellmann There's no question that OpenStack has a steep learning curve, both as a user and a contributor.
Documentation is useful as a reference, but there's nothing quite like having an experienced guide helping you first hand. I had the benefit of a couple of informal mentors when I started contributing. They walked me through the long process of setting up the tools and development environment I needed until I was able to submit my first patch, helped me get the most out of the design summit, and generally eased my entrance into the community. Today we have a few formal programs in the community to match mentors and new community members. Those programs deserve our support, but day to day, we can all do a little bit to help each other out by answering questions and sharing our knowledge freely.
Sean Dague Terribad.
24 steps of CLA madness, multiple ids, signing stuff, to get to the point of submitting your first bug fix is insane.
You have exactly one chance to make a first impression, and today I think the process of contributing to OpenStack prior to even uploading to Gerrit is onerous enough that we're preventing most of our best future OpenStack contributors from ever existing.
This needs to change.
Adam Lawson I mentioned Upstream University earlier and I think it's worth repeating that working on something that matters is motivating.
I do *not* believe however that maintaining the status quo is ever an acceptable approach with technical leadership as provided by the TC. Quirks, 'that is the way we've always done it' and 'get used to it' are completely unacceptable. We can't discourage change if it helps but we can't allow unnecessary or poorly-prioritized changes to negatively affect our progress on the project as whole either.
With that said, I'm pretty sure new contributors that are contributing to Openstack (more than casually) understand the dynamics around contributing to a high-volume open source project like Openstack. For those who do not, the learning curve can be pretty steep but beneficial. And we need to be careful not to allow the process to suffer for high performers in the name of inclusiveness.
One of my goals, if elected, will be to facilitate a superior product via process(es) that enables a scalable contribution pipeline for experienced developers - coupled with an effective onboarding process for those who are just getting started with Openstack's development cadence. I think the priority definitely needs to be where we get our biggest bang since our resources are obviously not unlimited but I hope that an effective contributor experience does a good job at accommodating both new and existing contributors and I hope we aren't afraid to challange the status quo if we're failing that goal somehow.
Zane Bitter I would have to guess frustrating. The process starts badly with a bunch of hoops to jump through culminating in the CLA. At least the first patch is greeted with a friendly, helpful "Welcome new contributor" message. From there we should keep in mind that the experience differs from project to project. The smaller ones are probably doing OK for the most part, but the larger ones are struggling to provide the timely feedback that new contributors need. In some cases that's exacerbated by overly-bureaucratic processes and review nitpicking (which could be summarised as a generally procedure-focused rather than results-focused outlook).
Russell Bryant I suspect being a new contributor would be quite overwhelming. Joining a project of this size and activity level is daunting for several reasons. I welcome and applaud all efforts to help onboard new contributors.
David Lyle There are several things OpenStack has right for new contributors. The documentation on how to contribute is easy to discover and very thorough. Requisite information for submitting a patch is well presented. The OpenStack developer is also a very open and inclusive community. New contributors are treated with civility, respect, and appreciation. This is something I am very proud of and strive to maintain. From there, the contributor experience becomes a more daunting. Although the documentation for getting started is very good, there is still a great deal of process and configuration required to apply that documentation toward contributing your first patch. Hopefully a new contributor's patch is a bug fix. Once that hurdle is crossed, the experience is much better. Patch review turn-around time is a large concern as well, and again comes back to dealing with the scale of OpenStack.
I know there has been numerous discussion regarding the CLA requirement. For most contributors this is not much of an impediment. However, I understand some employers are not willing to let employees contribute based on the CLA requirement. I'd like to strive to include those contributors as well.
John Griffith I sort of touched on this in the previous question, but there's certainly more I think that can be added here. I think the experience for most new contributors just plane sucks! What's worse is I've taken part in discussions where this topic was discussed and some honestly state "I don't care, that's not my problem". Over the years I've heard OpenStack called things like "The Ego Stack" and have had quite a few people point out to me that it's not a very welcoming environment. I think that many of us that have been around for a bit sometimes take for granted that not only is OpenStack a rather large and fairly complex collection of moving parts, but we also have some very specific ways of doing things. We also tend to be pretty hard on reviews sometimes (not saying that's good or bad, just saying sometimes when I read through review comments I kinda feel bad for people on the other end).
I think we'd all do well to take on a bit more of a mentorship role. One other thing that often comes up on this topic is the CLA, there's a lot of buzz about it on the ML and in some peoples blog posts. I should probably share my opinion here as it seems relevant; I've never understood why it was such a big deal, and I've never had anybody tell me that they wouldn't contribute to Cinder because of it or that it caused them any undue burden. I'm certainly not saying those sorts of claims are not real or justified, I'm just saying that if you're looking for a TC candidate to fight the CLA fight, I'm most certainly going to disappoint you on that. I really don't understand why it's such a hot item for some and I'd rather just come out and be up front about it than ignore it.
Dean Troyer The mechanics of contributing (CLA, accounts, etc) could be much better. I am not convinced that the CLA is providing value. The percentage of initial contributions that I see that are more than trivial spelling fixes or similar is low, as they need to focus on the process rather than the content just to get going.
Monty Taylor OpenStack is optimized for high-throughput at the expense of individual patch latency. This means some of our processes may seem new or opaque to people depending on their background. However, given that the project has regularly doubled every six months for quite some time, I do not think solving this is a priority if it's at the expense of the productivity of the folks that breathe OpenStack 80 hours a week.
For those who have not begun contributing to another Open Source project in a while, I recommend you do so. EVERY project of size has its own quirks. Ours are, while long, well documented and consistent.
Eoghan Glynn To answer this question, I tried to project myself back to my own journey up the on-ramp. It was of course a simpler time in terms of the proliferation of projects and services, but the key elements have mostly remained the same.
Firstly, the good ...
One thing I found awesomely useful at the time was the ability to easily spin up an entire mini-cloud in a VM and just get my hands dirty, attempt to decipher the logs, snoop the messages passing between services, peek inside the databases and so on. Given that we rely on it so heavily in our day-to-day, it's easy to forget how helpful devstack really is. I found it a massive leg-up, coming from a scenario where setting up any kind of simulacrum of production was quite a gnarly task.
I also found refreshing the willingness of various "old-timers" to answer my dumb noob questions in a friendly and non-judgemental way. We should never under-value this quality in our community, anyone who in a past life has struggled with knowledge-hoarding will attest to how open we are in this respect.
Next, the bad ...
We have a particular culture on gerrit were newbies sometimes feel they're being ignored, or at least that their patches are not getting the timely traction they expect. I know I fell into this trap myself back in the day, where I followed up a git push with an almost immediate full-court-press on potential reviewers via IRC. With predictably counter-productive results. I think we could better serve new contributors by setting more realistic expectations of review turnaround from the very outset.
And finally, the ugly ... ;)
Ah yes, the old Contributor License Agreement that many of us love to hate. TBH being required to sign this was more of an irritation to me when I first encountered it, but thanks to efforts over the last couple of cycles by some individuals on the TC, I now have a much clearer perspective on the real and practical difficulties this seemingly unnecessary legalism introduces for some contributors. Needless to relate, I'd be fully supportive of the TC's continuing efforts to replace the CLA with the Developer Certificate of Origin.
John Garbutt I enjoyed how I was welcomed into the OpenStack community. But it was scary then, and it has to be worse now. We all need to do our part to be open and welcoming to people.
But we should probably look at who is leaving our community. I certainly see people step back due to frustrated with the contribution process. Sometimes burning out after feeling like their ideas are "torn to shreds" or feel like the are battling pointless bureaucracy. The solutions are hard, but it feels like getting better at documenting the "intent" of a process, would help, better setting of expectations around how debates will work, would help. I find rather than trying to "merge my patch", its better to collaborate in "solving my problem".
Topic: Communication: How would you describe our current state of communication in the OpenStack community?
Zane Bitter We communicate a lot, and in the open, which is great. The hard part is filtering the fire hose. As we decentralise even more, we'll need to mitigate that problem by establishing fixed (rather than ad hoc) channels of communication, so that people hear about the things they need to without getting swamped. The Oslo liaison program is one great example of how to achieve this.
Anne Gentle Communication with such a wide, growing population can be difficult but I think we have the channels available with opt-in policies that make sense for our community. The TC listens on many channels, I know I'm subscribed to all the mailing lists without filters still, and we made a concentrated effort to write summary blog posts to let everyone (not just ATC listers) know what we're up to. We understand its importance and we have a lot of good writers and communicators on the TC who make communication a priority.
Monty Taylor Did you read this email all the way to here? If so, communication is going well. :)
Inside of the tech community I think we're doing ok with communication. Piercing our bubble, on the other hand, needs work. Keeping up with what we're doing as an inside is hard enough, I cannot imagine trying to follow it as an outsider. Similarly, since we're optimized for intra-developer communication, getting a voice to operators and users is hard.
Doug Hellmann Our growth is making communication more challenging, but we are adapting.
The specs process has helped with technical planning, setting expectations, and recording decisions. Still, we have a lot of initiatives not tied directly to specs -- especially those that span project boundaries and releases.
I told the Oslo team that my mantra for this cycle is "Write it down," by which I mean we should clearly document our discussions and decisions so when a topic comes up again we do not have to rely on our memory. IRC is a great medium for quick iteration, but it's lousy as a historical record.
Communication is the key to maintaining a healthy open source community. Keeping up can be difficult, but we all have to pay attention to the messages coming out of other teams, to watch for anything relevant, then participate in the conversation.
Sean Dague I'm going to take "our" to mean all of us in the OpenStack community. And the best way I can say is fragmented. We have the mailing list, but with so many efforts being on list (Nova and Fuel being in the same list, for instance) it means that many things get lost. We have a vast array of per project IRC channels... though very little traffic on #openstack-dev. As far as I can tell only a very few core developers currently monitor #openstack-dev for interesting content, which adds huge burden to any cross project effort that's not got a dedicated cross project channel.
Russell Bryant The way we communicate seems pretty typical for most open source communities. We have a heavy emphasis on mailing lists and IRC. We have a significant amount of in person meetups as well. For those that are able to make it, I think they help. We just need to continue to be sensitive to community members that can’t attend all events. Good documentation of discussions and allowing discussions to continue on the mailing list are important. This is largely done well already, but it’s important that we continue to emphasize it.
John Garbutt Its not terrible. I think we could do better at on boarding people without previous open source community experience. There is a lot of email, but the tagging seems to make filtering some of it possible.
Cross project discussions seem to have improved with the mid cycle meet ups. Certainly need to keep track of what was decided, and share with those who couldn't make it. I do hope, one day, we can come up remote participation that works.
John Griffith So the good thing here is I think we communicate well considering the challenge we have. I think that most people are currently very open via public discussions on IRC and raising issues and concerns on the mailing list. The only problem is that it's become increasingly difficult to actually keep up. So in terms of the community being open and communicating, I think we're doing great. In terms of the volume of communication and the effort required to keep up to date, it's a bit overwhelming. You certainly need to focus on certain areas/items that are most interesting or applicable to yourself in my opinion.
Dean Troyer There are enough different communication channels available that it is hard for anyone to monitor them all and still have time to write. I do think in general we have done a good job of herding conversations toward the mailing lists and logged IRC channels. Twitter and personal blogs are other common avenues and may or may not be easy to discover if one doesn't already know about them.
Eoghan Glynn We have many "official" vectors of communication: the design summit, mailing lists, mid-cycle meetups, gerrit, logged IRC meetings and so on. All of these have their strenghts and weaknesses, but as a community we're learning to use and filter them quite well, despite their firehose-like nature.
There is also an emerging trend for important discussions to be initiated and developed outside of these official channels, e.g. via ad-hoc discussions and blog posts. This is something I'm not so enthused about, as it's harder for such channels to host a two-way inclusive conversation.
Also, as in any technical community that I've ever experienced, there's a lot of shared "tribal knowledge" sitting in peoples' heads. I'm as guilty of it as anyone else, perhaps even more so. That's just what happens day-to-day as the rate of knowledge accretion surpasses the time available to codify it. However we all need to try forcing ourselves to take the time to write such nuggets down in a discoverable place, in order to provide a bread-crumb trail for those who come behind us.
Adam Lawson While I think our communication overall is encouraging and moving in a positive direction as a whole, I think cross-project and communication between developers and the consumers remains to be a challenge. Understandable though when you have multiple mailing lists with countless updates and program owners and contributors who can't possibly read every message to se if there's something that requires their attention. IRC and email tends to be our forte but I envision expanding the Operator Summits to include cross-project summits where brainstorming between 2-3 programs that compliment each other (i.e, Swift/Sahara, TripleO/Ironic/Nova) can be *highly* beneficial. I know we already have mid-cycle meet-ups but this level of collaboration might even benefit from a dedicated design summit. No sponsors - just a place where ideas dedicated to the technical direction of Openstack share the spotlight. Just a thought.
David Lyle For a global community of developers, I think communication is very good. However, from the feedback I receive, the burden for communication is too high. With 19+ recognized projects and 20+ other satellite projects vying for developer eyeballs, it is very overwhelming for contributors to filter and find the important items to them. I think this is primarily another symptom of community growth.
Topic: Relationship with the Foundation Board: The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?
John Garbutt Not having been on the TC before, its hard to comment. Seems like they are talking to each other, which is good news.
David Lyle As an observer of the technical committee the past couple of years, the open interaction I've witnessed has primarily focused on Def Core. There is a fundamental disconnect between the objectives of the Technical Committee and the Foundation Board on this issue. This is expected as the two bodies have very different end goals. The board's role is to protect the OpenStack trademark in which many companies have heavily invested. Allowing the trademark to carry a very broad definition potentially lessens the return on this investment. The technical committee is made of the builders of OpenStack, believers in an open process of development. To restrict the way operators can use OpenStack to satisfy how the trademark can be applied runs counter to the open process. An impasse is the result. My position is that the components of OpenStack are replaceable, the burden for the trademark should allow for API compatibility, but I fall on the developer side of the fence.
Doug Hellmann I have a somewhat better impression of the relationship between the TC and Board than has been expressed by other candidates. We are different groups, with different perspectives, but we are all working in what we consider to be the best interests of the OpenStack project and that means working together. The face-to-face meeting in Atlanta allowed some of that attitude to show through in ways that it doesn't always in IRC or phone meetings. We have had spirited debates on topics like DefCore and the CLA, as is natural for groups with such different perspectives, but we are also continuing to work together to find ways to solve those and other issues.
Zane Bitter Getting the TC and the Board on the same page on any issue is a big challenge, because the combined group is *huge* (~30 people). Discussion inevitably moves slowly at that scale, and the Board doesn't tend to hold wide-ranging open discussions between meetings the way the TC does on openstack-dev. Cultivating relationships is important, but most of the work will continue to get done by joint subcommittees.
Eoghan Glynn Interestingly, the membership of these two governance structures is somewhat intertwined. Obviously this presents challenges for the individuals involved in both, in ensuring that they can "swap hats" and context-switch appropriately. But it does at least ensure that the board is not resting in an ivory tower, insulated from the day-to-day technical leadership. In terms of the practical interactions that I've seen, I was heartened by the robust approach of the TC in making their preference to switch to the DCO crystal-clear and putting it up to the board to deal with the CLA issue once and for all.
Adam Lawson There's a world of difference between project governance and technical leadership. I admittedly have not sat down with the Foundation members within a TC context so I couldn't speak to how it works well or not today. But what I can say is that I've read what the other candidates who have served on the TC in the poast have shared and my interpretation is that things seem to be a bit frosty.
But I've run into this before. Regardless, I think a clear definition of roles and responsibilities would be of value to both the Foundation and the TC and the relational elements that affect their ability to work together effectively. I'm looking forward to seeing this interaction firsthand and making up my own mind. But until then, onward and upward!
Russell Bryant Our interaction has been improving. We’ve started holding joint meetings at the OpenStack summit. There has also been quite a bit of interaction on the DefCore topic specifically throughout the development cycle. I look forward to continuing to collaborate with the board on the topics where it makes sense.
Sean Dague Confused? No, I mean I'm confused, because honestly there seems to be not that many fronts in which they interact. I was very mixed on DefCore because it seemed like so much of the important work there happened in face to face meetings in San Fran. And there kept being real confusion over intent.
Beyond that I feel like there hasn't been a ton of Board / TC interaction. The joint Atlanta meetup was good, and I think some concerns that got raised in the room did get talked about. But I feel like there are actually quite different scopes of the Board trying to define the commercial ecosystem and market dynamics, and the TC trying to define a set of bits that do a thing. And hopefully keep doing that thing even when some more bits are added. Honestly, perhaps the disconnects that currently exist between the TC and the Board are largely around the fact that the only place our roles seem to overlap is near the trademark definition, and so vastly different perspectives exist based on the day to day challenges each face.
Monty Taylor Abysmal, but getting better. We had a good TC/Board meeting in Atlanta and have another scheduled for Paris.
I think the biggest issue we face there is figuring out how to disagree with each other productively. It's essential that both the TC and the Board get better at being direct and open with each other when we feel that the other body is maybe not stepping up to the plate. There is information we learned from the board as part of DefCore that probably would have been better if it had just been some direct statements - and which I think once Rob and TC reps started meeting directly started getting worked out much more effectively. Similarly, the TC just passed a resolution requesting that the Board consider the DCO to be our CLA. It's clearly the board's prerogative to do whatever - but it's our responsibility to let them know that we have an opinion.
In short, we're learning how to work together being respectful of boundaries but still being honest about needs. It's a journey, and one I think is important that we take seriously.
Anne Gentle Our interactions with the Board include conference calls, in-person meetings, and IRC meetings. I personally find the in-person meetings valuable as it's easier to communicate in person with more rich feedback so you can get a sense of how the interaction is going. On IRC, there's a trade off in richness of input/output but there is also a precision in the typed phrasing, the ability to read back later while you have more thinking time, and an openness since anyone can read the interaction at any time. Our board has been quite solid and changed little over the years which has been helpful for building relationships over time. I know I can reach out to members and I have had members help me when I've asked for it. I sense we're all struggling with the growth rate and feeling like we can't be as agile as we used to. But we're all dedicated to an open cloud for all and I think that shared mission enhances our interactions.
John Griffith Hmmm.... well, I'm really not sure. While I was on the TC in the past there really hadn't been much interaction or communication between the Board and the TC, and one of the few experiences that I did have frankly was less than what I would call enjoyable or productive. So I don't really have much insight here, and the experiences that I have had (which are very very limited) were not good experiences.
That being said, I believe there have been efforts over the last few months to improve this and increase the interaction and communication in a productive way, which I think is great and much needed.
Dean Troyer I have mostly seen the interaction around the DefCore work and have found it interesting that neither side seems to want to say “This Is OpenStack” for fear of stepping on toes.