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

Thu Apr 21 00:09:34 PDT 2016

Hi Tim,

This looks really good to me!

Thanks you for taking the time to write this article
Matthias

On 04/21/2016 07:23 AM, 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.
>
>
> ———— 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 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>
>
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc

-- 
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/8ac1ff2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5931 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/8ac1ff2e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4642 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/8ac1ff2e/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160421/8ac1ff2e/attachment.sig>