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

Thu Apr 21 01:00:13 PDT 2016

Hi Tim, all,

On 21/04/2016 07:23, Tim Sutton wrote:
> 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.

One missing point, which may seem obvious for us, but generally not for
others building software on top of QGIS : "respect the licence". Not
mixing with proprietary software, plugins and code released as GPL, no
obligation of publication but highly recommended, etc.
This may need an article per se, but it seems important to remind in
such a general post as well.

Some more remarks in the text.

> ———— 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:
> 
>  1. Our community of project contributors
>  2. 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

I would not say that there is no interest for this class of users, if
this user segregation is even true. Not only large corporate or
government institutions want helpdesk, support or other professional
services.
It would be better to present the 'enterprise' offerings as a
prolongation of the services offered by the community, in a
complementary way.

> 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.

I would get rid of this article too, which is pretty negative and will
talk only to people already having deep knowledge of some particular cases.
Why not see the future and present this as "enterprise services should
collaborate more and better with the community for the best of the project".
And I personnaly do not agree with the dichotomy. You can love the work
you do on QGIS for a commercial enterprise.
Being simplistic does not seem to be a good way to present the reality
to our end-users and companies wanting to build business on top of QGIS.
We should instead tell them that they can love what they do, be part of
the community _and_ make a living from this.

> 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,

For me LTR is much more dedicated to users than to commercial companies,
but it has indeed an (good) impact on all users for which QGIS is the
main tool in their day-to-day work.

> 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.

I would insist on the fact that forking a project is not a good idea in
terms of economics. Maintaining a software is more than half of the TCO,
and on the medium-long term, maintaining a fork of QGIS will cost much
more than integrating the specific code into the master codebase, even
if initial costs are higher for master integration.

> *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.

Question here : it seems linked with the QGIS trademark policy. Do we
have to explain it here ? Or link to some place where it is explained ?

> *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.

Can we replace "hackfest" with "community meeting" ?

> *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?

This is the pendant of "not forking", maybe move it just after the
paragraph on fork ? Also mentioning financial aspects seems important :
"making things generic and integrating master code base costs more on
the short term, but much lesser on the long run"

> 
> *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!

Maybe you could also add some statistics from Ohloh on the global
evaluation of QGIS in terms of $$$ and man-year, so as to be able to say
"look, we offer you all this, not only can you get something back, but
it is also in your interest"

> 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 -------------

Thanks for writing this and submitting it for review !

Vincent

> 
> 
> 
> ---
> 
> *Tim Sutton*
> QGIS Project Steering Committee Chair
> tim at qgis.org <mailto:tim at qgis.org>
> 
> 
> 
> 
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
> 