Development
OpenStack and "open core"
The "open core" model, where certain features are reserved for an "enterprise edition" that is not open source, is not particularly popular with a large segment of the open-source community. There are certainly businesses that rely on the practice, but the ideas behind open core run counter to the ethos of open source in many ways. The OpenStack community has recently grappled with the definition of open core, which is explicitly disallowed as part of the project's principles (the "Four Opens"). It is not a simple question, as there are clearly gray areas, some of which came up in the discussion.
In early February, OpenStack technical
committee (TC) chair Thierry Carrez posted a
question to the project's development mailing list: what does "no open
core" mean in 2016? The policy was adopted in 2010, when Rackspace was
the sole owner of OpenStack, in order to differentiate it from Eucalyptus,
which was another open-source cloud platform that was pursuing the open-core strategy. It was meant to send "strong signals that we would
never follow such a strategy
", which was "essential to form a
real community
".
But things are far different today, Carrez continued; there is a non-profit
foundation at the helm, but there are also components that are proprietary
and closed source being sold by member companies in their "enterprise
editions". There are "drivers that expose
functionality in proprietary components
".
(That situation led Bradley Kuhn to recently state that
he knows of no OpenStack distributions that
do not have at least some proprietary pieces.)
Those pieces are clearly
not a part of the OpenStack project, but
how does that all mesh with "no open core"? He gave his view:
As he and others noted, the definitions of "fully-functional" and
"production-grade" are
somewhat unclear, but Carrez thought his take might make a reasonable starting
point. While he didn't mention it specifically in that post, it became
clear in the
thread that there is at least one project that may fall outside of those
boundaries. Poppy,
which is not an official part of OpenStack but is part of the wider ecosystem,
provides an interface to content
delivery networks (CDNs) so that OpenStack installations can offer
CDN-as-a-service. The problem is that there are no viable open-source
CDN implementations, which means that it requires "proprietary
software or a commercial entity
" to use—or even to test.
Interoperating with commercial services is not typically seen as adding open-core functionality, exactly. As TC member Doug Hellmann put it:
There is a moribund open-source CDN in the OpenCDN project, but a
CDN is far more than just code. Ryan Brown pointed that out: "Open source projects aren't usually set up around making big capital
expenditures and buying lots of bandwidth, so the lack of a FOSS CDN isn't
exactly Poppy's fault.
" But even if there were an open-source CDN,
and Poppy supported it, would that be sufficient? TC member Flavio
Percoco raised that question:
There was some talk of having Poppy provide some kind of "reference" open-source CDN, but that is not really something that the Poppy project wants to take on. There is no existing project to use, but there is more to it than that, as Poppy project member Amit Gandhi noted:
Poppy intends to be an abstraction API over the various CDNs available. We do not want to be in the business of building a CDN itself.
But OpenStack projects need to be able to be tested using the umbrella project's infrastructure. That will become problematic without an open-source CDN, as OpenStack Foundation cross-project developer coordinator Mike Perez explained:
But Hellmann doesn't see Poppy as being all that much different from other OpenStack pieces:
The *only* difference is that because of the nature of a CDN, running one yourself isn't practical and so there's no significant (or viable) open source implementation.
But without some support for an open-source option, Sean M. Collins argued, Poppy doesn't really fit into the OpenStack project:
Yes, it's a lot of work, but without that, as I think others have stated - where's the OpenStack part?
Carrez circled back to the more general question of defining open core for OpenStack on February 22. He considered some alternate wordings from his original post, but worried that those left the door open to real open-core services in OpenStack. In the end, he suggested that perhaps it was best left up to the TC to decide what open core means on a case-by-case basis. That idea seems to have won the day—no real opposition to it was heard.
Meanwhile, the Poppy question came up at the TC meeting on February 23 (log). While some were not convinced that Poppy was open core in the true sense of that term, it was still not accepted into the OpenStack project. In a close vote, seven of the thirteen members felt that it still didn't meet the requirements to be included. It can still be hosted using OpenStack infrastructure, but will not be an official part of OpenStack.
That situation may change, especially if Poppy comes up with a way to be tested and tried without requiring proprietary services. It seems clear that the project is not intended to sell any additional OpenStack components—which is a major part of the objections to open core—but it still doesn't quite live up to the "open" in OpenStack.
Brief items
Quotes of the week
OpenSSH 7.2 is available
OpenSSH 7.2 has been released. While this update is primarily a bugfix release, it also disables, by default, several algorithms in the ssh client. The disabled ciphers include " Version 2016.02 of the Buildroot build-automation toolkit has been released. The update adds support for GCC 5.3.x, configuration support for several new boards, and support for MIPS Codescape toolchains. Notably, this release also drops support for legacy uClibc, in favor of uClibc-ng.
blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES
", while the disabled hash algorithms include all MD5-based and truncated HMAC algorithms. The algorithms in question were already disabled in sshd in an earlier release. The announcement also notes that a "
near future
" release will refuse all RSA keys smaller than 1024 bits.
Buildroot 2016.02 released
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (February 25)
- What's cooking in git.git (February 26)
- What's cooking in git.git (March 2)
- LLVM Weekly (February 29)
- OCaml Weekly News (March 1)
- OpenStack Developer Digest (February 26)
- Perl Weekly (February 29)
- PostgreSQL Weekly News (February 28)
- Python Weekly (February 25)
- Ruby Weekly (February 25)
- This Week in Rust (February 29)
- Wikimedia Tech News (February 29)
Lord: The case for an embeddable Gecko
At his blog, Chris Lord advocates
for developing Mozilla's Gecko web renderer into an embeddable
engine—something that Mozilla has long resisted. He lists a
long series of disruptive technologies (starting with the original
iPhone in 2007) that have made use of open-source embedded web
runtimes—all of which, of course, went with a project other than
Gecko and, thus, represent missed opportunities. "It’s hard to
predict what the next technology trend will be, but there’s is a
strong likelihood it’ll involve the web, and there’s a possibility it
may not come from a company/group/individual with an existing web
rendering engine or particular allegiance.
" In conclusion, he
argues, "if we want to form the basis of the next big thing, it’s not enough to be experimenting in new areas. We need to enable other people to experiment in new areas using our technology.
"
Malcolm: GCC 6: -Wmisleading-indentation vs “goto fail;”
David Malcolm takes a look at a new compiler warning in GCC 6, -Wmisleading-indentation. "At a high level, the underlying implementation looks at control statements (if/else, while, for), and if it sees them guard a single statement without braces, it looks at the followup statement. It complains if both have the same indentation. That’s a simplified description – we spent a fair amount of time working on heuristics in the warning, to try to ensure that it warns for all cases that are reasonable to warn for, whilst not complaining unduly for indentation that’s merely bad (rather than being actively misleading). We’ve also tested it with a variety of coding styles: GNU, K&R, Linux kernel, etc."
Page editor: Nathan Willis
Next page:
Announcements>>