Define plan for open sourcing package without open sourcing real-time-server module

[jasonrudolph]

Currently, the real-time package and the real-time-client module both list the real-time-server module as dev dependency:

• https://github.com/atom/real-time/blob/64846bc/package.json#L14
• https://github.com/atom/real-time-client/blob/c669bfb/package.json#L20

It's my understanding that we plan to open source the real-time package and the real-time-client module, but not open source the real-time-server module. I think that plan would require removing the real-time-server module from the development dependencies in the real-time package and the real-time-client module, but many of the tests in real-time and real-time-client are dependent on the real-time-server. Let's figure out how we want to address this issue.

[nathansobo]

Some options

1. Go ahead and release the server as open source as well.
2. Release an alternative reference implementation of the server.
3. Make it so open source developers can't run tests on the client but we can.

[jasonrudolph]

1. Go ahead and release the server as open source as well.

I'm personally drawn to this option. I like the transparency that comes with this option, especially given the sensitivity around people likely wondering what information we are/aren't collecting.

2. Release an alternative reference implementation of the server.

I like this as a potential long-term solution. I'd prefer not to do this in the short-term, given that doing this would take time away from the other items we have planned for the initial launch. However, perhaps we could start by open sourcing the server (which means that everyone can run tests in real-time and real-time-client and everyone can see how little data collection is taking place). If we later find ourselves wanting our server implementation to be private, we could then release an alternative reference implementation or a test harness.

What do y'all think?

[nathansobo]

Yeah, for now the server is fairly simple. If we start doing special stuff to make it scale, writing it in Go, etc, then maybe we keep it private. The problem with a reference implementation would be keeping everything in sync, but we could potentially run our tests both against the real server and the reference implementation internally. But that's ongoing double-work.