One of the interesting things about AWS Firecracker is that it is (one of?) the first OSS projects *originated* by AWS. It will be interesting to see how outside contributions and community are curated. Some comments after a 2 minute look at the repo/docs:

First, there is a Code of Conduct (github.com/firecracker-mi…). It is very corporate though where violations are reported to an amazon alias. If a real community forms it'll be interesting to see if this shifts to be a community driven thing.

The MAINTAINERS.md (github.com/firecracker-mi…) lists the Amazon team working on it. Doesn't look like there is provision for external maintainers.

There are clear guidelines for contributing. These list out the typical workflow and expectations of a PR. See CONTRIBUTING.md (github.com/firecracker-mi…).

One thing missing from firecracker is either the DCO or a CLA. This is very surprising! One of these is typical when accepting any outside contributions. I expect to see this fixed ASAP once external PRs start coming in. Will be interesting to see what they pick.

(FWIW, I'm not a fan of CLAs that are owned by commercial companies. It gives the company free reign to re-license in the future and dual license. The chrome VMM base will prevent that in this case and isnt' as big an issue with Apache 2.0. IANAL tho.)

Summary of Firecracker from OSS community PoV: looks like a great start but some missing pieces. Clearly not going to be community driven (like k8s, Apache, OpenStack) but rather vendor driven. Not "throw it over the wall" OSS though (chrome, android). Looking forward to more!

Oh! One thing I forgot -- there is a pre-submit check on PRs that leads to an AWS login screen. Looks like you have to be an Amazon employee (or have an AWS login?) to see the presubmit checks?

Kubernetes had (and still has but is working on it!) the issue where the OSS block and tackle was still overly tied to Google internal systems. It has been super hard to unwind that over time. Hopefully they'll run all the build/release/test infra for this in the open too.

I am sure @arungupta will work with the team to sort out these issues out, as you say it takes time. Personally I am over the moon some of this tech can see the light of day outside amazon so people inside can be a part of the greater community.

Yep, feedback accepted, will work with the team to sort them out! // @anliguori

It's not using internal Amazon systems, it's using publicly available AWS services like CodeBuild. It's not the intention to run this behind a curtain, and all of the build infrastructure is set up in a way that is could be run through other services like Travis CI if needed.

Sorry for not being clear. But, regardless, you have to be an Amazon employee to see that, yes? We had the same problem with k8s where some of the project block and tackle required you to be a Googler (even though it used GCP).

A lot of effort in k8s went into building infrastructure from the ground up that scales, is maintained by the community and is as open as possible. Check prow: github.com/kubernetes/tes… and prow.k8s.io

Obviously something like Prow is *way* overkill in this case. But the fact that pre-submit check links send make to a login page sends the wrong signal from a community point of view.

Well, I'm an Amazon employee and I can't see the log that was generated. The link goes to the CloudWatch log for the build, but it doesn't give me a clue about what AWS account it lives in. An easy thing to do is just push the logs to a public S3 bucket.

And so it starts wrt building your own CI/CD system that is OSS friendly. FWIW, pushing logs to GCS was one of the early steps for k8s :) Will be interesting to see how this evolves!

We will fix that. There are some technical challenges as most popular open source build platforms don't do nested yet. Yeah, I know nested is useful here :-)

The funny thing is that I'll probably use desktop VMware or GCP to play with it because I don't want to pay $5/hour to play with it on AWS. I really do think that nested will become a critical feature here. Not everyone will run on metal.

Definitely not "open source in license only." The people who are named maintainers today are payed by Amazon. The project will be shaped by those people and Amazon's peculiar ways. So, rather than community driven or vendor driven, I hope this will be a customer driven project.

"Customer driven" in this case sounds like marketing BS. At the end of the day who controls the roadmap? Who decides where the project goes? Who defines what he customer is? That's all amazon (for now). And that's okay!

The customer thing is my own philosophy on how I would like the project to be run, but I can see how it could read like marketing. It means working backwards from customers, and applying some of the mechanisms we use internally at Amazon to an OSS project.

For example, the changes I made in github.com/firecracker-mi… were intentional. Adopting tenets is something we do inside Amazon any time we're embarking on a new journey.

Don't get me wrong -- having tenants and an idea of what and who the project is for is critical. And that is being driven by Amazon (for now). Giving that up to the community is super hard. It requires deep thinking about governance and who has standing to influence project.

And you can't do that stuff too early. You need a core community to form before you can hand things off to it. But you can signal early on that you are serious about building something that goes beyond AWS.

A good place to start might be examples/docs on how to launch/use firecracker on other clouds. That starts to establish the idea that the technology isn't tied to AWS. That can be super tricky inside of a company though.

There will be other more subtle signals. If you set up a community call will you force everyone to install Chime? Because the only people that use Chime are Amazon employees and it is super buggy last I tried. K8s started with hangouts but then moved to zoom.

There are POTS dial-in numbers for Chime... And full VTC is working very nicely from Chrome running on my Ubuntu laptop, nothing extra to install. But I hear your feedback, and you bring up a number of points that we have some deep thinking and discussions about already.

If you are using a POTS dial-in number you are talking to lawyers. ;)

If you needed more encouragement, GCE supports nested virt, so firecracker should work all the way down to an f1.micro (although I wouldn't necessarily want to run it there :)

I know! I'm going to look to get it working. But the instructions look like you have to spin around 3 times counter clockwise and say "nested vert" while facing north. It should be easier or on by default. It is on Azure I think.

Try these instructions (minus the Kata bit): github.com/kata-container… (also tell me if anything doesn't work -- I own that doc :)

Yeah -- it is just the "create an image" bit that is strange. Modeling the nested virt capability as a license string seems like a hack. Is it because plumbing a new option through the API/console/gcloud is just pure pain?

I’m curious how it goes. Report back?!

If you wanted to build something that could be access controlled for project whitelisting, usage counted, VMs running with it could be found easily, etc. you'd end up with something a lot like licenses, but you'd probably give them a different name.

The most well made plans for the perfect API often grows warts over time.. :-)

For sure. But it just feels strange to attach that capability to the image vs. some property of the instance. ¯\_(ツ)_/¯

Indeed, and sadly this is how AMI properties work too (ena-support set to true changes instance features when you run that AMI). But now we have CPU options for EC2 (like disabling hyperthreads) that could be used for nested support in the future...

(so yup, it's a hack, but it's a convenient hack that has all of the properties you might want as an operator -- it certainly more user friction than one might hope for, but it was initially a niche feature, so tradeoffs, etc.)

I hope that everyone we interact with will influence the project in some way. For high level mechanisms like tenets to set the direction, we welcome feedback and suggestions from anyone.

But that is my point. "Feedback and suggestions" isn't community driven. It is still Amazon driven. But also that is ok and appropriate at this stage. The question, IMO, is signaling when/how/if that might change and those can be driven by non-AWS folks.

Concretely, Kubernetes, for example, has a steering committee with limits on company representation. That sets the tone/charter for the rest of the project. We delegate power to other groups run by the community. No one (google, red hat, etc) can act unilaterally.

You can't do that from day 1. But you can start to give more power to external folks. Your first external maintainer is probably the next big step.

Irony: the "throw it over the wall OSS" that is Chrome includes crosvm, from which the Firecracker codebase is derived (branched? forked?)

There is even a policy for security disclosures already in place:

This wasn't the best wording. I assume you don't mean the CLA being owned (written by company) but rather copyright assignment to a company being problematic. For example, Google wrote its CLA but it doesn't require copyright assignment.

Perhaps my wording is bad. But most CLAs (I think!) allow the entity that is assigned to to re-license. In the ~GPL world this allows dual-licensing. While there is no copyright assignment the copyright license is *super* broad and allows sublicensing.

And I mean CLAs for code contributed to a commercial entity vs. CLAs for code contributed to a foundation. For me, CLA makes much more sense for the CNCF than for Google. Doing work and giving it to google under that CLA is giving away too much IMO.

Good point about sublicensing. Agree with GPL I'd be more concerned. Generally Google's projects are Apache or BSDish so hard to take away rights with relicensing.

I'd like a CLA revocable on license change. So if Google has to relicense for compatibility, don't have to get confirmation from every author. But if they're doing it to manipulate, I can tell them "not with my code!"

Is that ~ a "bitwise NOT" or is it "approximately"?

Ha! Approximately. :)

I thought the ability to close/relicense commercially that was one of the big appeals of Apache V2 licensed for some corporate users (eg not copyleft). The ASF seems to state it can also go the other way (relicensed in a GPL project). But of course IANAL.

You can't, for example, apply gpl to an Apache 2 project. Just to any changes moving forward. It is all super confusing and ianal too.

That sounds less than fun. But the point more being, they could probably make a closed source derivative work within the framework the Apache license without necessarily needing CLAs?

Yeah. Anyone can make a closed derivative of an Apache 2 project. As such the cla issue isn't as big a deal practically. It IS a bigger deal with gpl projects.

The last bullet of github.com/firecracker-mi… is intended to be a lightweight DCO. If anything more is needed, I expect we would simply use DCO.

Ah! Good to know. I missed that! I was going to check the pre-submit checks for that but they aren't public. I do see that all of the existing PR commits do have the signed-off-by.

One of the the things we learned at @heptio is that folks can often be confused by the "-s" stuff and it is tricky to apply after-the-fact and re-push. Some more help on how to do that will probably smooth things for users. Newer git makes it easier:

That's not an oversight. We generally don't do DCO. If others in the community are eager for it I don't have a problem adopting it.

We would love to have external maintainers :-)

Good to hear! Might be worth thinking about what those folks would look like and what they'd have to do to get there. Also pre-clear it with the lawyers and such.

Yeah, I think all communities are really trying to figure this out. We wanted to have something from the start but if we are successful in the long term, I would love to have a community based mechanism here.

It is a great start! And I love seeing a CoC from the get go. These things are *hard* though. Like *really* hard.

OMG thank you. More of these. SoundCloud?

Great breakdown.

Worth keeping in mind that it is a fork of Chromium’s crosvm

Yeah - I recognize that when talking about the license and the lack of DCO/CLA further in the thread.

But it is clear that this is a pretty deep fork with a different purpose so I guess it is new enough IMO to establish a new community.

Thanks for the feedback! It is an open source project, we’ll actively listen to community and customers actively and evolve!

I’d just congratulate you and @adrianco on making OSS bigger at AWS — expands everyone’s world....

Thanks, exciting times to be at #AWS!

Firecracker is awesome but AWS Amplify has been an OSS project for just over a year now with a lot of community involvement and completely originated in AWS

Not an expert there but it looks like Amplify *only* works with AWS backends? If so, I view it as more of an SDK vs. a core technology like Firecracker.

Nope, it's designed to be independent. Much of the implementation is for AWS backend right now but the category design is pluggable. For instance Auth0 can be used for some auth pieces instead of cognito, you can use generic REST or GraphQL endpoints with API component, etc

Well, the getting started docs start with creating an AWS account so it looks like a SDK to me even if things are pluggable. ¯\_(ツ)_/¯ aws-amplify.github.io/docs/

You have to give customers somewhere for getting started 😃, and it's not just a client lib but also toolchain for codegen, backend automation, etc