How to involve the OCA in your project delivery process?
And remain competitive and profitable...
How do you guys do to contribute and be profitable?
Where do you find the time and the resources to make reviews? To publish modules? To fix bugs? These are some of the questions I have been asked a couple time in the last 2 years.
My guess is that most integrators understand contributing as an extra step at the end of a customer project: Once the project has been delivered, they would push some modules into the community and that's where the problem is. At that step of the process, there is no time, resources nor budget to make the required changes. Each comment on your pull request is seen as a frustration because it delays your availability and increase your cost. Hence, the pull request is left unloved until the next inter-project period.
On the other hand, the community is seeing your contribution as an extra load of work: lots of module to review, no idea of what each module is about and does, many features in the same module, OCA guidelines not always respected, poor design, no fixes from the contributor (who has been assigned to a new customer project), etc...
So how? Let's try to integrate your process with the community. It is possible because your customer is a sample of the community: He shares some common interest, so its objectives and the ones of the community are aligned in a part of the project scope. Don't try to contribute modules that only your customer care about, but be imaginative for the other modules and think about other customers that may be interested. There may be a market waiting for you...
Talking about market, this is where you can start involving the community: You have a new lead and one of the first thing you can do is look at what the community has to offer in this industry: How many modules? How much activity? How much "noise" is made?
You will want to:
Research and identify the modules/repositories that can help you build an attractive demo and get closer to all the requirements of your lead. Less development is lower cost for your customer and lower risk for you. (Ab)use Odoo Apps, Odoo Code Search and Google.
Research and identify the PSC/people in the community that may help you, especially if it is a new industry for you. Give you a chance to bypass the newbie mistakes and learn from your experienced peers.
Contact the PSC/people to know about their interest, availability and pricing. You may contract them to migrate modules, review your specifications/modules, mentor your developers, fix bugs, fund or crowdfund a feature (BountySource, IndieGogo), etc.
Quote your customer for the worst case scenario, i.e. any unknown requirement will need development, so any existing module will be a good surprise and give you some budget to contribute.
Did you win the deal? Yeah! Good job. Announce it so the community members know some modules will arrive, they can inform their own leads and get ready to review your specifications and modules. You also give you a chance to collaborate and share the development and spread your cost among the customers of other community members.
Project has started and your customer has a list of requirements to answer. You may not have the answer to all of them or a new answer may exist. Let's find it:
- Research existing modules using Odoo Apps, Odoo Code Search or Google
- Ask on the Community/Contributors/PSC mailing lists for modules if you don't find any
- Evaluate modules on Runbot and report a bug if you find any
- Review modules in development on Github
- Ask on the Odoo forum or create a Github issue if you don't understand how the modules works. Documentation can certainly be improved.
Assuming there is no existing module to answer your requirement, you can request a new feature. Create them as soon as you can (even if incomplete), this way you give anyone else a chance to follow your progress and they can provide feedbacks early on. Of course, you don't need to take every comments/features into account: Plan a first version with at least your requirements and keep improvements in later versions of your modules.
Then, the process is well documented in the Code page.
When creating the pull request, don't forget to add the link to the issue with the design in the description so people can review the specification and have some context. Anything that can speed up the review is always welcomed.
Now that you've done the development and tested your modules, time comes to deploy your solution and put it in front of the customer. Problem is that your community modules/branches haven't been merged and are still being reviewed. Thanks to Stéphane Bidoul from Acsone, you can deploy your modules using Wheelhouse, Pypi (soon) or directly from your Github branches (see slides above).
I hope this post will save you some frustration and allow you to smoothly integrate your process with the community ones. If you have any feedbacks or questions, please do not hesitate to share them in the comments or on the contributors mailing list.
So, meet your new team and let's be stronger together: