[coreboot] Expectations, project direction and interest of contributors (was: Changes to the coreboot Project Structure)

[Paul Menzel]

Dear Stefan, dear coreboot folks,


Am Donnerstag, den 20.03.2014, 22:55 +0100 schrieb Stefan Reinauer:
> Changes to the coreboot Project Structure
> 
> We -- the coreboot project -- have succeeded beyond our wildest
> expectations, with every major laptop vendor using our code. Going
> forward, this will require a few structural changes that will ensure
> that the vendors shipping coreboot products can count on a stable,
> reliable code base.
> 
> With that incredible success, there is also a lot of work to be done to
> make sure the project is scaling and keeping up with the requirements of
> the millions of new users that coreboot gets every year.
> 
> […]
> 
> While there is a fairly good understanding of the project direction and
> interest between those individual contributors, […]

reading these lines I realized I do not have that understanding and I am
not so certain anymore about the expectations, coreboot’s directions and
the interest.

First I find “wildest expectations” a little exaggerated seeing the
blobs (especially ME) shipped in all current Intel devices [1]. It is
even worse that these blobs are not allowed to be distributed making
building and flashing an image more difficult.

Additionally I heard claims, that the GPLv2 license is violated as it is
currently impossible to rebuild the exact same image that is shipped
with the devices as it is not even clear what commit was used to build
the image and to my knowledge the requests on the list and in the IRC
channel were not answered.

I suspect that in the beginning of coreboot even Ron and you would
not have expected anything like this to happen and not considered that
such an image meets your expectations.

So I congratulate that coreboot is used by several vendors and has
millions of users, but it is to be taken with a grain of salt. It is
also clear, that you do not like this situation either, but it would be
interesting what the expectation and direction should be.

Clearly, getting a system to boot is not the main goal as everybody can
do that with the vendor BIOS/UEFI, which, by the way, lately greatly
improved boot time too in my experience.

For Google and the laptop vendors, I guess the goal is simply to save
the money per device that traditionally went to the BIOS/UEFI vendors.
Of course the payload concept gives a lot of flexibility, which is nice
too. But in the end it seems to come down to saving money and hoping to
make more profit. I do not know, if that worked and works out and how
much more time it costs to deal with the community and reviews compared
to the interaction with the BIOS/UEFI vendors and paying the fee/tax or
with the time to deal with Intel’s management engine.

The other sad development seems to be that AMD, until now being the
company most supportive of coreboot by contributing code and employing
developers – unfortunately only in the embedded section – working on
coreboot, even *thinks* about only providing binary blobs of AGESA
instead of (IP scrubbed) sources for AGESA. Unfortunately they do not
seem to get the advantages of free software and understand free software
in their AGESA department and although being of much smaller size than
Intel, they seem already big enough to not being able to change or only
being able to change slowly.

And the possible move to blobs is also kind of understandable, as
despite being such a first class citizen, seeing that Intel (i945) gets
chosen by the German government and Google chooses Intel for their
Chromebooks and ships images with blobs. As Intel is bigger, Google
probably hired more people from Intel than from AMD. Maybe the Google
decision makers know the Intel decision makers and play Golf with each
other. Anyway, it is another datapoint that it is not about free
software at all.

So one could even say, that coreboot’s decision to allow binary blobs as
the Management Engine and RAM init (MRC) even supported AMD’s current
*plans* to go back to binary blobs as it is currently allowed for Intel.
So it is questionable if the past decisions served the project well. I
have no clue what would have been better and if this could have been
avoided at all. Nobody can look into the future. So we have to take it
as it is now, but it is clear that the opponents back then had valid
points and that such decisions can have negative long term side effects.

It should also not be forgotten that thanks to the leaks from Edward
Snowden, the current political and economic(?) situation is as good as
never before for free software and coreboot. In the Internet business,
companies in the USA already feel the consequences and loose contracts
and money when their datacenters/servers are located in the USA.

The same will hopefully happen to hardware vendors shipping proprietary
BIOS/UEFI firmware. AMD is currently the only feasible (x86) vendor and
hopefully policies are going to be implemented only allowing government
agencies to by AMD stuff with free firmware. (No idea how much the IT
personal is educated and who is in charge for these decisions and if one
can sue/request such policies, like the tax agency has to use AMD
hardware with coreboot to adhere to privacy concerns.)

So there is hope and a chance for coreboot to get rid of these blobs
once and for all.

So what are the expectations for the next years? What directions should
coreboot go? I am interested in your views. Especially from the
benevolent dictator and other old term contributors.

In my opinion, we should get the first AMD laptop supported as soon as
possible as currently only Intel laptops are supported, so there is an
option on the market government, people and companies can buy if they
are interested. In the IRC channel #coreboot on <irc.freenode.net> [2]
such things are discussed already and there might be even volunteers.
This should be discussed in a separate thread though.


Thanks,

Paul


[1] http://www.coreboot.org/Binary_situation
[2] http://www.coreboot.org/IRC

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140325/c80511e9/attachment.sig>