hernad · December 19, 2025 08:28
diff --git a/OCA_Marc.txt b/OCA_Marc.txt
 Good evening Ernad,

 I thought I would chime in with a point of view that boils down to saying "just open it up", 
 but hopefully with some useful reasoning that will help you make up your mind about what is right for your case or not.

 We're a small 2-person team based in Quebec, Canada. 
 Population about 8 million for the French speaking community that we mostly cater to. 
 Nowhere near the unrest and division that you describe in Bosnia and Herzegovina.

 I started out as a simple Odoo user when we implemented it for my family's water treatment company pack in 2012 
 (when it was still OpenERP). 
 Since then, we founded Bemade because we had a difficult time finding Odoo partners that fit well with our needs... 
 so we decided to become that partner and to offer our expertise to others. 
 We've used Odoo CE, Odoo Enterprise, and switched back and forth a couple of times.

 In my experience dealing with clients here in Quebec, I've found quite quickly that most of the local market 
 has no idea what Open Source can bring to their business: increased software reliability, reduced/no vendor lock-in, 
 better security standards, an army of potential developers for both bug fixes and feature development, 
 and, most of all, reduction of costs for feature development.

 For two years we worked mostly behind closed doors, but licensing our code under LGPL-3 and leaving it on public repositories. This has worked "ok" but has certainly not built a community. 
 Just a bunch of clients relying on us and benefiting from the fact that many modules are "already written".

 After observing the Open Source communities across different projects (and reading The Cathedral and the Bazaar), 
 I decided we needed to get more "aggressive" about building excitement in the business, non-profit and government community about open source software. 
 One of the clear trends in open source software projects is that there is typically one dominant project/community per need/niche. 
 This is because both user and developer attention are limited and so people choose to work on the "winner" even if it's not perfect.

 This is leading me toward:

 1. Simply getting the word out more actively locally about all the benefits of going open source (to potential clients and their advisors).
 2. Building our own place in the local community as experts, advocates and serious contributors to open source business software.
 3. Where possible, contributing actively to existing projects instead of starting our own and attempting to attract a community toward them.

 For example, we've done some work building a framework for managing a fleet of Odoo servers on Kubernetes. 
 Now that I've gotten the feature set close to where we want it, having used it privately, I am looking to open it up so that other intelligent people can look at the code, tweak it, fix it, and use it. 
 But, as you probably know, our wonderful Stéphane Bidoul gave birth to a related project a number of years ago (runboat). Knowing that, I'm not going to just put my solution out there and try to find people to work on it. 
 I'm going to reach out to Stéphane and see if we can work to combine the best parts of both architectures to improve his already successful project. 
 My reason for doing that is totally self-interested: even if my current software is "pretty good", I think I and my future clients have more to gain from also having Stéphane and the other OCA contributors on our side. 
 Also, runboat has WAY more developer and client eyes on it, and contributing to it will increase my credibility both in the developer community and to my clients.

 That's the beauty of open source projects. 
 The sooner you either launch them or join them as community efforts, the sooner the "interest" compounds. 
 It's far less expensive to profit from an existing platform visited by thousands (millions?) of users and devs than it is to launch your own project that will compete for their attention. 
 It's also far less expensive to have other people contribute fixes than to have to code them yourself.

 So my current logic is to either contribute new code to the OCA if there isn't already a project/module that addresses the need, 
 or to try and add features to existing projects. 
 With that said, I do hold back when I don't think a module has seen enough pre-alpha use and debugging or if I don't think it serves a wider need.

 One final example.

 We were recently talking to a client who owns a CNC machining shop. 
 He's been looking to buy a solution to automate steps in their quoting process. 
 They receive emails from their clients with PDFs containing 2-dimensional images of parts to be machined. 
 Their estimators then take those emails and try to find similar parts in their "database" 
 (a folder hierarchy with other PDFs from past projects) to get an idea of historic comparable production costs. 
 He would like to automate this step. He has been unable to find a suitable solution he can purchase or subscribe to.

 Looking that the project, I have two options. I can either develop the software for his company, 
 leaving them as the sole owner of the intellectual property. 
 This was initially their preferred route : "If we're going to pay for the development, we should own the product!". 
 But, in reality, they're not a software company. 
 They're not realistically going to sell that product any time soon. 
 Also, if that product existed as an open source project, I could very easily offer it to them under an SaaS model later, meaning that they wouldn't need to invest in the server infrastructure to run the eventual solution. 
 This opens up a revenue stream that we can realistically take advantage of (we have the hardware and the server infrastructure know-how already). 
 So I can propose to my client to try and find other CNC shops that would also benefit and have them split the development cost. 
 Perhaps even have a free first year of hosting or some other "kickstarter-style" benefit. 
 So instead of the project costing them, say $150,000 CAD (30k of development time and 120k of compensation for losing the revenue stream), it might cost them $5000 or $2500. 
 Then, if there is a community around the product, others can improve on it, maintain it, etc.

 So, I don't know if these are things you've already considered, 
 but they're the bits I find useful to think about for my own company.

 Best of luck,
 -- 
 Marc Durepos
 Bemade inc.
	Good evening Ernad,

	I thought I would chime in with a point of view that boils down to saying "just open it up",
	but hopefully with some useful reasoning that will help you make up your mind about what is right for your case or not.

	We're a small 2-person team based in Quebec, Canada.
	Population about 8 million for the French speaking community that we mostly cater to.
	Nowhere near the unrest and division that you describe in Bosnia and Herzegovina.

	I started out as a simple Odoo user when we implemented it for my family's water treatment company pack in 2012
	(when it was still OpenERP).
	Since then, we founded Bemade because we had a difficult time finding Odoo partners that fit well with our needs...
	so we decided to become that partner and to offer our expertise to others.
	We've used Odoo CE, Odoo Enterprise, and switched back and forth a couple of times.

	In my experience dealing with clients here in Quebec, I've found quite quickly that most of the local market
	has no idea what Open Source can bring to their business: increased software reliability, reduced/no vendor lock-in,
	better security standards, an army of potential developers for both bug fixes and feature development,
	and, most of all, reduction of costs for feature development.

	For two years we worked mostly behind closed doors, but licensing our code under LGPL-3 and leaving it on public repositories. This has worked "ok" but has certainly not built a community.
	Just a bunch of clients relying on us and benefiting from the fact that many modules are "already written".

	After observing the Open Source communities across different projects (and reading The Cathedral and the Bazaar),
	I decided we needed to get more "aggressive" about building excitement in the business, non-profit and government community about open source software.
	One of the clear trends in open source software projects is that there is typically one dominant project/community per need/niche.
	This is because both user and developer attention are limited and so people choose to work on the "winner" even if it's not perfect.

	This is leading me toward:

	1. Simply getting the word out more actively locally about all the benefits of going open source (to potential clients and their advisors).
	2. Building our own place in the local community as experts, advocates and serious contributors to open source business software.
	3. Where possible, contributing actively to existing projects instead of starting our own and attempting to attract a community toward them.

	For example, we've done some work building a framework for managing a fleet of Odoo servers on Kubernetes.
	Now that I've gotten the feature set close to where we want it, having used it privately, I am looking to open it up so that other intelligent people can look at the code, tweak it, fix it, and use it.
	But, as you probably know, our wonderful Stéphane Bidoul gave birth to a related project a number of years ago (runboat). Knowing that, I'm not going to just put my solution out there and try to find people to work on it.
	I'm going to reach out to Stéphane and see if we can work to combine the best parts of both architectures to improve his already successful project.
	My reason for doing that is totally self-interested: even if my current software is "pretty good", I think I and my future clients have more to gain from also having Stéphane and the other OCA contributors on our side.
	Also, runboat has WAY more developer and client eyes on it, and contributing to it will increase my credibility both in the developer community and to my clients.

	That's the beauty of open source projects.
	The sooner you either launch them or join them as community efforts, the sooner the "interest" compounds.
	It's far less expensive to profit from an existing platform visited by thousands (millions?) of users and devs than it is to launch your own project that will compete for their attention.
	It's also far less expensive to have other people contribute fixes than to have to code them yourself.

	So my current logic is to either contribute new code to the OCA if there isn't already a project/module that addresses the need,
	or to try and add features to existing projects.
	With that said, I do hold back when I don't think a module has seen enough pre-alpha use and debugging or if I don't think it serves a wider need.

	One final example.

	We were recently talking to a client who owns a CNC machining shop.
	He's been looking to buy a solution to automate steps in their quoting process.
	They receive emails from their clients with PDFs containing 2-dimensional images of parts to be machined.
	Their estimators then take those emails and try to find similar parts in their "database"
	(a folder hierarchy with other PDFs from past projects) to get an idea of historic comparable production costs.
	He would like to automate this step. He has been unable to find a suitable solution he can purchase or subscribe to.

	Looking that the project, I have two options. I can either develop the software for his company,
	leaving them as the sole owner of the intellectual property.
	This was initially their preferred route : "If we're going to pay for the development, we should own the product!".
	But, in reality, they're not a software company.
	They're not realistically going to sell that product any time soon.
	Also, if that product existed as an open source project, I could very easily offer it to them under an SaaS model later, meaning that they wouldn't need to invest in the server infrastructure to run the eventual solution.
	This opens up a revenue stream that we can realistically take advantage of (we have the hardware and the server infrastructure know-how already).
	So I can propose to my client to try and find other CNC shops that would also benefit and have them split the development cost.
	Perhaps even have a free first year of hosting or some other "kickstarter-style" benefit.
	So instead of the project costing them, say $150,000 CAD (30k of development time and 120k of compensation for losing the revenue stream), it might cost them $5000 or $2500.
	Then, if there is a community around the product, others can improve on it, maintain it, etc.

	So, I don't know if these are things you've already considered,
	but they're the bits I find useful to think about for my own company.

	Best of luck,
	--
	Marc Durepos
	Bemade inc.
No results found