when to open source?

[jgravois]

are there any drawbacks to:

• getting this repo into a state that it can be open sourced
• adding an experimental flag
• putting out a call for public feedback
• tagging v1.0.0 once we've got something we're fairly happy with?

putting on my open source evangelism hat, i think it'd be a 💯 story to show devs from different teams across the company collaborating on a low-level tool from the ground up 'in the open'

[dmfenton]

I'm with you @jgravois let's develop this in the open from the start.

[tomwayson]

Agree, just a matter of what does this mean:

getting this repo into a state that it can be open sourced

I that means at a minimum ironing out the details of #10 and merging a PR that implements that. After that, I'm all about the public alpha.

[jgravois]

@tomwayson i was just talking about jumping through the appropriate legal (and conventional) hoops to please the admin gods.

i don't see any downside in airing our dirty laundry from the outset, from the envisioning stage, but thats just me doing me.

[patrickarlt]

Personally I would rather wait until the initial package and tooling is all worked out right now I do't think everything has been bulletproofed enough for external people to really start looking at this yet.

[patrickarlt]

I generally think that after #16 and closing #10 we should be good to move to a public alpha, but we should probably take care of #23 and #24 first. I would also say that we shouldn't release the API on NPM until we do #21. If we want to test this locally in our projects we can do it with npm link for the time being until a stable 1.0.0.

[jgravois]

i'd like to take this opportunity to revise my suggestion from the other day and recommend that we move from an alpha/beta to full blown SemVer v1.0.0 and publish to npm as soon as humanly possible.

i may be in the minority, but looking back on my own experiences i have a lot more regret about being gunshy than i do about pulling the trigger prematurely because:

• we tend to think of our projects as more volatile than they are
• hyphenated tags and stopgap hosting solutions ultimately create more confusion than (the holy grail of) stability in the long run reduces.

[dbouwman]

I second that @jgravois - npm link will not work for Hub, mainly b/c of our CI system, but also because we have ~8 devs working in this codebase, and having them all npm link this into the ember-arcgis-portal-services addon, which would need to be npm link-ed into the apps/other-addons is just unmanageable.

Thus, I'd definitely push for publishing to Npm sooner vs later, and simply stick to 0.x.x (which is really "use-at-your-own-risk") until we feel the API is legitimately stable, then do 1.0.0 and toss the code over the wall. We have done this with a bunch of ember-addons, and it's working well for us...

[jgravois]

our wise old friend @ungoldman made some great points about '1.0.0 anxiety' back in 2015 that i come back to again and again.

0.x breaks / is meaningless in SemVer

• See https://nodesource.com/blog/semver-tilde-and-caret
• In particular https://nodesource.com/blog/semver-tilde-and-caret#1-0-0-anxiety & https://nodesource.com/blog/semver-tilde-and-caret#recommendation-start-at-1-0-0
• This means moving to 1.x will make [insert lib name] work correctly with package managers and things like ~ and ^

[dbouwman]

Yeah - I fear the 1.0.0 more than I should... time to get past that I guess!

I could see (in success) us being like hapi where they are on v16.5.2

[patrickarlt]

I still see some value in holding off on 1.0.0 and doing a 0.x.0 to give us some time to validate that the public API surface area looks good. If we 1.0.0 right now we might incur a lot of breaking changes if we need to change the public API for modules that we have yet to build.

With releases like 0.1.0 the code can still be stable but it give us a little more time to break APIs if we need too.

[ajturner]

I would like to use this in a few of our projects to validate the design and demonstrate usage. I'm thinking about Cedar, Sonar, Koop for ArcGIS Search

[patrickarlt]

@ajturner I would be 100% comfortable with open sourcing this and publishing a 1.0.0 of all modules at our meeting next week if @jgravois and I can wrap up #29 and #34 (comment) this week and do a little guide doc.