Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: Building an Open Source Community For a Proprietary Software Product?

Posted by Soulskill on from the if-you-free-it,-they-will-come dept.

An anonymous reader writes: I run a company that develops scientific computing software. Our core product is a traditional proprietary application — we develop the software and deliver the "binaries" to our customers. We're considering changing our deployment to include all of the source code and giving our customers some additional rights to explore and extend it. The codebase is HTML/JavaScript/Python/SQL, so a lot of the code is available in some form already, albeit minified or byte compiled.

Because we are in a scientific domain, most of our customers use Open Source software alongside our product. We also maintain Open Source projects and directly support others. We're strong supporters of Open Source and understand the value of having access to the source code.

We also support a free (as in beer) version of the software with a smaller feature set (production and enterprise elements that individual users don't need are removed). We'd like that version to use the same model as well to give users that don't need the full commercial version the ability to extend the software and submit patches back to us for inclusion in future releases.

Overall, we'd really like to find a model that allows our core product to work more like an Open Source product while maintaining control over the distribution rights. We'd like to foster a community around the product but still generate revenue to fund it. In our space, the "give the product away but pay for support" model has never really worked. The market is too small and, importantly, most customers understand our value proposition and have no problem with our annual license model.

We've looked at traditional dual licensing approaches, but don't think they're really right fit, either. A single license that gives users access to the code but limits the ability to redistribute the code and distribute patches to the "core" is what we'd prefer. My questions for the Slashdot community: Does anyone have direct experience with models like this? Are there existing licenses that we should look at? What companies have succeeded doing this? Who has failed?

4 of 85 comments (clear)

  1. Translation by Anonymous Coward · · Score: 5, Informative

    We want employees that work for free!

  2. Have you considered APIs or Plug ins ? by Crashmarik · · Score: 5, Informative

    That way you can give your users the ability to extend your product to their needs without risking killing off your revenue stream.

    Which begs the question where is your revenue currently coming from ?
    1. Product Sales
    2. Training
    3. Maintenance/support

    If it isn't 2 or 3 you may be killing yourself off. Especially if your product is user friendly and needs little in the way of support.

  3. qmail and Microsoft by paskie · · Score: 5, Informative

    Yeah, you seem to want to have your cake and eat it too. Doesn't produce a lot of sympathy. Think again about how to make your software free but still want users to pay. What about keeping value-adding plugins or frontends closed and opening the core? If you open source but limit ability of people to make use of the core, what exactly do you expect to gain from such a "community"?

    Still, take a look at the licence of qmail. This worked not so bad for them, and might be the right equilibrium. If you just want legalese for your scenario, take a look at Microsoft's Shared Source licences.

    --
    It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
    1. Re:qmail and Microsoft by Anonymous Coward · · Score: 5, Interesting

      My guess is that this is more like a Matlab style system, where users can create and share content and build a community that way. Having worked for a time at one of Matlab's competitors, I remember more transparency into the engine was something our users wanted and is one of the reason's R/Python have taken off (in addition to the fact that they're free). Every now and then there was something a customer wanted to do and contribute back to the engine, but we didn't have a mechanism for it.

      In this case, I suspect the poster is looking for a way to find that level of transparency, but still do maintain control over core development without the chance of forks. It also gives the users a path if the company goes out of business without having to execute one-off escrow agreements with each customer.

      I see people all the time on /. complaining that proprietary software is bad because they can't see the code. The poster here seems to be trying to find a way to address many of the issues about transparency while still controlling re-distribution. With a free version, it sounds like everyone can use it, but changes to the core can't be propagated without going through the company.

      Full disclosure: I saw this post in the firehose and modded it up since we're wrestling with similar issues right now. I'd love to see more models evolve that take the best of both proprietary and open source methods. Hopefully this discussion will yield some interesting ideas beyond the typical fanboy banter. :)

      -Chris