10 Software Development Principles That Power A DevCrm

SaaS coupled with free pricing options has created a market for developers where they can quickly iterate with customers through their code to create apps at the speed of light. All you need is GitHub for your code, Slack for collaboration, and AWS to host your service. These intuitive developer first tools have enabled thousands of startups to reach millions of people across the globe with their new ideas. An engineer with the right APIs can build features and integrations which previously required several project teams to execute for years. And imagine if you have a thriving community of customers and developers who are collectively building your product- the possibilities of a customer-led product development are limitless.

We at DevRev believe that this phenomenon will redefine the way companies have been thinking of Customer Relationship Management (CRM) platforms. CRMs that were considered sales, support, or marketing tools will evolve into managing the relationship between the developers and their customers. The Developer CRM plans to change the traditional models that ignore the customer and the product in the tedious agile project management process of churning out sprints with bugs and features. Dev CRM aims to provide a platform for the developers and their customers to jointly work on the product in a “bazaar” like model which has its roots in the open-source community.

Origins of the bazaar in open-source

Software industry was heavily licensed and commercial vendors made sure that developers could not study, change or share source code of their software products. Richard Stallman started the Free Software Foundation in the mid-80s to revive the founding spirit of collaboration and curiosity among developers which was prevalent since the early days of computing. Free software foundation gave birth to the freedom-respecting GNU operating system where hackers could create, share and modify the source code. It wasn’t however till the mid-90s that the “open-source” word came to being when Eric Raymond wrote “Cathedral and the Bazaar” and started the Open Source Initiative.

The open-source revolution was a rebellion against the unfair “tax” software industry imposed on the makers of that age. Hackers of that age were getting increasingly impatient with how the industry was killing their creative freedom. Not only was the software free but even the development process for the software was decentralized and open for hackers to contribute. Thus came about the free “bazaar” model of software development which was contrary to the command and control style of a “cathedral” model.

It almost sounded too good to be true at that time. A “free and fair” utopia where everyone gets to “share and care” for each other’s code. Developers started with fundamental building blocks of operating systems and databases to build their metaverse on top of it. The bazaar was open for business, the only problem was that the rules of the bazaar are still not codified and continue to evolve like the code. In his seminal paper and later a book titled “Cathedral and the Bazaar” Eric S Raymond writes: Linux evolved in a completely different way. From nearly the beginning, it was rather casually hacked on by huge numbers of volunteers coordinating only through the Internet. Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days, creating a sort of rapid Darwinian selection on the mutations introduced by developers. To the amazement of almost everyone, this worked quite well.

When I read this, I am almost forced to draw parallels of this style of software development to our current CI/CD (Continuous Integration Continuous Delivery) methodology in the devops cloud native world. Also, the industry has now universally accepted the practice of releasing Minimal Viable Products (MVPs) and everyone gets feedback from users almost immediately and builds iteratively. While there are several things to learn from this model, I will focus on the software development style of the bazaar in the rest of this article. Numerous open-source projects have followed the bazaar style of software development and became an integral part of our day-to-day lives.

Github is the de-facto platform where open source thrives. Ironically, the biggest detractor of open source software Microsoft bought Github for $7.5 billion dollars. According to a 2021 study by Synopsys, 70 percent of the audited code was found to be open source . This number was only 36 percent in 2015. Microsoft’s Visual Studio code editor is an extremely popular open-source repo in Github with over 107k+ stars and 19K+ contributors. (DevRev is hosting a hackathon to develop a VScode extension powered by OpenAI Codex to make developers’ lives easier with AI).

The evolution of the software bazaar

In a series of articles, I will go through the evolution of the bazaar from the days of Linux to Web 1.0, Web 2.0, and now Web 3.0. A story where the bazaar always made it easier for the underdog “hacker” to build their idea and disrupt the incumbents, one which always thrived on decentralization and innovation to power its activity. This bazaar also thrived on chaos and collaboration to produce one of the most resilient and reliable systems humans have ever built. Bazaar, almost self-governing and self selective, was inclusive to those who could code but still excluded the majority. A bazaar that was supposed to be fair yet gave tremendous control and advantage to a few.

A bazaar that took many forms since its inception — .com, Internet, Social Media, Big Data, Cloud, DevOps, SaaS, Crypto, and Metaverse. A bazaar that reminds us of the chaotic and lively bazaars of the Middle East and Asia where “artisans” adorn hundreds of shops in meandering lanes and customers experience diverse aromas, colors, and most importantly seeking serendipity in their normal and boring lives.

In the bazaar, interactions are not transactional but the belief is in creating trust through personalized care. The bazaar might look chaotic but there is a method to the madness which has endured through civilizations. A bazaar where the customers are finally free to try out SaaS goods and services without hitting a paywall. A bazaar where the quality of the product speaks for itself and everything is product-led. A bazaar where you could host your product in the cloud and reach out to anyone in the world. A bazaar where the developers can build, operate, support, and grow their businesses. A bazaar where customers can lead the makers to the product.

10 principles of a Developer CRM

I have tried to distill the lessons shared by Eric S Raymond during his open-source journey in the 90s with Fetchmail below. These ten principles hold true even today and apply not only to open source projects but also to any commercial software, especially SaaS. To me, these are fundamental to the thesis of Dev CRM and what DevRev is hoping to achieve by rethinking the agile software development process.

1) Write, rewrite, and reuse code

Initial Linux code was borrowed from Minix, a tiny Unix-like OS. Eventually, the Minix code was rewritten and most of it went away but it did provide the initial skeleton to the infant which would become Linux. Open source communities like Discord are thriving on GitHub with developers reusing code from javascript libraries and contributing from across the world.

2) Start small and iterate

You often don’t understand a problem until you build an initial solution. This is particularly true for software and gave rise to the “hacker” culture. Linux went through several iterations before it became such an elegant and powerful OS. The Linux archives are a great resource for curious minds. This holds true for any feature you build in your product as it goes through several iterations in its API or UI design. The process of crawl, walk and run which needs to be memorialized in a SoR just like the Linux mailing lists as they are a treasure trove of context for anyone looking to learn and contribute to code. This also helps through the “hacking” process where small ideas and optimizations can turn into side projects and evolve into mega projects later. The Apache Software foundation is a classic example where a bunch of users came together to support and maintain the HTTPD web server written at NCSA. They started to make incremental changes, bug fixes and shared information on how to improve it. Today more than 65% of the web sites in the world are powered by the HTTPD web server. The Apache Software Foundation exploded and gave rise to the “Big Data” movement with popular tools like Spark, Presto.

3) Release early and release often

Early and frequent releases were a culture that the Linux community had nurtured from the early days. Even though it was something as complex and critical as an operating system, the buggy releases flew off the pipeline real fast. This was a testament to the trust folks had in the community to do the right thing and their user base to bear the pain of buggy software. Software developers should also do incremental commits on their branches to make integration easier and more frequent. It is common for SaaS companies these days to have weekly releases with “feature flags” to make sure they can incrementally roll out and test features with their users.

4) Users as partners

If your tool is for developers, a lot of users will be coders too. Because the source code is available in an open-source model, they can be effective co-developers as well. Users can help you with debugging, triage, troubleshooting, and even suggest fixes. This almost creates a flywheel which increases the velocity and shapes the direction of the product. In Linux, the Lisp code pool was user-driven and the collaboration was fuelled through the internet. In the SaaS world, GitLab has applied this principle to build an open core software development platform where the users can contribute to the code and build as partners. DevCRM creates a process around which companies can pivot/micro pivot to find the elusive product market fit.

5) Empowered user community

The bazaar style advocates empowered users who have direct access to the developers and the prioritization of their bugs and features. The roadmap should be shared transparently and there needs to be feedback loop to any new features released. This builds the new age moat for your business called “community” and helps your product become a platform with all the goodness of network effects. DevCRM brings the customers into the agile software development process of the developers.

6) Linus’s Law — More eyes on code = all bugs are shallow

Bugs are especially hard to tame when the tester is looking outside in and the coder is looking inside out. They tend to talk over each other. It becomes much easier when both have source code visibility and can communicate with the same mental model. It’s even better when beta testers can not only look at symptoms but also the underlying root cause and code. This saves time for the developer as well.

7) Collaboration at scale

For folks who have worked on software projects, we all know that adding more developers necessarily does not lead to greater velocity. As more people are added to a project or codebase, communication and collaboration drains time and also more bugs start to creep in. Imagine running an open-source project with so many contributors. The open-source community scaled this through a hub and spoke model. The the “halo” or peripheral developers worked on independent parallel tasks which required no communication; whereas code change reviews and bug reports streamed through a small core group that had to communicate and collaborate amongst each other. This style of organizing product teams has especially gained popularity in today’s age when you have platform or core teams that work with independent feature teams through loosely coupled microservices.

8) User’s idea is your feature

Recognizing good ideas from users and being self-deprecating and truthfully honest about them is probably the most important part of gaining your user’s trust. Easier said than done. This requires courage and humility. By accepting and making their ideas into features, you make them “owners” of the product. More importantly you should maniacally mine all the user ideas and pick the ones which could be the next killer feature. Also its very important to build these features very closely with the users so that they can stay as pure as possible. It is very easy to lose those nuances as the idea comes to life in code. Dev CRM will be critical to take customer ideas to develop product features.

9) Think hard about the problem

"More often than not when I have hit a dead end while trying to solve a problem. I end up asking myself if I am solving the right problem or am I asking the right questions to understand the problem”. This especially holds true when we are encountered with design problems. The assumptions and understanding of the customer’s pain point is critical to the development of a feature. In the open source world-community boards have been critical in surfacing user’s pain point and fostering discussions through “Threads”. These “Threads” have time and again inspired several developers to come up with ideas and build great products.

10) Less is more

Last but not least, do not hesitate to throw away code or features in your product to make it more elegant and simplistic. This is especially true in a self-serve product-led era where the user has to discover and love the product without any guides or training. Eric aptly summarizes - ‘‘Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.’’ Conclusion These 10 principles of software development hold true even today as the release cycles have become shorter and more rapid. Yet, as a developer or even product managers, we have to constantly remind ourselves of these software development principles to get closer to what matters the most when building something new — our customers.