I recently considered contributing to an open-core software (a product which core is released with an open-source license by the company that developed it, but it retained a paid license for more advanced functionality). But some questions occurred about the nature of working with an open-core project, and I would like the input of the community. My question is would you still be motivated to contribute if:

  • most if not all the software was contributed by paid developers.
  • you'd be benefiting the finances of one company (opposed to benefiting the community)
  • the direction of the software would be determined by the company and not by you (or the community).

I would like also for someone to confirm if those are myths or not

  • implementing the same features that are sold by the company won't be allowed.
  • forking the project won't be allowed (it might depend on the open-source license).

Thank you.

ps: Could someone create an "open-core" tag?

  • +1 for a question about a concept that is interesting but doesn't get talked about as much as perhaps it should. Commented Jan 25, 2011 at 21:37
  • 1
    If you can't fork it, it's not Open Source.
    – Dan Dyer
    Commented Jan 26, 2011 at 0:17

4 Answers 4


The answers to your question will depend on the license the product is released under so it's impossible to give you a catch all answer but I think there are general principals you can look out for.

If the core / open source components are released under an established open source license then the sort of restrictions you talk about won't exist. If it's under a variant license then they may be in place.

Personally I'd only get involved in working on code that is covered by a recognised, unencumbered open source license. The company are getting free work done, the least they can do is not try and restrict how people use stuff they're being given for free.

I'd also want to understand a bit more about who manages commits and how the overall direction is governed. You don't want to be working on something which ends up getting declined because the company who owns the product decides it's not compatible with their vision. That's not to say they shouldn't have a big say, just an overall direction and intent should be public.

But I don't think there's anything wrong with the model if done in this way. You could make a case that Mac OS X is an example of this as it uses elements of the FreeBSD kernel which is obviously open source.


If you have made improvements or new features that you want to see in the next version, because you want or need them yourself, you should contribute them (i.e. send them to the core team).

Other than that case, I see no point in contributing.


It sounds like your changes would be to the open core of the app, not the proprietary "advanced features", part so any changes you make would benefit any community that has access to the core.

  • So... is that a "Yes" to his question?
    – Ben L
    Commented Jan 25, 2011 at 21:18
  • @Ben: Tentatively... I don't know enough to answer the parts about forking or implementing features that the company charges money fore. Commented Jan 25, 2011 at 21:19

I think that, by contributing to the open-source core of that application, both the company and the community would benefit from it.

What's more, the community could engineer some kind of open-source front-end to such a core.

Personally, I don't see anything inherently bad in helping out with a half-open-sourced product, even if the company then sells it and makes money out of your work.

Of course, I would prefer if the whole thing was opensourced, but hey, having an open-source core is probably better than nothing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.