The first discussion is about USING open source. Philip Hallstrom puts the justification very well: 'it let us do much more, faster, and for less.' For me it's important the customer understands that "using" open source entails contributing back patches when we resolve issues or missing functionality for ourself. This is usually not a problem.
The second discussion is about releasing your completely independent work as open source. My favorite tack is explaining that if we're clever about how we build this, we should minimize and focus the code that's actually unique to YourBusinessTM. THAT'S the part that's mission critical, THAT'S the part they want to spend money supporting. The rest of it should be broken into pieces that other people will be interested to use and support as well. If they're lucky (or willing to spend a fraction of the cost of support on building community), they'll find "the rest" of their application gets supported "for free" by an organic community of self-interested users. After convo number 1, that model is something they can understand.
I often explain "code as a cost center" - the smaller and more tightly focused the code you have to maintain, the cheaper and simpler it is to maintain. Really, YourBusinessTM should only care about maintaining the part that is their unique business logic. For the rest, it's even worth spending money to try and build some community to support it... because that's way cheaper than developer salaries these days.
Source: My job is convincing huge companies to collaborate with us on open source solutions to their tech problems, and then doing the development with them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The first discussion is about USING open source. Philip Hallstrom puts the justification very well: 'it let us do much more, faster, and for less.' For me it's important the customer understands that "using" open source entails contributing back patches when we resolve issues or missing functionality for ourself. This is usually not a problem.
The second discussion is about releasing your completely independent work as open source. My favorite tack is explaining that if we're clever about how we build this, we should minimize and focus the code that's actually unique to YourBusinessTM. THAT'S the part that's mission critical, THAT'S the part they want to spend money supporting. The rest of it should be broken into pieces that other people will be interested to use and support as well. If they're lucky (or willing to spend a fraction of the cost of support on building community), they'll find "the rest" of their application gets supported "for free" by an organic community of self-interested users. After convo number 1, that model is something they can understand.
I often explain "code as a cost center" - the smaller and more tightly focused the code you have to maintain, the cheaper and simpler it is to maintain. Really, YourBusinessTM should only care about maintaining the part that is their unique business logic. For the rest, it's even worth spending money to try and build some community to support it... because that's way cheaper than developer salaries these days.
Source: My job is convincing huge companies to collaborate with us on open source solutions to their tech problems, and then doing the development with them.