Okay, my name is Johny Nock, I'm a senior researcher at the National Research Institutes
in Sweden and London University.
I'm going to give some insights and examples of how developmental collaboration can be happening
in public sector, open source products.
It's a study I did together with forensic colleagues from Spain and London, we're
Sweden as well, who have the University and other places, Johny Nock, from Cisco UNAS,
Satchegu and Gregorio.
We looked at, we crawled, seven different public sector, open source products, catalogs,
and then we find a quite narrow sample of what we identified as quite mature cases.
So we did a lot of interviews, we did a lot of mining, etc. to really find some insights
and examples to provide others in how you can go about and with doing open source collaboration
development in the public context and how that may differ towards the more general,
there may be informal practice that you can find in more products in the world.
So the cases we looked at was one example was the energy plus project, it's a simulation
program for energy consumption in the houses from the US, we looked at those two forms
from our day insurance and we looked at Oscari, map application platform, powering the
geoportal in Finland, we looked at geotrick, platform for managing and enable exploration
of national parks in France, we looked at the Mars simplifier, we could call it an
resource platform by the room in France and we also looked at the IOAP, so it's an entry app
in Italy for accessing these little public services.
So looking at the development practices, what we saw was that quite a line with open source
in a lot of context is that the development was very centered to a very few set of people,
a core team typically between two to 15 in the most cases for doing most amounts of development
as we can see in a lot of other contexts as well.
Generally an open development happening on geotrick in these cases and they used very formal,
very structured age-old processes, very detailed quality insurance processes and this
aligns quite well because all the development, there wasn't really a lot of development
happening like the cross organization, most of it was happening within the main public entity
or divender doing that development, so there wasn't a lot of community development in
these cases that we looked at.
Stuffed was generally reported high-quality, high-level user build in some which could refer
to that.
We looked at the different types of sponsorships and one kind of sort of how who develops
or who funds the development and who drives the development basically.
One major part was where it's really centered to a certain few or one or a very resourceful
organization, speed up public service company or a ministry or something.
It's typically a very business critical, this application for them, so it's really
warrants a major investment for them in these applications.
And then the more decentralized model where you have a lot of different public entities
collaborating co-funding development, driving the development more in a community way I would
call to get away with service providers in the cases we looked at.
In terms of development resources, again, it was typically performed within one organization,
one way or the other, either by the public institution in the self or through a vendor.
In case was the Pagropa where in other cases the resources was procured in one way or the
other, typically consultants in some cases, really highlighting this general notion of outsourcing
and trusting yourself on external capabilities, especially on a municipal level.
The Pagropa is quite interesting because they are the output of an experiment really
where Italy or the government wants to build their own capabilities, build their own development
teams and grow vendor independence long term.
So that was a unique in this case, but a very interesting approach.
And again, all across suppliers was really highlighted as key for the sustainability of these
projects.
There needs to be suppliers out there that can support the development because again, in
most cases, like Pagropa, you were a client on either doing consultants or having vendors
to develop the software.
So for the projects to stay sustainable, you need to have suppliers with a sustainable
business out there that can support you in this.
So the planning and decision making was typically done top down by the public entity
spending the development, either through some kind of technical steering committee, with
those involved or through direct communication between the municipality or public entity and
the vendor.
So this could be run in parallel, so they could be like overall coordination happening while
still municipality is going directly to the vendor to fast-track some things.
And in some cases, although then for the internal teams, and this is something to maybe
consider is that by how you include vendors or the service suppliers in your collaborations,
excluding them fully and just doing with the public entity and collaboration, that may
lose insights from the vendor service supplier, which could help you actually in the
development.
And also by fully relying on the vendor or the service supplier in coordinating, that
can lead to soft lockings.
So you kind of lose track of the product.
So it's really finding this balance in how you include the service suppliers and vendors
in the products.
And this becomes then a matter of how you do public procurement, for example, if you're
doing it below the fresh hold limits and you can do direct procurement, or if you're
frame, frame agreements as well, so that needs to be considered in context as well.
And there was also an interesting note in the interviews that was a large preference for
local service suppliers and vendors to have some kind of closer collaboration and relationship
with them.
And then in terms of communication, all the products have some kind of formal communication,
but a lot of the communications was happily closed between inside the organization, like
within the vendor or the public institution doing the development, but also directly
between the public entities and the vendors.
So this is also like a risk creating these clicks or isolated communication, really losing
a lot of the benefits with the openness and transparency of open source, really creating
a big barrier for others to come in and start collaborating and see what's done and so
on.
So this is also something to think about how communication is done.
Community engagement, the community were very user oriented, but we can still talk about
some kinds of contributions in terms of funding, sustaining that development, of course.
Providing subject matter expertise to their requirements in generic process, but also in
terms of the general shaping and knowledge sharing and identifying a bugs and so on.
So not not much about like the more technical code contributions here, so more about the
higher level in sustaining the projects.
The user basis, so often quite limited, is typically public sector entities, but there's
somewhat higher user communities, so not these developer communities as we find in the
wild, basically or mostly, but the number of end users are much, much greater.
So depending on how we draw, the borders of the user community, it will be much, much greater
because these projects that we look at are really core in different kinds of digital
public infrastructure or public services, so they are still of great importance.
In terms of sustainability, we have touched upon it, but in the central model, there's
a lot of reliance on this core entity, like the land survey in Finland, for example, if
they were to pivot, or if any other case, then a lot of other ministries or agencies relying
on this project would have to reconsider, and if you're in the heavily invested, it can
be costly, so it's important that open source projects in general to think about the robustness
and the bus factor or whatever we call it, how development they concentrate and what you're
doing to address this.
On the other way around in a more decentralized sponsorship model where you have a lot of different
public entities collaborating, co-funding, co-pooling money, you often need to grow up until
a certain level, a number of municipalities, for example, for it to help sustain the development
and so on.
Otherwise, you need some a certain few larger ones that we've more capability to fund
the development, but that's typically not sustainable in the long term, because again,
it comes out of reliance on someone, be it like the capital city in the country, they
want to move on, so there needs to be a sustainable funding model for public sector collaboration
as well.
I talked in the funding dev room this morning, and we talked more about these community
rooms, but it's also an issue here.
So some further recommendations, really you need to consider growing an open collaboration
involving enabling more, more public entities to come in and help co-fund the development,
grow capabilities, consider these suppliers, business models that they are profitable, enabling
that you don't end up in a lock in having transparent continuous check-ins on code and so on
to, and also consider involving the vendors and the suppliers.
Okay, that was a...
Thank you.