I know that not everyone gets to see "behind the closed doors" of a company like Elastic, but I might shed some insights as to conversations we've been having here, since I think it may aid in transparency.
Before we even set off to have a proprietary "Elastic License", one set of conversations was that indeed, we wanted to be really obvious about our license allows/doesn't allow someone to do. For example, I know license.txt files are difficult for most of us in software development to parse, but we spent a lot of time honing our license to make sure it was very permissive relative to many "closed source licenses" and even include an e-mail address in the license if someone wanted sure and needed to get some validation that what they're doing is OK/not OK. I'm sure some people will argue that any non-OSI-approved license is out of scope for this conversation (and I'm not wanting to start a war on license files here), but I did want to point out that we went all the way down to thinking deeply about a very permissive/understandable license file relative to others I've seen, and we didn't do any of this until we felt that was in a pretty good place.
One of the things that permeates to the next level down of transparency is that we did want our development to happen in the open as much as possible. We used to have all of our proprietary code in a separate, private repository and we found that it was a bad experience for several stakeholders. Our users and customers didn't get to file/track issues themselves but instead had to rely on our support team to be a proxy. That was especially bad for the users of our free (but commercial, a.k.a. our Basic Licensed) software, which had to file issues on this forum which then went away into a private repository that they couldn't track, etc. It also led to development headaches internally: building source and CI from multiple repositories that had to be checked against one another. Simultaneously we also had explicit asks from several of our users / customers to contribute Elastic Licensed code, particularly when it integrates with another Elastic Licensed feature. I know that sounds funny for a lot of people, but there were a variety of instances of it, including additions to features that the user didn't want to maintain the code themselves long-term. We also get requests from users to audit our commercial code or have our software provided to a 3rd party software escrow, which caused another set of issues. Having our commercial (including the free) software open (and developed in the open) helps to achieve a great number of things with our users.
You've pointed out a potential downside that we recognized as well (and have attempted to prevent, which I'll talk about) to all of the code being open, which is that you could stumble on commercial code/development. We've striven to make our software as transparent and faithful to the community as possible through a variety of mechanisms to help avoid this problem. On the binary artifact side, we've continued to produce an Apache2 licensed build on a separate page/as a separate download that we continue to release (in various binary forms). On the code side, we've tried to deal with this by putting things inside of a dedicated directory (x-pack) so that you can easily exclude it if you want to.
The GitHub/discuss issue side is admittedly probably the hardest problem to deal with, and one we're thinking about a lot: if a community member comments on an issue and we're still in ideation stage on whether/how we'd do a feature, does that constitute that the feature needs to be OSS? If someone posts on our forums or talks to us at a conference about an idea? What if it's a commercial customer at a conference explicitly trying to ask for an enhancement request or a commercial customer that just doesn't care about the license? Ideas come from all over the place and I'm sure you can imagine the nuance to defining what conversations constitute significant contributions vs something that's "hard" like code. It's something that's a really tricky line to walk and there's a lot of grey area. To be clear, I'm not being defensive: it's an area I think we can still get better at to avoid confusion, and as Steve mentioned, this thread has started some great conversations -- both on this thread and at Elastic -- about how we could be more transparent and faithful to all parties. We're thinking about e.g. tagging on GitHub and other mechanisms we could potentially use to improve the awareness throughout the process. I hope this comes across as us not shutting down conversation but instead trying to improve. We've really been trying to be more transparent with everyone, though we've had some stumbles along the way (like all software). Changing the license of an experimental feature was really uncharacteristic for us -- I hope you notice that we don't have a history of "bait and switch" so to speak, but even so, as Steve mentioned, we're working on ways to prevent this type of thing from happening in the future.
In any case, having a free and open licensed tier has always carried the goal of having this type of transparency with the community: to help engage communication, get feedback on what parts of the software work and what needs improvement, to help speed up our users success, and to not gatekeep all of that behind a support team that required a paid subscription even for those that just want to use the free software. We've seen generally positive feedback from our users on this and a lot of engagement and excitement around being able to participate in features they used to have a bad experience in talking about, though I do fully get that not everyone wants to participate; that's where we'll continue to try to iterate to make things more transparent.
