DEV Community: Minal Mehta

How to build and maintain welcoming open source communities?

Minal Mehta — Thu, 03 Feb 2022 12:11:54 +0000

Open-source projects thrive upon the solid foundation that open source communities offer. However, there are zillions of open source communities and building and maintaining one is no magic but calibrated efforts of the maintainers who do not shy away from following certain best practices. How do we stand out? Are there any strategies that we can follow or develop? Well, it surely isn’t a walk in the park however by following certain best practices we may be able to build and maintain a tribe of our own! Read on to know more.

Making it easy for all to use the project

Creating a strong ecosystem around the project is as significant as developing a project. A strong ecosystem will be able to stimulate the growth of the community. When the developers, contributors, users etc find tools and techniques that can simplify their work they will not only use them but will find means of improving them as well. This creates a win-win situation for all within the community.

We may land up to the next obvious question. What makes for a relevant ecosystem?

The technical documents, the API, the readme along with the people all come together to build a significant and welcoming ecosystem. Good documentation is definitely time-consuming just like building a bond with all the members of the community. The trick is to keep it transparent and open for all.

Building personal relationships

Collaborating online may at times get lonely and often impersonal. If we are making internet collaborations we’ll need to build closer and more personal relationships. You’d want your tribe or community to know you as a persona and not merely as a GitHub username! How can we make our community more personal?

We can create communication channels that are easy to access and use. Such channels may foster conversations, sharing ideas, coming up with innovative solutions, asking the right questions and build personal relationships.
- GitHub issues is a great way to discuss feature requests, bug reports and other proposals. But sometimes it will make more sense for the users and contributors to hang out casually and get help through a platform like Slack or Discord. At ToolJet, we chose to use Slack as a lot of developers already have a Slack account.
- While choosing a platform for your community, make sure you do not use something that is less popular. Make it easy for your community members to join the platform. If it involves downloading a new application or creating a new account, they might just choose to be lazy.
We can welcome the new members to the group and get them up to speed with the latest developments.
We can identify our contributors and can support them to advance. We can even consider referring them to relevant companies and individuals. Inviting them on calls and chats is also a good idea.

The more our community members grow and expand their skills the more experts we’ll have in our tribe!

Letting the community members contribute meaningfully

Interested members who’d like to contribute to the projects may need to have all the information at their disposal. With information, they’d be able to begin and get to speed. For example to save the time of the developers from searching for documentation we may rather make them easily discoverable. As per one of the surveys by GitHub, about 93% of the people consider incomplete or outdated documents a major challenge. Improper or incorrect documentation may turn off a member from engaging meaningfully within the community. How do we let the community members contribute meaningfully?

Giving them clear guidelines of how to contribute as simply as we can.
Creating a dedicated contribution file to keep all the documents updated within.
Labelling all the documents correctly so that the new members are not lost within.
Always extending gratitude to the members who contribute to our open-source projects. A few words of kindness may go a long way in managing an empathetic community.

Driving inclusion within the community

Our open-source community may be willing to engage more when the members feel a sense of inclusiveness. The more we make them feel a part of the community the more they may be motivated to stick with us through the thick and thin of times. So how can we best make the members feel included?

We may pay heed to their feedback both positive and negative, this will make them feel heard. Also, we’d be able to gain the most useful of the information through these hard to hear feedback loops.
Ensuring that the maintainers of the community are available on different channels so that they can engage with all the members of the community.
Consider creating a mailing list for all the members who can time and again be updated on what’s going on within the community. Everyone who’ll be part of the mailing list may gain access to the latest blogs posts, major announcements, press releases etc.
We can empower the members to take up some tasks that they’d find interest in.
We can even dedicate a blog space wherein we can write about how grateful we are for our contributors.
We can make our trusted contributors the maintainers of our projects where they can take the lead to manage the project professionally.

Setting up a code of conduct

Our open-source community can bring in people from all over the world. For sure we can have a very diverse community however there can also be major conflicts within the community.

As per GitHub negative interactions amongst the members of the community may develop in the process. Nearly 18% of the members who’ve been part of the GitHub community have faced some form of negative interactions within the community. Almost 50% of the members have witnessed the exchange of negative interactions within the community. About 21% of the members mentioned that they’ve stopped being a party to the community because of the negativity. The common negative interactions could be impoliteness, stereotyping, name-calling etc.

Our open source community should be able to offer a positive and enriching experience to all the members regardless of their ethnicity, region, gender etc. Hence to foster an empowering and harassment-free culture we should enforce a uniform code of conduct for all the members. We can get started by considering the below-mentioned points.

Addressing any kind of negativity immediately by setting clear grounds.
Addressing negative interactions politely and publicly. By doing this we’d be able to send a clear message to our members that any kind of negativity will not be tolerated within the community.
We can give the members power and tools to act against any kind of negativity. Blocking a member can be one of the methods.
We can make our code of conduct file open and accessible to all. It should also be visible.

Open-source software revolves around the community of users, contributors and maintainers. The community can easily become the "product manager" of an open-source project. At Tooljet we follow the above-mentioned practices and principles to build and maintain a thriving open-source community. ToolJet is an open-source low-code framework for building web applications. You can check us out on GitHub - https://github.com/ToolJet/ToolJet.

Ending Note:

Building and maintaining an open-source community is possible when we look at each of our members empathetically. By being wholly transparent towards our members we’d be able to build personal connections and drive diversity and inclusiveness. Investing our time and efforts towards the goals of building a welcoming community is a worthwhile effort. The community that we’ll build today may take us closer to our long term vision of building a product that stands out amidst all others. The relationship that we share with our community is two-way. Gaining their support and giving them an environment to thrive in, is a win-win for all involved.

Understanding the low-code vs no-code debate

Minal Mehta — Fri, 10 Dec 2021 09:44:54 +0000

Most of us, at times, are unable to understand or differentiate between low-code & no-code. At times some of the users describe them in a similar way. Does this matter? What are the real differences between them and how can they be used independently?

Both the low-code & no-code principles of application development abstract away from ‘code’ to bring forth the advantages of ‘visual modelling’. However, the difference remains fundamentally in the scale and type of application that needs to be built via applying one of the two approaches. Let's explore more as we advance further in this article.

Low-code vs no-code: What are the similarities to begin with?

The low-code and no-code development platforms bring forth the methods of building software applications without coding or with less coding. So how do these principles work? These development principles take the visual approach to application development. Hence app development becomes accessible to a higher volume of individuals, especially tech-savvy natives working in the line of business.

The low-code and no-code principles of development support the professional as well as the citizen developers alike. It is possible to develop applications with greater efficiency while adhering to these novel approaches of development. This can heighten productivity. This is pretty much where the similarities end!

Low-code & its use cases

Low-code platforms are sort of a ’middle ground’ between the full-on manual coding and absolute no-coding. They are more malleable. The low-code platforms can be very visually driven coming with elements of ‘drag & drop’. They are quite open and extendable. They also have room for manual coding, giving developers the joy of both worlds! Here it is possible to increase the speed of development and there may not be any need to constantly replicate the basic code.

Low-code development principles also permit for the scalable architecture, open API that can be reused & come with the flexibility of being ‘on-cloud’ or with onsite adaptability. The developers can additionally exercise control over the application quality, testing and performance tooling.

Additionally, with low-code principles of developing, the potential for the developers to extend the capabilities of the platform with the application of their own code can be multiplied. They are at the same time empowered to modify or build complex and sophisticated applications that may otherwise need more manpower deployment or may need some specific skills.

The low-code platforms are able to handle more user cases because of their generic purpose nature.

Let us have a look at some of the pros of low–code platforms:

Next-gen technologies with the applicability of innovative use cases: A host of Low-Code platforms come with a comprehensive library of components that are built by the technology leaders. They also permit you to draw upon the third party smart services on offer in the cloud-like Machine Learning, AI, Blockchain, Facial & Voice Recognition services and the likes.

The Customer Experience Applications: These are available for mobile, leveraging the previously – built interface templates that are designed in such a way to support the developers optimise the user-friendliness and uptake of any application. They also come to ensure consistency in corporate branding.

The Legacy System Modernization comes along with the current architecture along with microservices. These support component-based development where they are able to use containers. These come with continuous deployment opportunities for the existing mission-critical applications.

No-code & its uses

No-code platforms or principles of development can be safely considered to be the simplest. These are visual-based, drag & drop platforms that allow us to function with basic applications. We may not be overhauling the legacy systems here as we did in the Low-Code Platforms. At the same time, we may not be able to scale it very well and may be limited in our approach towards the integration capabilities. This approach to development is best suited to teams that have specific needs that fall within a limited scope.

The No-code Platforms come with simplicity of use However this can also be one of its downfalls. With most of its framework being determined by the ones who developed it, the real ability to customize it boils down to low or no at all! This may possibly lead to loopholes for security and compliance-related issues. Also, the ability to work out the application into a more wide organizational architecture becomes limited. This principle of development may lack the oversight and the consideration that comes straight from a developer-driven application. The No-Code apps are also known to end up contributing to the presence of shadow IT.

It may seem somewhat blurry that if these principles of development are limited in their capabilities, why have they at all been able to hang around for as long as they have done? We can answer by saying that this application is safe to use by people with no – coding knowledge or experience. Especially by the ones who can’t wait for an IT team to build something for them. No-code applications are also a great way for non-technical people to build prototypes for what they want before they bring them forth to their IT teams.

At the first glance, the simplicity and ease along with the rigidity that comes with No-code development principles may work at a basic departmental level, however, scaling to the organizational level may pose certain challenges like:

Architectural considerations: There can be instances of monolith application architecture solely due to the inexperience of the developer with application architecture patterns. Most of the no-code platforms may require deployment to their affiliated public cloud and they may not come with the flexibility of deploying to a private cloud or onsite application.

Low extensibility: the No-code platforms lean more towards the operational efficiency use cases. They do not have the bandwidth to focus on the User Experience or are not able to extend to the legacy systems We may not be able to create custom solutions for third–party or homegrown requirements.

Inefficient data governance: Because of the stand-alone nature of the apps built using the no-code, platform data governance is likely to be a primary challenge

Where does Tooljet stand in the no-code / low-code space?

We may very well use the Tooljet platform for no-code application development, where it really makes a mark in the low–code space. Tooljet allows rapid application development with pre-built components to suit the end-users. By minimizing the coding needs and taking away the grunt work, Tooljet is able to gain ground when it comes to keeping updated the ageing legacy systems and improving customer experiences brick by brick among its other benefits.

Ending Note: With the ongoing debate when deciding upon which principles to route for, we may end by insisting that the no-code platforms are quite simplistic when it comes to supporting the complex use cases while the low-code principles come across as too complex for non-professional developers to use. To compound this challenge let us observe that while implementing a no-code principle to development, one may be seen as shadowing IT to the larger IT space. Also, once your application grows beyond, what are you going to do? All the cost-saving and efficiency may go out of the window as your choices get limited. On the other hand, if we deploy the low-code principles to development it may expand your horizon and you may be able to add more customizations to your application. Larger more complex and sophisticated applications can be built with a low-code platform and this is not the case for the no-code principles.

Looking for a low-code platform to build your next internal tool? We would love you to check out ToolJet on GitHub.