1. 9

I have a project I’ve been working on for about a year now which includes both server and client code. I will definitely be releasing the client code for both the extensions and native binaries, GPL compels me and I would like it vetted by lots of people. However I am at a loss as to whether I should distribute the server binary or not. There’s business reasons like other companies coming to eat my lunch but then there’s also people finding exploits and hitting my users somehow.

I want to distribute it because I want people to be able to set up their own infrastructure for the system but I’m worried. I’ll have much less time to react if I don’t see the testing they’re doing against the server itself and since I’m working by myself I’m worried about copycats.

What would you do in this situation where you want this to be a sustainable project? Distribute the server and client code or just the client code? I already plan to make the API docs and pseudo code for each server in case they want to write their own.

What would you do?


  2. 9

    We have very little context to advise. But roughly:

    • If you have lots of users, you might have a successful project with security problems.
    • If you have no users, you have a failed project and security doesn’t matter.

    Unless security is paramount (e.g. crypto-related), building your audience is far more important and you do that by making it as easy as possible to get started.

    1. 4

      How about a ‘source available’ license? Paying customers get the source code, binaries, documentation for how to run it.

      I’d also have some copy on the site to the effect of “any interested security researcher who wants to poke around, email me for a copy of the source”.

      1. 3

        IANAL, but purely ethically speaking, if you are using GPL’d or AGPL’d code in the server, you should distribute (and may in some cases be legally required to) the server code. There are many ways of monetizing your development efforts, and it would probably help address your concerns to look at what others in a similar position have done.

        What would you do?

        I would definitely release the code (and do for the projects I’m currently working on).

        1. 3

          Recent history has shown convenience trumps nearly everything for rapidly growing something, and most ‘normal’ people don’t give a toss about open or closed source. It depends on the product, My inclination would be to release source, but that may not actually be the best decision.

          You might as well tell us what the product is, I don’t think anyone is going to copy it before you can release it. If they can maybe they are a stronger competitor and will win regardless.

          1. 4

            It’s distributed and decentralized encrypted file management. I would share more in pretty much any place that didn’t have participants with more years of experience than I do alive.

            There’s still some work to do but it occupies a useful niche that WhatsApp, Signal, Dropbox, Keybase, Telegram, Tor, and I2P don’t seem to fill. I thought it needed to exist so I’m making it.

            Thanks to you guys for your suggestions and opinions.

            1. 2

              Since you reveal some project details here in this comment, consider editing your post to include this information, so newcomers can reply equipped with more context.

              1. 2

                I’m not able to edit the post since too much time has passed. If a mod wanted to tack it on to the end as an edit that’s fine.

              2. 1

                Thanks and good luck - There will always be critical people of any project, don’t let them get to you.

                1. 1

                  Honestly, given this context, I’d open source every part of it. Especially something security sensitive, I’d always like to get more eyes on the code.

                  If you do get popular, it becomes a lot easier for third parties to audit your implementation and for researchers to investigate and test it. Additionally, if one of the goals is to be decentralized, then people hosting their own infra and even different implementations should be encouraged. imo decentralization is more than just the server you’re talking to not being centrally controlled, but also the protocol and implementation not being centrally controlled.

                  Admittedly, I have a more open-source-friendly bias, but that’s at least how I view the scope of the issue.

              3. 4

                I would just launch the client code and keep the server code locked for now. Then, in a few months, you can see how much traction it has gotten and release the server code then. The advantage is that during the months it has been launched you are able to further refactor the code and improve it.

                1. 6

                  I heavily disagree. Promises of “it might be open source later” are often worse than nothing; I certainly distrust them and am unlikely to use a project that says such things without backing them up.

                2. 1

                  Release the code and post a revenue-sharing bug bounty. Like out of first x$ you get y% or something.

                  1. 1

                    How is that remotely enforceable or binding?