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

Thu Apr 21 01:44:08 PDT 2016

Hi,

2016-04-21 10:31 GMT+02:00 Neumann, Andreas <a.neumann at carto.net>:

> Hi Tim,
>
> Well written - thanks a lot!
>
> May I suggest that the same text also ends up in our website, not only on
> the blog? On the blog will not be visible any more after some time. I guess
> the bulk of your writing is valid for many years to come and thus it would
> be useful to have. The "Get involved" section on our webpage seems to be
> suitable for this text.
>
> +1. Another advantage is that it can be translated and thus read by more
people and, if needed could be easily updated.

> Maybe we should also some day write a text on how to best contract with
> QGIS developers - for organizations who ask developers to implement new
> features to them. Things like you should check how active the company is on
> Github, that unit tests should be included - also QEPs (if necessary), etc.
> Maybe this could be combined with an effort to support crowd funding
> initiatives.
>
>  +1 (again).

Thanks Tim for tackling this.

Regards,
H.

> Thanks again and greetings,
>
> Andreas
>
> On 2016-04-21 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.
>
>
> ———— 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
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
>
> _______________________________________________
> 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/20160421/3df4b7ed/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/3df4b7ed/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/3df4b7ed/attachment.jpg>