I would suggest the same industry standard maintenance period that would normally apply to a commercial, closed source product. For instance, consumer hardware might only receive a year or two of support from initial release, but an embedded system might be more typically see 3-5 years or more. Especially with the focus on using binary-only libraries with newer e.g. Intel platforms, I don't see how maintenance of the coreboot portions can reasonably be expected beyond the support period of the upstream software vendor. At the same time, if a commercial product would see some degree of maintenance, we should expect the same level of maintenance in the open product (coreboot) where feasible.
One interesting issue brought up is whether we should be expecting maintainers to rewrite large chunks of code as the underlying coreboot APIs change. This is where things differ from a normal closed source lifecycle, in that in the closed source world "maintenance" can be as simple as applying small patches to a mothballed, static codebase and recompiling. In the open source world, maintenance normally involves a continual treadmill of making sure the board support is kept up to date as the underlying codebase continually changes. While I am not advocating for the static approach, it should be recognized that continual changes do cost something, and perhaps there should be more emphasis on developers that are pushing widespread changes also ensuring that all officially supported boards / chipsets / etc. are fixed up at the same time. Just my $0.02, as a somewhat time strapped and not very good de facto maintainer of parts of the legacy AMD codebase. :) ----- Original Message ----- > From: "Martin Roth" <[email protected]> > To: "Peter Stuge" <[email protected]> > Cc: "coreboot" <[email protected]> > Sent: Thursday, May 2, 2019 4:16:41 PM > Subject: [coreboot] Re: What maintenance is expected from coreboot developers > & companies > Thanks Peter, > Is there a time limit that you think is appropriate to request > maintenance for? > > Obviously it's not reasonable to request that they maintain it > forever, but is 2 years after the initial push reasonable? 3 years? > What level of maintenance would be expected? Would we just require > bugfixes, or would adding new features to the chip be expected? Or > even just reviews of code affecting their chip? > > Martin > > > On Wed, May 1, 2019 at 10:01 AM Peter Stuge <[email protected]> wrote: >> >> Martin Roth wrote: >> > I'd like to discuss the issue of what's expected from developers after >> > code is added to the coreboot tree. >> >> Thanks for bringing this up. >> >> >> > It seems like there's a feeling >> > that if a company pushes code to coreboot, or hires someone to push >> > code to coreboot that there's an obligation to help maintain that code >> > going forward. This seems to be different than if an individual adds >> > code, but maybe I'm wrong. >> >> That's about right, at least for me. >> >> I assume that no company contributes to coreboot purely out of altruism, >> in fact I believe that doing so could violate tax code in some jursidictions. >> >> Given that companies engage in coreboot development with a resource (money) >> profit motive I find it fair and just to expect that some of that profit >> will be contributed back into the project, through "public good" >> contributions, which can include janitorial maintenance work as well as >> much-requested feature development that noone else is working on. >> >> Nobody wants to receive a code dump. >> >> Volunteer contributors tend to not have resources comparable to companies. >> And volunteers inherently tend to focus on "public good" contributions. >> >> I believe that everyone who sees the project activity maintains a mental >> balance sheet of who has taken how much and who has given how much. At >> least I do this. I think it's human nature. >> >> My expectations derive from that (unspoken, subjective) balance sheet. >> >> My experience is, however, another axis. In my experience, some companies >> give more "public good" back than they take, other companies only ever >> take and never give anything at all back, and other companies still >> will take, and try to give back, but fail to give back anything useful >> out of ignorance in the best case, and give back something harmful on >> purpose in the worst. >> >> >> The maintenance story in coreboot has been a topic before, and >> everyone (also every individual developer working for companies) >> knows that a maintenance investment is required for the code not to >> become perverted over time. >> >> But someone has to spend money on that, and noone really wants to. >> >> The Linux Foundation employs maintainers for this purpose. It might be >> useful for coreboot to also employ maintainers, but I'd vehemently >> argue *against* copying or joining the Linux Foundation, because it >> continually make things worse rather than better. >> >> One of the fundamental problems is the expectations its members have, >> another is the (legal) culture in its jurisdiction. >> >> >> //Peter >> _______________________________________________ >> coreboot mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
