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

Sat Apr 23 03:30:33 PDT 2016

Thanks a lot Tim.

On Sat, 23 Apr 2016 8:29 pm Tim Sutton <tim at qgis.org> wrote:

> Hi
>
> For anyone still following this thread, the final article is no published
> here:
>
>
> http://blog.qgis.org/2016/04/23/promoting-and-using-qgis-for-the-enterprise/
>
> Thanks again for all the input!
>
> Regards
>
> Tim
>
> On 23 Apr 2016, at 12:25, Tim Sutton <tim at qgis.org> wrote:
>
> Hi
>
>
> On 21 Apr 2016, at 10:00, Vincent Picavet (ml) <vincent.ml at oslandia.com>
> wrote:
>
> 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.
>
>
> Ok I have added a section about the license to the text, thanks.
>
>
> 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.
>
>
> I get what you are saying but I think the distinction is still there: I
> don’t think QGIS.ORG <http://qgis.org/> ever wants to position itself as
> a commercial service provider around QGIS, providing SLA’s and formalised
> helpdesk. At least it is not on my roadmap for QGIS, it it is on the
> roadmap of other community members I have never heard it raised. I would
> rather community members do it through their own companies where they can
> manage risk, law suits, grumpy users etc. as part of their contractual
> obligations. I tweaked the wording a little to make things clearer I hope.
>
>
>
>
> 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.
>
>
>
> Well I think this is largely the point of the article: As QGIS grows and
> enterprise venders enter into the equation, people start representing the
> project with two or three degrees of separation from the project (e.g. the
> marketing guy in the basement who is more concerned with how to promote the
> interests of the company) and don’t necessarily hold the values of being in
> an Open Source community close to heart. I made a few tweaks the wording to
> try to echo your sentiments above.
>
>
> 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.
>
>
> It is for users, but part of the intent is also that commercial companies
> use LTR releases for their support SLA’s and contribute fixes back to the
> LTR so that everyone gets a more stable LTR to use as the basis for their
> SLA’s.
>
>
> 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 ?
>
>
>
> We have this:
> https://www.qgis.org/en/site/getinvolved/governance/trademark/index.html -
> I put a link to it in the blog article too but rather in the ‘don’t present
> our work as your work’ section - thanks!
>
>
>
>
> *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” ?
>
>
>
> Awwww ... I always feel like a little of the fun oozes out of the project
> when we do that ….
>
>
> *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”
>
>
> I had a slightly different intent here: I wanted to encourage companies to
> design their features in a way that they will be generic and acceptable to
> the community. The ‘don’t fork’ maxim only carries weight if we are
> actually willing to incorporate their changes. I will add a note about
> using QEPs etc to hopefully make my intent more clear - thanks.
>
>
>
> *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 !
>
>
> Thanks very much for all your input Vincent - I really appreciate it!
>
> Regards
>
> Tim
>
>
>
> Vincent
>
>
>
>
>
>
> ---
>
> *Tim Sutton*
> QGIS Project Steering Committee Chair
> tim at qgis.org <mailto:tim at qgis.org <tim at qgis.org>>
>
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> <qgis_icon.jpg>
>
>
>
>
> ---
>
> Tim Sutton
> QGIS Project Steering Committee Chair
> tim at qgis.org
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
>
> ---
>
> *Tim Sutton*
> QGIS Project Steering Committee Chair
> tim at qgis.org
>
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160423/c9dd7741/attachment.html>
-------------- 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/20160423/c9dd7741/attachment.jpg>
-------------- 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/20160423/c9dd7741/attachment-0001.jpg>