Testing out a potential open source documentation project for the Dropsource help center.

In my last blog post I tried to provide a high level overview of developer relations and outline how the field relates to our company goals here at Dropsource. This time I’d like to hone in on some of the pathways we hope will give our community of developer users: input into decisions about the future of the product, the ability to contribute to it and its ecosystem, and ultimately more control over their own ability to succeed in their app development projects.

A primary goal of developer relations (dev rel) is to help developers have success with a product and ultimately promote adoption. This can involve a range of activities such as creating learning experiences, promoting / evangelizing for your product, and providing support. Additionally, a number of key dev rel activities that can increase user engagement relate to user contributions.

Win Win

Driving developer adoption typically means empowering developers, and developers having success is a win for any dev tool. It helps adoption if you have a great software product that lets developers get jobs done, but there are additional ways you can supplement your core product’s purpose and ramp up its impact within your user community.

So how do you empower developers and increase their chances of success with your product? One way is to open up contribution channels – this is something we hope to advance for Dropsource within the coming months. We want to create an environment in which people can engage with the product and community in more meaningful ways than just as users of our software. We want to give our members the ability to influence and contribute to the product, and to drive the Dropsource community, with those of us representing the company acting as facilitators in that process.

This type of approach can be delivered in a variety of ways – it can mean open sourcing some part of your offering, a decision that has to be taken carefully within the parameters of your company goals. An interesting recent announcement along those lines came from development platform Fuse, who are open sourcing their software.

Defining your Pathways

At Dropsource we already have a couple of fairly standard contribution pathways, including:

  • User feedback  – we currently capture it through support interaction, occasional dedicated interview sessions, and surveys.
  • The Dropsource community forum – some of our founder members have already made a huge contribution by helping other users and sharing learnings from their own projects.

While these will continue to be integral engagement channels, we are also exploring a few additional pathways – read on for an overview.



Using git version controlled open source documentation would allow us to accept feedback inline and even merge user pull requests with new content.

Currently our documentation exists in two main places: the Help Center and inside the product (the information you see displayed next to elements and actions comes from our software’s plugin documentation). We also post informational content in the Forum, but our primary source for canonical product reference information is the help center.

Given the range of potential use cases for a product like ours, and the variety of external services people integrate their apps with, it would be ideal if our users were able to contribute to the documentation themselves, either by providing feedback inline, making content suggestions, or even editing / submitting new content they think might benefit other users. To that end we’re exploring the possibility of moving our documentation to an open source platform and accepting contributions to it, for example via Jekyll and GitHub Pages.

Feature Requests


Our feature requests forum category.

Right now the way we manage feature requests can at times be a little ad hoc. Our software is an app development product, so we have users attempting to implement an extremely wide variety of app types, not all of which we can support out of the box. If a user requests something we think will have a more general appeal, or that a number of people have requested, we will typically develop it internally and add it to the platform as a standard feature.


We also track feature requests via our Intercom chat support.

As our community of users has grown and the list of requests has become more varied, feature prioritization has become more of a challenge. To that end we’re currently discussing options that will allow us to automate and track feature requests, as well as exposing information to users regarding their development status.

The Dropsource platform was designed from the outset to be extensible. That’s why all of the available elements and actions you see in the editor are provided via plugins. Plugins are what make up your app’s UI and functionality. This means that there’s no need to be restricted to using just what we develop internally – ultimately our hope is that users will be able to write their own Dropsource plugins and extend the range of functionality possible with our platform.



Each action you see in the Dropsource editor is provided via a plugin – actions are how you add app functionality.

Our engineering team is currently redesigning the Dropsource plugin system in order to make the platform more readily extensible. We’re exploring methods we might employ to build user input into this process as early as possible, for example by using Documentation Driven Development to elicit feedback even before development has begun.


Dropsource elements also come from plugins, allowing you to use both standard and third party UI components for the native iOS and Android platforms.

The longer term goal we have always had in mind for Dropsource is to create an open contribution channel for people to build their own plugins, use them in their projects, and share them for others to use, or even monetize them. This could have a series of potential consequences, including but not limited to:

  • Allowing people to achieve use cases that are not supported by the default version of the software.
  • Creating opportunities for people to collaborate on plugin projects.
  • Giving our users the power to determine what is possible using the Dropsource platform.

The finer details of how this engagement will work are still in development, but one thing we believe is that opening our plugin system will expand the horizons of what people will achieve with the platform, by cracking open a much more meaningful contribution channel for our community.

Building a Platform

We’ve touched on adoption, but there is a greater goal in mind here. Ultimately at Dropsource we are all about making it easier for people to implement their ideas, and these contribution pathways could increase our ability to make that happen. A lot has been said and written about the difference between a tool and a platform, and this is key to why we’re doing all of this. To me, a platform is something that facilitates projects in a way that lets users define the possibilities. The classic example of this model is WordPress, where the technology can be supplemented by user contributed plugins, allowing the core software to power a hugely increased range of projects. By opening and facilitating contribution pathways with Dropsource, our hope is that our community of users will amaze us all even more with what they can achieve by building on our foundation technology with their own skills and creativity.