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.
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!
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.
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
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.
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.
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.
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.
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?
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.
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:
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.
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