Hi,
while this was addressed at AMD, I feel compelled to add my 2ct to some of this.
* Peter Stuge peter@stuge.se [141106 16:07]:
As these contributions started to flow into the community many years ago, you may remember that I guessed that such rules would exist and asked *literally* what those rules were. You may also remember that there was *NO* response whatsoever.
Please keep in mind, that, even or especially in large corporations, coreboot is until this day still driven by motivated individuals rather than through corporate commitment. If the motivation, or the people go away, the communication channel breaks down. I have seen this happen dozens of times for various reasons through out the last decade and a half.
Unfortunately, by not communicating with the community, AMD has caused a significant amount of uncertanity and confusion within the project. Because community projects are supposed to be about collaboration and communication, this has placed AMD in a worse position than anyone wished for.
Although coreboot has received contributions from AMD over a long time already, it is also painfully obvious that AMD still has some ways to go until they can get proper returns on their investment in coreboot.
The problem here, in my opinion, is that firmware is only one little, important but very limited part of the whole story. Even if an individual inside of the organization, or the firmware team as a whole, gets it, they will still have to argue with the same amount of energy to the other parts of the organization as they have to with the coreboot community.
You may understand that I, as a volunteer, can only do *so* much to help AMD make the most of coreboot. I believe I have asked exactly the right questions but without dialogue there can not be progress.
That pretty much applies to all members of the community. Being on the inside of a corporation gives you a lot more information, and somewhat more influence, but not ultimately the power to shift focus away from the corporate issues to the community issues. Especially not quickly.
I think we are having dialogue, and Sage is putting themselves out there to lead this dialogue. In my opinion, the fact that these mails do not originate from an AMD email address does not constitute that we shouldn't be open to finding a solition right now in this discussion. Sure, we can turn the discussion away, stating that it didn't happen on our terms. But will this help the coreboot community, or AMD?
AMD accepted that the process of releasing into open-source would be a very large and time-consuming task.
It is obviously backwards. I wonder, if someone in those meetings suggested "let's make the open-source code our HEAD so that we only have to scrub once and worst-case only incrementally thereafter".
I can tell you with a high degree of certainty that nobody outside of the core coreboot contributors considered the coreboot repository as a possible HEAD. None of the corporate entities in this field ever has. This is certainly something to be discussed, but there are also downsides to this. I remember when we (some of Google's coreboot community) decided to move ARM development to upstream first, there was a big concern in the community. Merging community outreach into a corporate development process is a bigger task than it seems at first, particularly because contributors are diverse and can't necessarily satisfy on all fronts. Like, porting coreboot to the ARM architecture did not allow us to open up the documentation we had access to, nor dedicate time to educating the community. In fact, most effort might have gone into making sure that coreboot was an option at all, rather than staying with the status quo. And after all, there was some code to write, too.
Major corporations like AMD are perfectly capable of contributing to and even running open source projects. There are many sources of inspiration.
I would like to know more about what you had in mind here. Maybe we, the community, and the corporations, can learn from some of these examples.
AMD realized that the open-sourcing process they developed was awkward and required lots of developer and legal involvement.
I think you understand that the community is quite frustrated since many attempts were made right at the start to explain that this would be the case. Community members with any meaningful open source experience immediately recognize how resource intensive the scrubbing process would be for AMD.
Unless coreboot is running on the majority of systems out there, that is not going to change though. If we're running on more systems than everybody else, we can dictate how that process is going to look like. Until then, we'll have to convince and win people over.
The six month delay required to implement the “scrub” prevents AMD Embedded from capitalizing
But ultimately this is AMD's problem and not coreboot's.
That's a very matter of your position. As long as they capitalize more on non coreboot systems, we will have to argue our point. Can coreboot prove that it provides the better ecosystem? The better environment to create innovation? Not all of that is about capitalizing, but blaming a corporation for being profit oriented is certainly not getting you closer to wide spread adoption.
Please remember that AMD’s primary goal in open-source AGESA is to enable new platforms to sell more chips.
Please remember that the project's primary goal is to create an open source firmware.
Mu personal take on this is that I would rather see coreboot run 75% free on a billion machines out there than 100% free on 1000 machines. Because that will ultimately leave the project in a better place of negociating future ports and leaves the whole ecosystem with a higher percentage of free software total.
By donating AGESA as a binary instead of scrubbed open-source, coreboot becomes available
That's false. coreboot is an open source project. Binary PI is not open source, so can not be part of coreboot. If it were, coreboot's GPL would make a combination of the two difficult to use.
So maybe we need to find a common ground on this. In the past we have always accepted VGA option roms. Now we move forward to open graphics. Are we willing to sacrifice open memory initialization in order to be able to deploy open graphics initialization? In order to deploy an open source resource allocator? In order to create an ecosystem in which we can move to an open source memory initialization in the long term? Or is this a dark alley that will only lead to giving away freedom? We, as a community, need to find a way here. If we decide we prefer to run on older hardware that is 100% open on the firmware side, that's something we can run with. Maybe that's where the libreboot effort comes in and makes sure that we can make this goal a reality, while still having another part of the community open to enabling the latest and greatest hardware?
This is good for AMD and good for companies that want to use AMD’s chips.
It is however not good for coreboot, the open source firmware project.
I would propose forking open-source AGESA within the coreboot tree. What do you think … ?
Let's not be in such a hurry to make changes for once, let's try to think this thing through?
Yes, I am absolutely in favor of that.
Industry contributors appear unable to see the forest for all the trees.
I notice a trend within governments to require more transparency from IT equipment suppliers. It will take a couple of years, but those requirements will eventually bubble up also to Intel and AMD, who will have to either open up or lose market share. Things will progressively get worse for anyone who insists on remaining opaque, as industry starts adopting the very same requirements as the government.
Let's work on opening up the industry before governments get the hang of it. While it is a great opportunity, the one thing that, in my opinion, moves slower than corporations, is governments. No offense to any governments listening in on this ;)
I predict that whoever opens up first has a great advantage in winning contracts over the next 5 years, but what do I know.
My prediction is quite similar. But there's also the part of me that knows that if coreboot only runs on a 6+ month old piece of silicon, it will not be adopted, and hence not be in the position to discuss the needs of the community.
Stefan