Boost sandbox proposal

[chyt]

This proposal is for contribution of the Boost project into the MicroProfile organization. Boost has previously been demoed during a hangout session and a post was submitted to the MicroProfile blog: https://microprofile.io/2019/04/18/build-your-microprofile-apps-quickly-with-boost/

A sample application demonstration Boost functionality is available here: https://github.com/OpenLiberty/boosted-microprofile-rest-client/

[kenfinnigan]

I’m -1 on this proposal being added to sandbox as I have great concerns with the idea of doing this.

Given there was additional pushback on the mailing list for this proposal, it is far too premature for this to begin work in the sandbox

[kwsutter]

@kenfinnigan I disagree. There should be no barriers to developing in the sandbox. That was the point of providing a sandbox before it becomes a proper repo and project. We can continue the discussions about the direction of Boost in the sandbox, the mailing list, and the bi-weekly hangout. But, due to the mostly positive feedback on the hangout, the next agreed to step was to use the sandbox to flesh out the proposal.

[kenfinnigan]

I disagree with the characterization of the feedback in the call. And separate to that there was additional negative feedback on the mailing list thread.

For sure if ideas are deemed worthwhile then there should be nothing stopping work in the sandbox. I'm saying it's dubious that it's an idea even worth investigating.

[scottkurz]

There was definitely some positive feedback on the call, e.g. from TomEE folks, in addition to your negative feedback Ken.

And I recognize we haven't addressed the other detailed criticisms you and others pointed out in the MP forum thread. Not trying to sweep that under the rug, but to have something more concrete to talk to when we pick up the discussion thread again.

[kenfinnigan]

My issue, irrespective of my technical concerns, is that this problem is absolutely not something that needs an MP solution. It's for that reason I'm challenging it even being in the sandbox.

The mailing list also had others raising concerns about MP even considering doing this, as it's very tooling specific and very different than portable application code.

[scottkurz]

But the MP Starter project goes beyond portable enterprise/microservices APIs to provide a better developer experience. I don't see where we crossed a line into an invalid problem domain here.

Yes, there were some objections on the mailing list such as whether the user would be stuck with a "lowest common denominator" of implementations and how a Boost project could graduate/migrate to use implementation-specific capabilties when required. There was also a suggestion that we keep Boost as an IBM project.

But we also heard enough interest to motivate us to continue with the plan to contribute to the sandbox as a proposal, to have the discussion against the code in this repo.

[kenfinnigan]

I disagree with your statements about MP Starter.

It's a project creation tool, nothing more. It's used once by a developer and never again, that's not tooling.

What's being proposed is a tool developers would use constantly, that is where it significantly differs from MP Starter and why I have serious concerns about going down this path.

[chyt]

Hi Ken, I've been following along the discussion so far and I do acknowledge that there are some technical concerns that need to be addressed. However, I disagree with your statement that "this problem is absolutely not something that needs an MP solution."

To me, it seems like there is a lot of fragmentation amongst MicroProfile developers, in that their experience can differ greatly depending on their runtime of choice. While this may be by design to offer greater flexibility, it also increases the barrier to entry by complicating the getting started experience, raising the opportunity cost of selecting a MP runtime, and fragmenting developer resources.

One of the main goals of Boost is to address this fragmentation. Ideally, we would like to create a good balance between a better getting started experience with lower barrier to entry, while not hindering the ability for experienced users to take advantage of more specialized resources or configuration. How well we can feasibly do this is another discussion, but I don't think that this isn't something worth pursuing. Isn't it reasonable to say that providing a simpler getting started experience between runtimes will attract more developers to try and potentially adopt MicroProfile?

[dblevins]

No comment on the PR at hand. My questions are really around what the goal of the sandbox is.

My understanding of the sandbox was that it could contain any ideas, even if someone thought they were bad, and that basically any PR would be accepted unless it was obviously spam.

Specifically, that it wasn't entering the sandbox where we scrutinize, but leaving the sandbox is where we do that. In short, you're welcome to play here, but be warned, you may never leave unless you get proper buy-in on your future proposal.

Seeing a proposal to enter the sandbox feels off track. This is the place we deemed for working on proposals for future MP projects.

Seeing rejections to entering feels off track. This should happen on attempts to exit.

Are we ok with providing a place for people to play even if someone doesn't (yet) see value in the idea?

[Emily-Jiang]

+1 @dblevins @kwsutter ! This is exactly what I understood when we created the sandbox. To iterate what being said already, there is no barrier to enter the sandbox. We also agreed we are free to merge in the PRs into sandbox. It is merely a playground so that the community can join in the discussion. At the end of the discussion, one outcome is to create a proper repo while the other one is not. I don't think we should waste any more time to argue about this PR entering the sandbox.

[hutchig]

I believe the current process for sandbox use is documented here: https://wiki.eclipse.org/MicroProfile/FeatureInit it says “an intentional zero bar to entry to capture ideas when time permits, from anyone.”. I recognise and respect that some people may carry more influence in issues of governance than others but this influence is best flexed by changing our way of working by due community process rather than downvoting individual sandbox proposals.

[kwsutter]

Thank you, @hutchig, on pointing out the "zero bar" wording in our description of the sandbox. And, thank you, @dblevins, for some non-IBM support... :-) In order to make some more progress in the sandbox, I'm going to go ahead and merge this PR. Thanks for your patience while we worked through the process.