Lessons learned on how not to run an Open Source company

Back when I co-founded Inigo, one of my primary motivation was to create an Open Source company which:

• Provide quality Open Source solution for Malaysian market (in this case, KM & CMS solution)
• Work closely with upstream on improving the products supported by the company (in this case, Plone)
• Actively develop local talents and human resource on Open Source skills, following pure Open Source philosophy
• Actively create new innovation for the market related to our core solutions
• Scale the company up that it become a prominent player on its core market

Unfortunately, over the years, none of the goals were reached. Due to our business model approach, ended up as a company which primarily focus on developing client-specific add-ons on top of Plone. The projects were fun, and challenging, however, due to a poor support and pricing model, the business unable to scale and we ended up in a hamster wheel of non-stop trying to catch up to pay the bills. Mistakes done includes:

• Poor business/pricing model which penalize efficiency (the more efficient you become, the less you earn), made things very unsustainable. 
• Hiring is difficult due to the business model creates no sustainable revenue for investing on human capital development or hiring an experienced developer. Plone is not exactly something junior developer can pick up quickly. So the bus factor of Inigo is very poor, with only me as the developer.
• The support model which we adopted also was self-destructive. It is an all-encompassing support package which does not limit what code will be supported - therefore, I have to be familiar with whatever codebase the client use on their system - including custom code which was developed by other vendors - fun at first - but a too high of a bar to handle after a while - human brain have its limits.
• Continuously building downstream customizations removes the benefit of being part of Open Source community. Almost none of the code can be collaborated with other contributors because it is too specific to a single client.
• Growing number of non-upstream custom code, of which are too client-specific that we could not immediately reuse, (if we managed to, the pricing/support model does not reward code reusability), inability to hire for help and/or build local capacity to help things out (due to I have to focus on delivering projects to pay the bills instead of building a team) - slowly take a toll on my mental health. 

Being somewhat alexithemic, I did not notice the signs that I have been stressed out for over 2 years - something which apparently many people around me, especially those in Hack In The Box community have noticed way earlier than me - until I finally broke my brain circuitry and ended up with anxiety disorder (I'm still on xanax therapy until this date), and almost falling to a deadly state of depression. It took me 4 months struggling to figure out what was wrong with the brain function, nausea and constant chest pain made things harder to manage, only after finally medically diagnosed with anxiety disorder I decided to stop whatever I was doing, and take a break from programming.

Having said that, over the past 5 months, I have been working as a solution architect in a local Open Source system integrator company. The position I'm at gain me access to observe the process utilized by 2 of the major companies which adopt the philosophy of 100% open source and high commitment to upstream - Red Hat and Hortonworks. Picked up quite a bit from them, especially on the business side of enterprise open source, and learned how they create a sustainable support model around 100% open source software.

From the newly acquired knowledge, it created a new motivation to attempt again in bringing Plone to this region, through a creation of a Plone distribution - KOSLAB PlatoCDP.

More information, on the next blog post.

- Izhar Firdaus -