On Wed, Jun 06, 2007 at 03:03:03PM -0400, James Carlson wrote: > Casper.Dik at Sun.COM writes: > > For one, closed source can export public APIs and the Open ARCs may want > > to have something to tell about them. > > The APIs are just the tip of the iceberg. Effectively reviewing the > open portions that share (depend on, supply, use) those APIs very > often means understanding a bit about how the closed part works. It's > not as clean a process as simply saying "this part is closed source, > so use closed ARC; this part is open, so use open ARC."
Yes, there will be design details that must leak in order to have a proper open architectural review. E.g., some component uses doors, or forks, or doesn't or whatever. Typically such details shouldn't be the sort that should be considered proprietary information, but there will be cases where they are. Ideally the process we setup will be sufficiently flexible. Disaster scenario: I could imagine a case that integrates into Solaris (with internal, closed ARC review), then tries to integrate into OpenSolaris, is told "not without open review" then the open review requires changes that would be incompatible with what was shipped in Solaris, or the team refuses to undergo open review, at which point: impasse. One solution then would be: the team distributes their stuff separately from OpenSolaris (both in Solaris and as an open source project separate from OpenSolaris). That wouldn't be forking -- the fork already exists -- but it wouldn't be very nice because then you can see different OpenSolaris distros making different choices as to whether to include the separate component or not. Another solution would then be for the OpenSolaris ARC to bite that bullet and accept the component as is or with backwards-compatible improvements. Another would be for the Solaris PAC to access the OpenSolaris ARC's backwards-incompatible changes and break the interface stability commitments made by the team in Solaris. Etc. One thing to do might be to say that all projects that undergo only closed review can only integrate into Solaris and must allow incompatible changes at minor releases or even at micro/patch releases. That would > It'd be nice if it were that simple, and perhaps it is in some > restricted cases (particularly where the closed source just implements > some standards-defined bit of functionality). There are many other That will be rare. > cases (such as, say, LDOMS) where understanding the details of the > open parts necessarily depends on having a broader view. I'd argue that your example (LDOMS) is one where the whole thing should be run openly. Today that might not be the case, but eventually it would have to be (again, unless mgmt clarifies just how much openness it wants and we build the result into the OpenSolaris charter -- I'll stop adding that caveat now). > That's where we're shoving people into a corner. As I said before, > there are multiple possible schemes you can use, but all of them have > faults. Yes. Nico --
