[Qgis-psc] Draft blog article about enterprises collaborating with QGIS

Wed Apr 20 22:23:04 PDT 2016

Hi all

Following a suggestion by Richard I have been drafting an article for the QGIS blog about how companies can approach building services around QGIS in a sensitive way. I am inlining my first draft (I haven’t taken an editorial re-read of it yet). Do others agree with the general sentiments laid out here and are you happy for me to post it? Also if you have other good points to raise please let me know.

———— copy starts —————————
Over the years, QGIS has gained more functionality, more users and more people and organisations who make their livelihood from it. As an Open Source project, there are two things that we value most highly:

Our community of project contributors
Our community of users
The two groups are intermingled, co-dependent and indispensable to the project. As both these groups have grown, our reach has grown. Now as a project we touch the lives of (by best estimation) hundreds of thousands of users and contributors around the world.

It is a natural consequence of such reach that QGIS has become an attractive platform for companies on which to build service based business models to their customers. From this rises the advent of 'enterprise' offerings - service packages tailored for large corporate and government institutions which need service level agreements, guaranteed turn around times, helpdesk support and so on. As a volunteer driven, grass roots project we are not in the position and do not have the interest in catering to this class of user base - it is far better taken care of through third party service providers that have the infrastructure and legal means to set up such service offerings. 

As the momentum grows around such enterprise services it is probably an inevitable consequence that tension may arise between third party service providers and the QGIS core project.In simplistic terms this tension can be seen as the dichotomy between those of us who view our work on QGIS as a labour of love versus those who see it their work around QGIS as a labour of commercial enterprise.

The reality is that much like the relationship between project contributors and our community of users, there is a huge amount of potential symbiosis between the QGIS developer community and the growing number of value added resellers providing services around QGIS: many of the improvements, bug fixes and other enhancements produced by value added resellers make their way back into the core QGIS offering, whilst the body of work produced by the community of QGIS project contributors becomes the basis around which value added resellers build their marketplace offering.

Over the years we have tried to be sensitive to the fact that many people rely on QGIS for their livelihood - initiatives such as our Long Term Release programme, the creation of test suites and heavy investment of donated project funds into bug fixing (among many other similar initiatives) have all gone a long way to making QGIS a viable platform for value added resellers. We would like to ask that resellers give the QGIS project similar consideration in their marketing and work endeavours. As such I would like to present a few simple guidelines below that you should use as guiding principles in your interaction with the QGIS project. I will use a hypothetical company 'ACME Corp.' in my examples below: 

Keep us in the loop

There is so much going on around the QGIS project we often get surprised by things people do. More often than not it is a pleasant surprise but sometimes it isn't. If you are planning some big new feature or creating a new service around QGIS, I highly recommend that you share it with the community early in your planning process. In particular for the case of new features that you would like to see in the main code base, coming along with an ACME Corp. 10,000 line code contribution with no prior consultation creates ample room for friction.

Don't present your work as our work

It seems obvious, but many miss the nuance here. If you wrote a marvellous plugins to count sheep in farm fields because it will add great value to your customers, call it 'ACME. Corp sheep counter', not 'QGIS Sheep Counter'

Don't present our work as your work

This is the corollary to the above. Our community works incredibly hard to make QGIS, the web site, the documentation, triage bugs, provide help on the mailing lists and forums. All that effort can be disregarded in a single line of careless copy like 'QGIS by ACME Corp. is the next best thing since sliced cheese'. Show a little love to the people that built the platform for your service offering and refer back to the parent QGIS project and it's community as the progenitor of all the goodness you are sharing with your clients. That does not denigrate the valuable service that you provide your customers and it lets them know that you represent your company and work fairly and contribute back to the source project that you are basing your services on.

Friends don't fork

Forking in Open Source is the process by which you create your own divergent copy of the  software and maintain it independently, often resulting in two incompatible versions (at the source code level) of the same project. Nobody really wins from that. Your customers lose the ability to migrate projects, workflows, knowledge between the community maintained version of QGIS and your modified one. Your developers get stuck in a one directional highway which takes them further and further away from the original code base and any opportunity to capitalise on the work of other contributors from the QGIS community. In reality forking is normal (its the standard workflow in GitHub for example), but I really am referring to the process whereby you create an heavily diverged copy of the source code.

Don't rebrand

Every few months I get an email from a value added service provider asking me if I can help them produce a version of QGIS which is rebranded as 'ACME Corp. GIS'. By rebranding here I mean deep rebranding - not just replacing the splash screen (which I am generally OK with), but changing the word 'QGIS' everywhere in the source code and user interface to 'ACME Corp. GIS'.  Beyond the fact that you instantly break all sorts of things like QGIS project file support, you also create a fork that will require massive amounts of maintenance  to keep in sync with the upstream project.

Integrate your team with the QGIS community

One great way to give your clients a good service and to ensure your work is well accepted is to integrate your developers with the QGIS community. By that I mean let them subscribe to our mailing lists, participate in architecture and other discussions, fix issues, contribute code, attend our 6 monthly hackfests and generally be part of the ebb and flow of the project. There are so many benefits to doing this - both to QGIS and yourself - which is probably evidenced by the fact that the most well known QGIS value added service providers each have a number of developers participating in the community. My main motivation above all other reasons is that they will gain the sensitivity to know how to get your improvements integrated into the code base, and the trust and camaraderie of the other community members which is great when the time comes that they need help solving problems.

Integrate your work with the QGIS code base

Whenever you are thinking about new features for your clients, I encourage you to think about how to make them generic enough that they can be incorporated into the main code base. Once you do that, you have an automatic delivery platform of your work to your users. QGIS has a well established release routine and the features shipped with QGIS get tested and used by many thousands of users. Besides you are benefitting from the features others are funding, why not pay the same complement back?

Don't only contribute code

For some reason coders are treated as the main hero's in the story of an Open Source project. Many people overlook the fact that there is a far larger team of translators, document writers, sys admins, authors, artists, testers and enthusiasts who contribute a massive amount of effort into the project. When you are thinking about how to contribute back to the project, take a moment to think about all the infrastructure around the project and how you might help that along along with the cool new features you plan to contribute to the code base.

There are many other things that you can do to integrate yourself into the community, but my real point in this article is that although QGIS is Free Software, it is not made for free. Many people have put a lot of sweat equity into QGIS and the only reward they get for their work (if they are lucky) is recognition and appreciation. Think of them when you build services on top of QGIS and find ways to acknowledge and motivate them!

Here's looking forward to seeing many thousands of people making their livelihood by offering services around QGIS!

Tim Sutton

(QGIS Project Chair)

—————— copy ends -------------

---

Tim Sutton
QGIS Project Steering Committee Chair
tim at qgis.org <mailto:tim at qgis.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/45649987/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timsutton.png
Type: image/png
Size: 5931 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/45649987/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis_icon.jpg
Type: image/jpeg
Size: 4642 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/45649987/attachment.jpg>