Proposing a Contributor Council for AWS CDK #676
Comments
|
think this is a flawed plan, and once again reinforces Amazon's lack of committment to own CDK properly. CDK shoudl be no different from anything else AWS does. 'S3' does not have a 'council'.. 'RDS' does not have a council. Please AWS, just own this, and deploy the appropriate resources to it, to get the job done. |
Hi, I think that comparison is a bit flawed. CDK is not a service like S3 or RDS but an OSS project. And other projects with AWS involvement like OpenSearch and Valkey have these councils or committees. Also staffing the project is decoupled from having a council to shape the vision of the project. |
|
Where I've observed AWS has delivered a poor experience in the past is the type of cross-cutting interfaces like the CDK or sub-platforms "experiences" like SSM. These types of horizontals usually feel disjointed and totally separate projects because they're usually handled by many different teams -- a very Conway vibe. I appreciate the idea behind the council because it brings with it the notion that this should be approached as a layer or interface that needs a cohesive, singular experience. On my first read-through the main thing that raised my eyebrow is the need for an NDA. Historically, I've only had the "AWS NDA" cone of silence invoked when it involves forward-looking product/feature discussions. I'd like to know more about how the NDA would be used for the CDK, especially since it's open-source. Also, I would suspect community members on the council would want to have a clear delineation of when something is under NDA or not. If the default is "everything is NDA'd until it's cleared for release", that doesn't sound like a good formula for success. If instead it's the opposite, e.g. everything is open unless it's specifically declared, then I could see how you could find a reasonable balance. Additionally, I'd like to understand better how the Council would avoid situations like "I won't and you can't" -- e.g. the community wants a particular feature/prioritization but AWS determines it should not be build or has a different perspective on priority and does not release it for development by the community. Overall, though, I'm excited to see the CDK get a much needed shot in the arm and direction. |
|
My two cents to your points: NDA: I am sure some things the council needs to discuss are regarding features needed for new launches of AWS so under NDA and/or might involve numbers coming from customers so also under NDA. But yes it should be the special case enot the norm. wont/cant: Given https://github.com/aws/aws-cdk-rfcs/pull/679/files#diff-4fbcef36c69495c52bf4471a37dd50326c3e6fb0e43a7c8ecf53a9ff7537336eR13 there might/will be things that AWS just cannot add to the project even if many people would love to have it. But again it should be a special case not the norm. |
I'm not sure it is opensource in the true sense. The code might have been aviaiable, but an OSS project should have an open contirubtion policy, and well, CDK has never really been that. Very little of AWS is open source. We pay money, if it breaks they fix it. Its a very simple contractual relationship. AWS provides services that behave in predictable ways. WHy does CDK think it needs to act in a different way. It just doen't need to. Just turn it into a service offering and say it does 'X'. Deliver and support 'X'. We all deal with this every day. Sure AWS shoudl listen. Stop pretending.. AWS will always have the final say. And so they should. This council idea is just 'feel good', that someone in marketing probably came up with. |
|
Is AWS going to Pay these people for their time. This kind of review and decision making, is the stuff people get paid several hundred dollars an hour for as consultants? |
|
The root of CDK's many problems is that it is a 2nd class API that service teams are not required to implement/support/maintain — an organizational problem that adding a committee like this cannot solve. I suspect the committee will likely be just another layer of (unnecessary) debate that may even decrease the current delivery rate, as the appointment to discuss the change further that could be “just delivered” is always one month away. I understand that Amazon wants to avoid this kind of corporate bureaucracy to remain agile. Have I understood it wrong? So that this isn't just a letter of complaint about how you're doing things wrong, here is an alternative: If the service teams with the best knowledge and experience of their service, users, and usage patterns owned and produced the service library constructs according to the standards defined by CDK and released them timely (together with the service feature releases), we wouldn’t need to have this discussion. Sure, it's a much more challenging approach, but at least it would try to grasp, possibly even admit, the problem and not only work around its symptoms. I’m standing here with Andrew: “Please AWS, just own this, and deploy the appropriate resources to it, to get the job done” ✌️ |
Learning CDK is 10x easier than learning the aws product. this is a much smarter approach. If you've created the service and the CloudFormation, the cdk constructs will be a walk in the park. and in any case, all we really need is the L1 constructs, a few useful L2 constructs, and a cli. |
Exactly. Do you remember the Werner's famous line "There is no compression algorithm for experience”? Well, here you actually have one: take the knowledge of the service team, distill it into a construct and ship it. I see no reason why CDK team should act as a gatekeeper for the content (what service constructs are in practice) produced using CDK framework — even when shipped as a part of the library. |
|
I appreciate the intent of this RFC: but without stewing in too much skepticism this early in the new year... inclined to agree with some of it. It's always been a bit "open source in name only" and that's okay when there's a core project team, and then outsiders can tinker around the edges "hey this default needs changed" or "updated the docs to make this clearer". And that's ok assuming that the core stuff keeps up, and that there was capacity to triage/merge/reject these contributions. But that wasn't the case, and so the entirely pragmatic contribution change a while back to not accept "new" things was a valid approach to where the project was/is. Maybe the CC can provide feedback, maybe if some stuff was under NDA and were then able to say "we should prioritise adding new service X to CDK" might be good. But doesn't change the overall vibe that those trade-offs shouldn't be happening: all services should have level 2 constructs. Could/Should the purview (you mention something being a committee and suddenly the jargon just happens) of this group extend to identifying stuff generated by the OCF, looking to hoist stuff that's looking like Undifferentiated Heavy Lifting into the main project? I'll be interested to see how this plays out, I hope it helps, but I fear it doesn't really address the main issues with the project. It feels to me that CDK is CloudFormation++ and should be run as that, by AWS. But that said, I appreciate the proposal, and I would love for my thoughts to be unwarranted scepticism or misunderstandings. There are a number of great non AWS people in the community who already make great contributions - and I'm confident that many of those would do even more on the CC. Finally, as a minor aside, THANK YOU, for not incorrectly pluralising Chatham House Rule, one of those things that irrationally grates my gears. |
|
Thanks everyone for the feedback and questions so far. Your input will help ensure this Council best serves the community. I want to address some things to clarify how we’re thinking and add my two cents. CDK is a really fascinating project. It’s different than almost anything else that AWS builds for a couple of reasons (some of which have already been mentioned here). It was designed to be open source from the very beginning, and yet it’s tied so closely to AWS services. There’s a natural tension in that. I’ll come back to that tension in a second. Another way it is different from other AWS services is that, to Preskon’s point, it is a horizontal layer that covers the full-breadth of AWS offerings. It interacts with a multitude of different components, and a wide range of customers use it, including Amazon itself. Both Amazon and our enterprise customers have non-public mechanisms to interact with AWS CDK teams to see that their priorities for the project are taken up. There is a natural tension in the spirit of CDK’s founding, and the realities of day-to-day operating a project like this at AWS. But that tension was a known quantity from the beginning. CDK’s creators wanted that tension, in fact they welcomed it, for the same reason we’re building this CC in partnership with the community. We believe that things are better when we build them together. If you want to go fast, go alone, if you want to go far, go together. From Elad Ben-Israel and Ricardo Sueiras’ blog about the history of CDK from 2021:
Given these tensions, it is vital that the AWS teams who build and use CDK every day take deliberate and documented steps to build in the open, solicit community feedback, and bring the community along with the decision-making process. That’s why the decision-making mechanism is designed to decouple decisions around “what is good/viable for the project” and “what AWS service teams will work on.” It is also why we are planning to adopt Chatham House Rule, so that CC members can make decisions as a member of the CDK community, not as an “AWS engineer” or as an “external user/contributor.” I want to be explicit. The intent of the CC is not to offload work AWS should be doing for CDK and we hear everyone’s concerns about this making CDK development slower. We think this effort is a worthwhile investment because involving the Council and the community much earlier in the decision-making process should lead to faster delivery of the right things. We'll build the Council such that it does not interfere with the CDK development teams progress, process, and/or roadmap. Regarding the concerns on Council overhead, again, we’re planning to work hard to make the time requirement for members as low as possible—think single-digit hours per month—because we want the focus to be on building CDK. We hope that participation in the CC is easy and accessible for everyone, internal and external community members alike. We also hear you about the need for investment in other areas of CDK beyond community engagement. We’re already staffing up a number of roles on the CDK service teams. We’re planning to work collaboratively to improve contribution pathways. We want to partner with the Council and broader community on community-led construct libraries, events, and more. To address comments about the NDA requirement. The Council will be open/ transparent by default. I think it would be valuable to publish artifacts from each meeting for the entire community to see. I realize it’s not common to see an NDA mentioned around an open source project, but we also want to be able to engage with the CC on issues/ideas that we can’t talk about publicly because they relate to non-public AWS services or information. So our intent is to bifurcate the Council sessions to public discussion, which will be the majority of our discussions, and non-public, for the items we can’t share with the broader community. Thank you again for all the comments. Please keep them coming, we’re around and monitoring to answer questions :) |
@haubles , this comment, makes me wonder why you're seeking comment. You keep reinforcing that the exisitance of this said council is already a done deal. That is quite concerning. Is there a reason why there was'nt a call for suggestions how to solve this problem. The situation we are now in, is that folks will see any comments suggesting alaternatives or not in support as just being negativity, and they hate that, more than they want to solve the problem. |
Fair points, and thank you for bringing them up. I think we agree on a lot here, and you bring up multiple points in your comment and I prefer to break them down into siloes. This particular rfc is focused around community and how we can better integrate with y'all and we chose to start with the RFC to get all the feedback. To speak to your points directly:
The committee will serve as a mechanism for feedback intake to offer perspectives outside of our usual mechanisms. AWS invests in engineering, support, security, feature/bug fix work, and so on for the project - this does not change or get altered with this process. AWS sets the roadmap for what AWS will work on. The committee serves as a partner to AWS in looking forward and helping to define the future of the project (in conjunction with those other feedback mechanisms that we already have in place).
Absolutely, I couldn't agree more with regards to working closer with service teams directly. We currently have service teams that follow this process (Amplify being a great example). We have and are continuing to have these discussions internally, and the committee alongside other process improvements are not mutually exclusive. I think there's a bigger point here that needs to be addressed - the purpose of the committee is not to agree that the CDK team will work on adding a small feature of lambda that is missing from the current Function L2 construct, it's to bring more transparency from the CDK team to the community in addition to partnering with the community on think big ideas about the project and what we can do to better serve our customers and community. We are in no way are saying that this contributor council is a giant hammer that will fix all of the problems with the CDK; rather, we are looking to work closer with the community to ensure that you are heard and your unique perspectives are brought to the table. So tl;dr - AWS fully owns and maintains the CDK, has deployed the resources to support the CDK, and is working on improving the project in many ways (technical, open source, etc), and this is just one of the things we are doing amongst the many other things. Again, thank you for the feedback - it’s super important for us to hear it and this is the reason why we started with the RFC process in the first place, to ensure that we heard from y’all. |
Another 'deal done' comment? |
|
I would like to ask AWS to delete/pause this RFC for a moment, and take a step back. I'd actually like them to be bold enough, to say we jumped the gun, Maybe we should start with a empty agenda and ask the community how best this problem can be solved.. Then the community ( and that includes AWS for clarity ) could actually say "heres some ideas".. I fully expect that one of the ideas would be "heres this code council idea". But then at least it coudl be discussed against other ideas which may be better/worse/.. What I'd expect is a fusion of ideas that probalby would have a better overall outcome. This would be real community engagement, as opposed to the loud voices of a few 'heros'. |
What are the new perspectives the council members, who will most likely be the highly active, already vocal, long-time members of the CDK community, can bring to the table? — why haven’t we heard these from them already? Why do you think that formalizing their position will improve their commitments to the project? I’m seriously asking this because the entire community, including the CDK team members, has always been super easy to approach. There have been no questions you couldn’t have asked or comments (even critical) you haven’t been able to give. It is (and hopefully remains🤞) a great and much-appreciated feature for me. |
|
It seems the OCF has been actively involved in this for some time. Why was no other part of the 'community' involved? Does the OCF have some special rights to this? This seems in conflict to the opening statement "the AWS CDK team". Is the OCF part of the AWS CDK team? Or was the OCF not involved. On the face of it, i smell an agenda that someone is trying to push through, which is why in order to make this transparent, 'fair' and community focused, you've got to take a step backwards. |
I think these are very valid and useful questions. I don't' see how the perspectives will be any different at all. And 'formatting' the collection of these perspectives through a council won't change the fundamentals of the position
There is a strange phenomena that humans seem to fall victim to. It starts when we give children a star on their 'star chart' on the fridge. They tell their siblings how great they are because they got 'star of the week'. It goes on to when people get 'titles' at work. There are even people who truly care about the colour of their ID badge. The reality is the colour of your badge, or some title is meaningless, if theres no substance to it. I kind of feel like this RFC has been driven by an attempt to get another 'star' in some peoples charts. For me personally, i'm much more interested in what you can do, and what you've done, than some 'star' on your chat :-), membership of 'heros' or 'community builders'.
Exactly, in the 6 years, since cdk has been around, I've found that to be the case in 99.5% of the time. The .5% for me was one individual who is no longer invovled with CDK, and who I believe was primary responsible for the mess that the cdk team found themselves in. None of what i'm reading is actually addressing the fundemental problem that the cdk team faces. Once a construct gets into aws-cdk-lib, its got to be supported. So, the cdk team needs a massively wide knowledge of every aws product to support it. You can't use the 'community' to provide the support. My clients pay lots of money to AWS for enterprise support which includes cdk, and it scares me to think that AWS is outsourcing its work to a community?? If the construct ( no matter how good it is ) cant' be supported, then surely it cant' be included The previous RFP process was'nt broken, it worked, when it worked. The problem was when AWS managers made decisisions about what was important, and what woud'tn be done. It was a resourcing problem. This council concept does'nt fix the real problem. If anything it just masks, it, and ultimately it will just cause more fustration, when AWS cant' do what the community ( which it would have kind of given some mandate to, if it had a council ) asks for.. AWS either needs to fully let go of this, and throw it into the OpenSource wilderness, or actually take full responsibility for it, ( or do both, with a free and a premium model ). For now, how about just going back to the RFP Process, and just addressing the availability issue of the CDK team.. Theres no need to chuck it all out, because one manager got part of it wrong |
|
we are having a good chat about this in the #aws-cdk channel in cloud-network-as-code. #aws-cdk Please feel free to join. https://join.slack.com/t/cloud-network-as-code/shared_invite/zt-2x7bcvayd-fNqqtM19rKq8YdBFqoUnWw |
O-ou. That does not sound great. @haubles Why didn’t you express that openly and honestly in the RFC if that was the case? Nevertheless. I don’t think OCF (Open Constructs Foundation) has presented the capability to deliver a large-scale open-source project, win users over, or envision a future that may require significant changes (the most crucial task for the council we are talking about) — traits of success. As with promotions, you must have these things before you can be trusted with a formal status. To maintain my trust in the people behind this initiative, I ask you to speak publicly and openly about your goals and agenda. I want to believe your intention was good — the communication just failed miserably. |
|
@nikovirtala We consulted with a number of stakeholders prior to opening this RFC up for feedback from the entire community. I was the initial drafter of this RFC. Since I joined AWS two months ago, I've made a point to make myself personally available to anyone in the community who wants to chat. (A point that still stands; my door is always open.) I introduced myself on cdk.dev Slack and asked anyone with ideas or feedback to reach out to me. I took meetings with several community members. I met with OCF board members. I also spent several hours chatting with @mrpackethead on cdk.dev Slack about his ideas for CDK two weeks into my tenure. Like all AWS docs this RFC went through several rounds of doc reads and revisions after it was drafted. We had a doc read with the OCF board members—including CDK's original creator—three or so weeks ago. Through this process we tried to balance getting lots of feedback early on with moving as quickly as possible. We know folks have been waiting for months or years to see the project move into its next phase. I have the utmost patience for people who are suspicious of tech companies with it comes to OSS. Tech companies have given people a lot of good reasons to be suspicious, so I'm always happy to talk through the motivations/goals/agenda. All anyone wants to do here is to make CDK successful. Our goals and intentions are exactly as stated in the RFC:
As to my personal goals and agenda... My goal is to do good work and my agenda is to leave the world a little bit better than I found it. You can read about my ethos and work experience in these places: As an aside... I understand people have strong feelings about CDK. Especially those who have built businesses on it, and therefore whose livelihoods depend on it. I also know that debate is a feature, not a bug, of all egalitarian systems including OSS communities. As the great Kelsey Hightower once said, "Maintaining an open-source project is like being a flight attendant for an airline where all tickets are free and the majority of customer surveys offer suggestions on how to fly the airplane.” All that being said, I'm dismayed by the personal attacks and rudeness towards myself and others resulting from this proposal. Please be constructive and kind when you share your feedback. :) |
|
@haubles At no point did we discuss this the concept of a code council, when i talked to you. All we discussed was the issue that I ( and an entire team of AWS Network engineers ) had had previously with the cdk when trying to work on a construct for lattice. You even suggested the other day, that you had offered me the opportunity to comment on the document, but when I asked when, you corrected yourself and realized that you had not done so. I don't recall offering any ideas, other than to say, AWS needs to own CDK and resource it properly. The way you've written this, it seems like I knew about this, before this was released a few days ago. I had no idea about it at all. If I had have known about it, i would have voice my strong concerns. This is why i'm asking you to stop, withdraw the RFC, take the time to engage properly with the community rather than run down a path that sits well with 2 or 3 people. (1) So, outside of OCF, which part of the 'community' actually knew about this? |
|
Nobody needs anyone elses permissions to make changes to 'their' cdk environment. Its hugely extendable, its easy to add your own constructs and add your own work arounds for the quirks. When there is a real bug, any delay is annoying, but realistically, AWS has always fixed them pretty quickly. This council idea seems to forget that, and it reinforces the perspective that somehow you need permission.. You don't. Just go and build it. find some like minds if you want and build it together. If you want to share it, goahead, you can. If its useful, others might use it, or borrow parts and modify it to fit their needs. and maybe AWS might say, 'Hey thats cool'. We can use that too. AWS, what you need to do with CDK is just this (a) you need to make sure that your providing up to date L1's that line up with Cloudformation. Thats pretty good today. ( Cloudformation being behind many aws services is another topic ). (b) You need to get your Service teams, to create the L2 constructs for their products. They are the experts in the topic. If they can create the service, and the cloudformation, the CDK is going to be easy. (c) You need to make sure that the tools, cli and 'glue' that hangs it all together works.. (d) You need to make sure you can support it. (e) Treat your customers with respect and honesty. There is no problem ( and never been as far as I can tell ) a problem with connecting with AWS people about CDK. None of that needs a council. What problem is this council actually going to fix. Re-reading the RFC several times, I just cant' see it. |
|
A quick reference from the RFC itself: (1) Town hall
* The AWS CDK team will report on project release priorities and the status of AWS-led features in each Council meeting. Council members will have an opportunity to ask questions and deliver feedback.
* Community representatives will report on news and share updates on community-led features. Council members will have an opportunity to ask questions and deliver feedback.
(2) New proposals
* The Council will review and debate RFCs/features, feature docs, or new processes brought forth by the CDK community and AWS. AWS may not be able to report on all AWS-led projects when we are bound by legal requirements, customer agreements, or when it would put AWS at a competitive disadvantage to report on some project.
* Anyone in the CDK community may propose topics for discussion by the Council. The agenda is finalized one week before each meeting to allow time for pre-reading and preparation. Proposers are invited to the meeting to present and advocate for their change. If they are unable to attend, their attendance is not required for the Council to make a decision.
* The Council discusses the change’s appropriateness, merits, scope of work, and whether the change can be community-led or if it will be built by internal Amazon resources.
* Decisions are completed and recorded through the following mechanism:
* Each Council member enters an opinion on whether the feature is viable including a short explanation. The opinions and reasons behind them are recorded on the change proposal. Opinion submissions follow the [Chatham House Rule](https://www.ibabs.com/en/glossary/chatham-house-rule/#:~:text=The%20Chatham%20House%20Rule%20reads,') by default, though Council members may choose to sign them.
* If the change is deemed appropriate for inclusion in CDK by the Council, the AWS CDK Product team decides whether the feature will be built by AWS and adds it to their feature backlog, or if the feature will be offered to the community for implementation.
* If a change is deemed to be appropriate for community-led development, the label 'open-for-community-contribution' will be added to the feature request.
* It is preferred that community-led features are code-reviewed by a [Distinguished Contributor](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md#badges-pilot-program) before AWS reviews them.
* If a Distinguished Contributor is not available within 30 days, AWS will review.
* The feature needs to adhere to all AWS development and security processes, which AWS will publish on the CDK GitHub. AWS is committed to providing all the required resources for timely reviews and merging.
* Those who build a feature through to completion are recognized in a manner to be determined.This RFC proposes a significant shift in how AWS engages with the open-source CDK community. Through a council-based governance model, AWS is proposing a commitment to:
This approach mirrors successful governance models in other major open-source projects. Rather than relying on informal channels or closed-door discussions with select individuals, the RFC establishes a transparent process for community input into CDK's roadmap. Most importantly, it creates a formal mechanism for AWS to directly support and integrate community code contributions. Thank you to those who developed this proposal, demonstrating both customer obsession through community engagement and ownership of the CDK ecosystem's long-term health. I hope that it comes to fruition. |
|
Over the weekend, I had a good discussion about this topic with a fellow community member who has kept the wheels rolling throughout the years and patiently helped me and many other community members with our issues and concerns. This conversation helped me better understand my own perspective and re-form some of my thoughts to (hopefully) a more understandable direction. I’m trying my best to express these thoughts and opinions here now. Firstly, I apologize if anyone took any of my previous comments as an attack on their person. That is not my intention and never will be. You should also understand that, in my thinking, nothing is as holy, set in stone, black and white, or absolute as my statements may first sound to you. Presenting contradictions and searching the boundaries (both in solutions and people's opinions) are just tools for finding a) that we are solving the right problem with the right solution and b) the right compromise to help us move forward. Those who know me better and in person know that making things better and moving forward is my only aim, and I usually do it with a big grin. Also here — so please don’t read my words too literally 😁 Why do I think the contributor council is such a bad idea, and why does it feel so harmful? First, from the most personal, individual contributor angle: Informal engagement (communication) is the best thing that AWS has ever delivered to me! Maybe you can even call it a feature since it seems to be recurring across the organization rather than just being a lucky coincidence. Throughout the past 20 years I’ve worked in this industry, I haven’t seen any other company doing anything anywhere close to this. This unique feature should be embraced and emphasized rather than suppressed by formalizing all the critical interactions that make being a contributor so joyful. We are people, not machines, and we want to have some fun with our friends and colleagues instead of being drowned in red tape. There is already enough of it everywhere that we don't need to voluntarily add it to the places we like most. The second one is a slightly more from professional perspective but remains on the area that surfaces the contribution experience: Contributions are often time-critical. The need to contribute something doesn’t happen in isolation; it usually happens when you’re in the middle of something, something that you’ve reserved time and resources, and you hit the wall. By being able to contribute immediately, it is more like 1) it happens and 2) it happens in a way that benefits the entire community the most. By delaying the start of the work by one month (the currently suggested time between council meetings), there is a high chance that the momentum is lost, the contributor implements the patch to their version, and the contribution will never see the daylight. So, I guess it is safe to say that introducing artificial delay to the process will not help contributors make more and better contributions but exactly the opposite. I'll stop here so that the post doesn't get too long. However, I promise to continue for one more post, where I'll delve into the proposed practical matters and the council itself as a process. |
It does. THe problem is that CDK is not like any other major open-source project. For a start, Customers pay for support when they purchase Enterprise support. When code is introduced into aws-cdk-lib, it has be supported, and fixable. Because thats what we pay for. When AWS stoped taking contributions, it was becuase it could'nt support it. ( lets be honest, it could'nt even keep up with its own roadmap ). While there has been mention of increasing head count, I'm yet to see a corrosponding increase in the output of new l2 constructs for services. How is AWS going to even more stuff? |
This is something i'd not really considered, but have absolutely experienced. When going to AWS events, i often end up not going to many sessions at all, becuase i've found some interesting person to talk to. And that is very high value. |
|
How will the influence of a particular group or organization not 'swamp' the community membership of this 'proposed' council. For example, could three leaders of "Cloud Networking as Code" all be members? ( just by way of example ) This becomes increasingly important when Chatham house rules apply. |
Good question. This should be covered by this section. You might have specific concerns about one or more of the points here. Maybe you can tie it back to the proposal.
|
The number of seats the AWS CDK team may decide to allocate to specific community groups or customers MUST be limited. Otherwise, AWS can choose all council members, and the community nomination becomes meaningless. |
The current discussion has been 1 members that represents enterprise customers and one member that represents the OCF. The other three can and should (IMO) be unaffiliated with the OCF. |
How does a group get a special place? There are multiple groups who have an interest in CDK. Can they all apply for a special place? |
Which groups? Did they sponsor and organize multiple virtual events for the CDK? Did they manage a slack server for the CDK? Did they run a website focused on the CDK? Have they continuously, for the last 5 years, dedicated time and content production to the CDK? If so, I don't see any reason those groups shouldn't get special consideration. |
|
I'd personally not like to see any restriction on community council members based on membership in other organizations. Respectfully, enterprise customers already have a special pathway for their feedback - the enterprise support contract and their TAMs. With 5 representatives from AWS already, it seems their feedback would have a welcome home. Granting a special seat to any other organization for the remaining 5 positions would be counter to the community nature of the proposed council, IMHO. The proposal says that the community itself would nominate potential candidates, not AWS, and if the community chooses to nominate more than 1 (or even all 5) council members who happen to share a specific organizational affiliation, that's the community's choice. Otherwise where do you draw the line? AWS Community Builders, AWS Heroes, AWS User Group leaders, CNCF Foundation Members, Freemasons...if it's a democratic process driven by the community, let the community choose. This is not to disrespect or downplay the efforts of certain individuals in getting this proposal off the ground, or their unique contributions to the CDK community as a whole. I believe those efforts speak well enough of those individuals that the community would choose to recognize them with representation on this council. |
@mikejgray , in deed. In my major accounts, more than 85% have enterprise support. our model of customer engagement often results in us acting on behalf of a customer, and for all practical purposes our interactions with AWS, are the same as if we were the customer themself. I attend monthly business reviews on their behalf for several of them. There is rarely a day that goes past that I don't talk to someone from AWS, be it a TAM, account manager, SA. In our business model, we often are acting for the customer. When required, they do go and find out what's happening, and create feature requests for the customers. They arrange meetings with experts and service teams as needed, and create escalations if needed. They do this for many things, including CDK. AWS TAMS on the whole, are huge advocates for enterprise customers, and there is no issue with having somewhere to connect. Council or no council, enterprise customers will still get the attention they need, becuase lets face it, they are the ones spending the big bucks with AWS. When your AWS bill runs to the hundreds of thousands or millions per month, AWS does give you the time of day
In deed, I think you have to either be fully 'democratic' or not at all. Trying to be half way in-between in fraught with difficulty. You can accidently become disingenuousness, and alienate the very people you are trying to connect with. I keep finding people who are doing great things with CDK, who are just quietly getting on with it. The guy who spends hours each week, teaching others how to use it. Just because hes not hugely visible, doe'snt make his efforts less valuable than someone who 'ran a slack server'. This raises another question about this process. How do you identify who is even 'community'. The proposal talks about communities nominating people. What are the criteria for being part of a community? Until you can reasonably accurately identify who actually has a Bonafide interest in cdk, voting is fraught with issues.
^^ What he said, because I couldn't say it better.
"elected" is the key word here. Elected means democracy. And democracys are very complex things with lots of curly side issues. You can't just rush a democracy together and expect it work well. You'll just end up with a large pile of pain. Go slower. Get it right first time. If AWS is intent on this council, there is another approach it could take for 'council membership'. AWS could appoint council members to start with. ( you could call for expressions of interest). It then could take some time, to figure out how to identify 'community' and how to give voting rights, and do it properly. |
|
Referring to mrpackethead, I would recommend a trial council to establish governance policy arrangements, such as voting rights, who the voters represent, and so on. |
|
Hi everyone. ~7 days in! Thanks for the continued conversation about this proposal. We’re grateful for the time and thoughtfulness you’ve put into your comments. We’re mostly hanging back to listen, process, and discuss what we’re hearing right now. We don’t want to put our hands on the scale. But, we do want to address some common questions/comments we’ve heard so far. A quick note before we dive in. Initially, we said we would only listen to feedback on this tracking issue. As a rule we are sticking to that, though we have seen and are considering some of the feedback from other platforms. If you don’t feel comfortable engaging on this thread please feel free to email your feedback to Hannah Aubry ([email protected]). We will not join or sign up for any general-purpose, private communities to discuss this RFC because we can’t be sure of moderation practices in those spaces, and therefore can't guarantee our employees will be safe there. Process We’re a new team learning to fly the plane as we build it, and AFAIK, this is an entirely new plane model for AWS. (Community governance for an AWS open source service/single-vendor OSS project, that is.) We appreciate your feedback to help make this unprecedented mechanism better, and your patience as we build out mechanisms to support it. The RFC process is not built to discuss this kind of change, but it’s the only process we have for proposing and discussing changes of any kind, big or small, to CDK. If we decide to move forward with this Council, we’ll work with the Council to figure out where we move these kinds of conversations, and the best process for this kind of discussion. Intent Given that we spent a long time researching, discussing, and stress-testing this idea and others because we did not want to propose an idea we couldn’t get behind ourselves. We’re cautiously optimistic that this idea can work, and be improved, with the community’s buy-in. Of course if people overwhelmingly don't want it, we aren't going to move forward. Can you imagine throwing a Contributor Council party and nobody shows up? 🥲 But we're not getting the impression that's what will happen if we move forward. The impression we're getting so far is that most people are cautiously optimistic. Most people have some reservations and questions about how it will work. And there are a few people that feel strongly this should not happen. We're listening to and weighing all this feedback. Again, almost nothing about this is set in stone! There are areas that we left vague intentionally because we did not want to be prescriptive about them. Voting and community representation are great examples of that (more on that below). We knew you all would have different perspectives and ideas to make those parts of the Charter better. Really, we don’t want to be prescriptive about any of this, except that AWS controls the release process and AWS controls how we spend our resources. (By the way when we say resources, we do mean our people’s time, yes, and we also mean our budgets.) Project velocity Community engagement We’re not trying to take that away by introducing a Contributor Council! Rather, we want the Council to help us create more opportunities for informal interactions like that. For example, we talked about supporting #CDKDay2025. Maybe we could have it in person? We'd be interested in working with the community to organize that. We’ve talked about kicking off AWS CDK Summits too. We could potentially have the Contributor Council meetings themselves be a way for you to have those informal interactions by live-streaming them (except for the small parts that will be under NDA, of course). Let us know what you want to see or how you want to participate in that kind of thing. We have a whole form about it: https://github.com/aws/aws-cdk-rfcs/issues/new/choose To reiterate, this Council is not the entirety of our community engagement strategy, it’s just the first crescendo. We’re starting with this idea for two reasons:
Community representation & democracy Rather, most democracies are democratic republics, which have mechanisms built in to ensure equal representation among all constituencies. That is what we are trying to build here. We are trying to create a venue for discussion of major changes to the CDK, where most if not all of the people who will be impacted by those changes are represented. Today, this community is widely distributed. We have a wide and varied breadth of customer constituencies, with wildly different ways to engage with us, and those engagements aren’t visible to other constituencies within the CDK community. Yes, we have other methods for hearing from enterprise customers. No, we’re not going to stop listening to the feedback we hear from enterprise customers in other venues. We’re not going to stop listening to anyone and only listen to this Council. By the way, I don't mean to imply we are definitely going to do designated seats. Just narrating the thinking behind them. Please keep discussing this. Here’s who we mean when we say CDK community (and this is not intended to be a complete list – who did we miss here?):
While we understand there are lots of valid scenarios for people doing work with CDK in isolation, our goal is to create a community where that work can be contributed back to the project and shared more widely. We want to celebrate that hard work, and reward your passion for CDK. The Open Construct Foundation At re:Invent, we soft-launched the tenets behind this Charter to a group of 88 Enterprise customers, AWS Heroes (including OCF members), and Amazonians. We did not share the document itself with them at that time. Throughout this whole process, we were taking what we were heard and putting it into this document. We heard good feedback about our ideas from the group that attended the event. One question we heard was, “how will you ensure the Council is representative of the entire community?” So we decided to propose designating seats for certain groups, e.g. enterprise customers and the OCF. We want to be very clear on this point: the OCF did not ask us for a designated seat on this Council. After the OCF showed support of the Council in early conversations and we got to the point of thinking designated seats might be a good idea, we asked them. The OCF has done important work around aspects of CDK that we’re focused on evolving—bringing this community together, for example—and we value their expertise. We also asked if they would help us get the word out about this RFC, given their standing and reach with the community. They were kind enough to agree to help with that, and we thank them for it. Conclusion |
So, would it be ok for you to join a community whos admins and moderators are AWS employees? |
Its AWS' product, and it can do what it likes. But when all the feedback and issues, both positive and negative are not visible, the lack of visiblity can be problmatic.
In deed its not.
Thankyou for clearing that up.
Its effectively mentioned in the proposal, by using the word 'vote'.
For clarity thats not where i sit. I actually think that this shoudl not be a democractic process at all. If AWS wants a council, just appoint some people and get started. Its very similar to choosing people for a job. Its your product aws, pick your people..
Of course you wont'. Because Enterprise customers have a lot of sway. I can't remember the exact numbers but i seem to remember Vogel saying something along the lines of 80% of things are impmeneted because of customer requests.
If your going to have some kind of 'election' or vote, how are you going to identify them and make sure they are all bonafide, and not bots?
|
This is a fair question. We're thinking about how to do this right now, if you (or anyone) has suggestions, we're open to that. |
What about requiring an AWS Builder ID? |
Thats not a bad idea, but what checks are made of a builder Ids? Can you have multiple? And just having a builder Id, doe'snt make you a cdk user. |
I was out mowing the lawn, and had a moment of inspiration. How about AWS / CDKTeam create a slack community ( or pick your platform of choice ).. that you moderate? That way its a neutral and safe place to discussions.. |
Honestly, not sure, but I imagine AWS does their due diligence to ensure builder IDs are at least relatively bot-free. I dislike the concept of purity tests to prove you are a CDK user. This is open source software under one of the most permissive possible licenses, Apache 2.0, and there's really no proof you can require that demonstrates someone is a CDK user. If someone wants to go to the trouble to get an AWS Builder ID (or whatever mechanism is decided upon to validate humans vs. bots) and vote on a CDK initiative, that's good enough in my book. New users who've installed the CDK once and had a poor experience are an important and valid voice, arguably as much or more as folks who've used the CDK daily from its first version. |
"You can create more than one AWS Builder ID as long as each ID uses a unique email address. However, using more than one AWS Builder ID can make it difficult to recall which AWS Builder ID you used for which purpose. When possible, we recommend using a single AWS Builder ID for all your activities in AWS tools and services." Seems its within the rules to create multiple Builder ID's.
So, do I. Somwhere between this, and 'anyone who wants to have an opinion, even if they really dont' care', might be a sensible approach. |
|
I always thought that Stack Overflow's elections for Community Moderators are handled really well. Voting rights are obtained by reaching a certain amount of reputation. Granted, they have the benefit of owning their own platform. Other examples can be taken from many western multi-party democracies. Parties may use direct membership votes to determine candidates or party leaders. However they don't want non affiliates to interfere in these elections. So often a cutoff date is imposed, on which a certain (membership) requirement has to be met. This seems to effectively prevent signups just to participate in a specific election.
I don't like these either, however the proposal is not for a CDK Users council. It's explicitly for a Contributor Council. I think we can derive a much smaller electorate from this. Though contribution is a very wide and undefined term, we might come up with a reasonable wide definition that doesn't include the whole world. Like any GitHub account that had an interaction with the CDK repo in the last 3 years. It could include multiple platforms as well, although we then have a problem with multiple votes again. |
AWS CDK is an open-source software product whose source code is hosted on GitHub, where a significant(?) part of the discussion related to contributions also takes place --> it should be safe to assume all AWS CDK contributors have GitHub accounts. Thus, we should be able to derive the definition of contributor from GitHub’s definition of What counts as a contribution:
Which comes really close to:
|
I think that is a fair assumption. Its not perfect, but perhaps the best of a lot of non perfect ones.
Yes. However, I would suggest that if you went down this path, you'd need to define it slightly tighter. Github account that had an interaction with the CDK repo before 1 July 2024. This is important so you dont' create a situation where folks could create phantom voting rights now the idea is being discussed, and the 1 July 2024 date comes from a point which is probaby before this document and the ideas of a code council existed. All that aside, what is gained by 'electing' people. Its a whole lot of effort, drama and angst. AWS should just appoint some people. Lets get real everyone. Andy Jassy does not run AWS by democracy. |
|
What are the key success measures? AWS is an org that measures everything. So, this should not be a difficult question. How in 6/12 months how could you measure if it's worked? |
|
Just stumbled on this today. Glad somebody sent it my way. I think, in general, I'm a big fan of this kind of a system. More community engagement, more formal engagement, and representation across the different segments of the community is likely a benefit. Having read through the RFC, I can't say I have the same FUD concerns that I see expressed here. I tend to bias towards "the good in people" and trust that the intentions of the people pushing for this are coming from a positive place. That doesn't mean that things can't go wrong, and change is always risky. But the RFC is, at least, a best effort to address some of those issues in a reasonable manner. I do agree, that election of the members is a bit challenging. It will, effectively, require campaigning of some form. But maybe it's the worst system, except for all the rest. Appointment would likely be more efficient, but it's just a different form of popularity contest. I think, too, that realistically, the first year will be a lot of getting the Council's feet wet. I wonder how much impact will really be had, and a limited set of goals is likely the right path. What I seem to takeaway from the RFC is that the goal here is to help get the voice of the community (as represented by the Council), in order to help steer the macro direction of the project. It doesn't seem to preclude the continuation of changes, contributions, issues, etc... via the micro system that's in place right now. This appeals greatly to me. I'm into this idea and curious about how it will take shape. Kudos to the team for taking the step. I recognize the hesitation in the voices of some of the folks in this thread, but I suggest we offer the benefit of the doubt, work with the group to help shape what this thing is, and revisit it all in a year when we see what it really is. |
We'd probably want some rules around campaigning and keep most of the main community platforms neutral. I could see candidates getting limited space on the official GitHub to introduce themselves and their goals. Or put it somewhere (semi-)official. I could see a hosted video call and/or townhall with all candidates. I personally would probably discourage, if not outright ban, any non-sanctioned campaign posts on cdk.dev and the GitHub repo. Of course we cannot (and don't want to) stop people campaigning on LinkedIn or other external forums. |
The effort required to build a democractric system that would be useful far outweighs the value it will ever return. Appointing people would give you good people, not popular people.. Is Popular better than good? |
|
(1) How will aws be able to support and maintain the additional code that the community creates when its in aws-cdk-lib, when it has historically not been able to. 1b. Will support for that code be sourced from the community has well? (2) How will users of CDK, know if code is 'community sourced' or was written by AWS? I share a concern with several of my customers, about this. While we can trust aws code, we don't' trust code from sources where there is not a contractual relationship with it. Could the community source code be put into a separate library so it is clear where it was sourced from? Then its easy to identity can folks can easily choose if they want to use it or not. |
I think I'm generally in agreement here. Though I will admit that I am biased as I'm part of a sizable enterprise and have inroads to relevant voices at AWS. I could probably "campaign" to those people instead of the community. It would be FAR less effort, and maybe even "fair" in the sense that if I have this kind of access, I might be the right person for the role. I'm not sure how this translates to others representing other sized businesses or interests. |
Yes. It's the same code base. Why would it be treated differently? The project is an open source project and its support is what it is.
I would bias away from bisecting the code based on who contributed it. That doesn't happen now, so why should it happen then? When it comes to trust, I'm most concerned with Lambda code written for L2 constructs as that's a possible source of attack. From a reliability perspective, for the most part, testing should be able to prove out that the constructs do what they're supposed to do, and holding testing standards high should be (is?) a part of CDK's contribution guidelines. I don't think the Council's existence changes any of the current patterns of development or management of the CDK code. It's simply a mechanism to prioritize and triage work. When something is marked as "done by AWS" that likely means it's done on a more reliable timeline. If it's marked as "done by community" then it needs to be advertised as "Hey, person who wants to contribute, have you considered THIS thing to build?" Regardless of the source of contribution, there should be an identical review process which holds standards high, ensures reliability and security, and maintains the quality of the CDK code base. It should be, as it is today, transparent as to who wrote what code for CDK. |
CDK is a product offering from AWS, that customer pay for support, when they have an enteprise support contract. It might be opensource. But support is paid for. ( and enteprise support is a big cost item ). Its support is contractually defined. Paid for. the CDK team have not been able to keep up with the volume of AWS products, as it sits. If the community starts providing code for lots of the 'gaps', how will the cdk team provide the support for the large scope of products. Having community contributions ( bigger number of things to support ) only increases the problem, unless in parrallel with this iniative, there is also significant increase in the resoruces that AWS is deploying to CDK.
Because its likely to be less supported by AWS. And making that known upfront means you've got the choice to use it or not. I have a choice now not to use alpha code, its well labelled. Its well udnerstood that if you use alpha code, that you may run into issues and there may be no answer. |
|
I favor appointing council members based on getting input from a diverse background over the popular vote. I develop AWS CDK code for multiple scaleups and midsized companies. My customers and I have difficulty giving feedback to AWS or AWS CDK. I have not found a reliable way to provide this either through TAM, Support, AWS Health Scaleup coaches or public roadmaps. We have a different perspective on the usability of AWS and CDK than enterprise because we have limited resources while we have the same challenges of building well-architected AWS infrastructure. For example, AWS Config looks amazing in automating compliance on AWS. However, implementing it requires a lot of custom coding in AWS CDK to deploy it correctly and custom AWS config rules to get good config rules. In an enterprise environment, you have more capacity to deal with the lack of out-of-the-box functionality. I would expect there to be more perspectives on the use of AWS CDK, and the council would benefit from capturing a diverse background if there were only a limited number of seats. |
Description
To improve visibility into CDK, increase feedback opportunities, and build a stronger, more inclusive community, the AWS CDK team proposes forming a Contributor Council.
Roles
Next Steps
This RFC kicks off a period of community input about the Council and its Charter, which will last for 30 days. On February 10, 2025, we will incorporate the feedback shared on the tracking issue and ratify the Charter by merging it to the CDK repository.
The text was updated successfully, but these errors were encountered: