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. |
|
This comment in linked in is telling me that some folks wont even engage because they feel the process is so bad.
|
|
@haubles , for clarity, my previous comment about agendas was not directed at you. If it came across that way I apologise. I do most definitely feel like an agenda is being pushed by a certain group of people, who are pushing their opinions and perspective very strongly. |
Other major open source projects offer support tiers. Which part of this RFC suggests that supportability is not important or will degrade? It's mentioned explicitly as the first item under
I'm unclear on the correlation between increased headcount and a direct increase in new L2 constructs. Do you have a reference for that somewhere? Related to L2s, I use a vanishing number of them in production as the years go by, because they are often extremely opinionated solutions that lack flexibility for key requirements that shift with my customers. This is always going to be a balancing act with L2 and L3 constructs. The product teams will not necessarily have some special insight into how an L2 should be built for specific use cases, and I've often heard from AWS users and employees that they learn new ways to use their products from their customers. That's customer obsession. The community is the customer. I am admittedly biased towards (F)OSS solutions so take those opinions with that grain of salt in mind. |
no, I just am making an observation, that i've heard AWS has increased headcount in CDK, but in a similar time frame i dont' see any increased number of constructs. I do somewhat agree with you about L2's.. I have to create most of what i use. The lack of useful constructs for most networking things,, (lattice, transit gateway, direct connect , vpc ) have meant i've had to go and create my own. |
|
I agree with your points (a to e) and would hope that these would be BAU (business as usual) for AWS. If we were to have no council, AWS make all the decisions (as they currently do) with whatever influence engineers can have through various channels we may be aware of.
|
|
Hi friends. As a reminder, CDK (like all AWS open source communities) is subject to the Amazon Open Source Code of Conduct. Please be mindful of your tone, your rate of posting, and ensure that you are not making personal attacks or engaging in harassment in public or private. To be clear, please share your thoughts (positive or negative) here but don't harass or spam on this or other platforms. AWS welcomes comments but not harassment. We appreciate your constructive feedback, but it is critical that we remain polite and civil in our discourse. |
|
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.
|
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: