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

Sat Apr 23 04:11:25 PDT 2016

Great, thanks Tim.

Il 23 aprile 2016 12:31:23 CEST, Tim Sutton <tim at qgis.org> ha scritto:
>Of course I meant *now* published :-)
>
>T
>
>> On 23 Apr 2016, at 12:30, Nathan Woodrow <madmanwoo at gmail.com> wrote:
>> 
>> Thanks a lot Tim.
>> 
>> 
>> On Sat, 23 Apr 2016 8:29 pm Tim Sutton <tim at qgis.org
><mailto: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/
><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
><mailto:tim at qgis.org>> wrote:
>>> 
>> 
>>> Hi
>> 
>>> 
>>>> On 21 Apr 2016, at 10:00, Vincent Picavet (ml)
><vincent.ml at oslandia.com <mailto: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
><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> <mailto:tim at qgis.org
><mailto:tim at qgis.org>>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Qgis-psc mailing list
>>>>> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
><http://lists.osgeo.org/mailman/listinfo/qgis-psc>
>>>>> 
>>>> 
>>> 
>> 
>>> <qgis_icon.jpg>
>> 
>>> 
>>> 
>>> 
>>> ---
>>> 
>>> 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 <mailto:Qgis-psc at lists.osgeo.org>
>>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
><http://lists.osgeo.org/mailman/listinfo/qgis-psc>
>> 
>> 
>> 
>> 
>> ---
>> 
>> 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 <mailto:Qgis-psc at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
><http://lists.osgeo.org/mailman/listinfo/qgis-psc><qgis_icon.jpg><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

-- 
Paolo Cavallini
www.faunalia.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160423/1774e9b4/attachment.html>