 Hello, welcome everybody. I hope you're enjoying the talks you've been at so far so we have here Ricardo Magliocchetti and He's gonna talk about tfw your country funds open source development. Let's give him a round of applause, please Hi everyone Thank you for being here So my name is Ricardo Magliocchetti and today I'd like to talk you about the feeling when your country funds open source development So a bit about myself I'm a patronist, of course, a software developer and consultant from Italy and In my free time, I'm an open source software contributor Most of my time spent on free software I contribute to the micro whiskey or you devil sg I project And so what I like to talk you about today. So last year I Consulted for the Italian digital transformation team, which is a unit of the Italian government tasked with making public services more accessible to businesses and Citizens so it's like a unit of the government tasked with fixing the Italian public administration digital culture, which is more or less like the Government digital service you have here, but possibly view that a lot like budge a lot less budget So I worked on the dox Italy team with these people you may recognize Maybe Yacopo, which is a Django CMS contributor Maybe so someone else someone like Francesco working in London. So maybe and With these people we built dox, Italy Which is a platform to host and share Documentation made by the public administration so Public administration like the state but municipalities regions can upload their documents so they can share with the public so Python which of course is a project within Python so a Python platform to host documentation you may recognize some pattern you and maybe you You recognize it because you already use read the docks and in fact dox, Italia is a fork of read the docks Read the docks. I think every one of you know it. But anyway, it's the leading Documentation platform for Python projects. So most of the time you read the documentation for Python libraries you possibly are reading them on read the docks so we actually forked read the docks and I mean that in Forks in old-school way like it's not just pressing the tab fork button But to site Wikipedia We forked read the docks as we are creating a dissing software like we of course press the fork button on github but we renamed our new repository and We are kind of created a different developer community community as Like as we are like a regional project like for Italy Our community speaks mostly Italian and so we like like different rules different issues and different documentation in other language and If you are old enough to remember all times like forking project world is possibly was Quite not the right thing to do Still so why a fork actually So we have to fork and we can't just use like install our instance of read the docks because We are very specific target We accept contribution only from public administration People so just random citizen cannot upload the document and We so we created quite different onboarding process to check that and We created a method as a system to make this contribution from public administration People like easier so we created a YAML format to add to a repository so our machinery can See documentation and people don't have to upload them manually So in this work fortunately, we managed to contribute quite a bit stuff of stream and we did the forty people request and 22 got merged and 11 closed possibly not very good ideas on these 22 poor request the marriage the 10 were back fixes which were fixes to Like back stack traces we got on our center instance and six were Internationalization Improvement we of course contributed a fully talent translation, but we like fixed Them Tooling used by read the docks to upload the manager translations and Doing that we have found some strings where we're not marked for mark for translation And six were just cut cleanups or nothing interesting So we but well I managed to contribute a regression to read the docks and I removed the schema from URL URL from a template and this change broke some JavaScript and the fun thing is The change was not needed and it was a wrong configuration from our side So we contributed not only changes to the redox doc's code base, but we'd Contribute a full ansible deployment to mention and read the docks is quite a complex project You have web workers. You have salary workers to build the documentation you have elastic search cluster for doing the search and You of course you have an engine X front-end so it's like a usually a multi-machine setup and so Having it automated is way better than following instruction on wiki. I guess And we managed to contribute to zero new features and I finally you maintain a Operator project. I think this is appreciated as a We haven't asked the read the docks developers to maintain our code essentially Well, we tried to contribute a feature at the time Read the docks was using a very old eluxe search version from the search Feature and it was like a 1.3 elastic search. So it was quite kind of old and And There was a request and finished to party to elastic search 5 and we tried to Update this poor request to add support for elastic search 5.6 but nobody on the team was very Um Nobody mastered the elastic search so it took a while we made mistakes and our code was not that great So by the time we were confident with our code Google summer codes student Started from scratch to support elastic search 6 which was the latest release at the time and so we dropped our effort and Fortunately it took quite a bit to the student to about this January last January Read the docks was using this new elastic search 6 code So doing this process is six months of work for me at least I Some lessons were learned. I think first one is important to build trust with upstream as Try to be part of a community as in contribute fixes comments help the people because one day you need help for from the developers and there's a lot better to Be recognized instead of being a nobody Second thing I learned is a fork is nothing more of that long-lived branch and if you maintain some code that you may know that Maintaining a long-lived branch is a can't painful because you have to keep up to date when the Code you forked the other branch is updated And so the better to fix upstream instead of carrying patches downstream And another thing I learned but I know it already Like contributing to open source software is just part of the job these days It's quite rare, but you'll have a software project without using open source software So if the software is part of your stack you have to contribute as a software won't write itself and then last lesson is a convenience is a Lot more important and purity when maintaining a fork so you have to sacrifice the better design for the convenient one and for example Really the docks is a jungle application So instead of modifying the original code that we created a new Jungle reasonable application So we can add our code there and to be more precise for example we Had to add of course some models so some database table and was The decision was to create another model Instead of changing the original wine because otherwise we had to maintain a handle conflicts on database model which Of course, it's not something you want to do and Thankfully the redox read the docks code base Yeah, it provides quite a lot of configuration like not just knobs or settings but there's a lot of entry point to override the Some the class to use for an implementation Just by specifying a ver path So a lot less code to change in fork last lesson actually is When you have to sync with a stream So you have to merge back the changes as upstream continue the development You have two choices usually the one is to merge changes on your branch And there are one to rebase your chains on top of a stream My opinion is that Rebase always better as maybe it's more painful the first time and you possibly have to manage conflict in a big way and the One year base But still your history will be a lot cleaner and having a cleaner history Will be better not only for you to handle your comment and see what's exactly different But also it's easier if you want to contribute to cherry-peak Comets Because we are atomic as the conflicts are already resolved in the same comment So you have less work to do and still possibly Easier also for a steam to see what you've changed and if I find something interesting They can cherry-peak So to conclude not our project folks are bad and our Isn't bad not just because we made it open source But because we contributed back to the upstreaming community some code some fixes and Like the important thing is like when you make something open source good chances that it's not really helpful for other people and So the important thing is that to serve the bigger community in this case the redox one and also another thing I want to point out is a You still can deliver value Why contributed to open source like? we I'm telling about a project around by Italian public administration Which is not exactly the an elite Example of working so working habit or Also and so I Think if we managed to deliver value why contributed to open source during and a public Administration project, I think you can do the same from your companies company project Private project whatever So this is all I got Thank you You can find my contacts and also references to the Italian government a github Account on github mine The speaker deck where I leave my slides my Twitter handle my site and thank you So we have time for questions. Does anybody want to ask a question, please? We're there Thank you very much for the talk Well, this is probably a question that will spark a whole new talk, but could you And give more detail about how was how did the project start like did the Italian public administration? Select what language or what technology you had to use or they gave like They assembled a team of people and then you had like more freedom to choose like how is this working out? Are the users like actually submitting documents and To the system, okay so the she's the season to use read the docs was already made because the Like the unit the Italian digital transformation team Was at the time like I think 20 people and we were mostly technologists so and Some people were Pythonistas so of course they already knew read the docs and so It was like a kind of natural solution for our problem and You know the need for a platform for documentation I I have to say I don't know where it came from but the the finger was that We we wanted a platform where we can see the difference between documents and Where we can search the documents where we can discuss the documents so there is an integration I Like Sphinx plug-in to integrate the rendered documents with discourse forum so the idea was that you can discuss the specific Like regulation or laws whatever on the forum and you can see what was people discussing on the rendered documents Okay. Thank you. Hey Anybody has other question Yeah, there Very informative talk what I wanted to ask was what do you thought with the difference in funding levels as a factor between? Let's say go dot UK and Docs Italian Sorry, but my understanding of British English you said the funding levels between gov dot UK and Okay, oh Can you give me a scale or a number? Oh, no, I was mostly a joke but now like again the at the time the digital transformation team was like 20 people and I think the Digital government government digital service like a lot more like a hundred I think at least So I think it's kind of that kind of scale I think the budget for the Italian was like a couple of millions a year Which I think is not that great But I don't have details on budgeting Well, 20 to 100 developers is a lot of money and a lot of resources. So yeah, I guess it gives a bit of the scale Do we have any other question? Whoa, turn me around Thank you for the talk. So my question isn't really about read the docs It's more of a well, I guess organizational questions. So all of the Government documents that are posted on Docs Italia, I guess that they're versioned through some sort of system, right? is every single revision of a given document available to the public and if so can members of the public Choose to edit these documents or propose new changes to these documents Okay. Well Docs Italia Italy will contain all the public administration documents, but at the moment not many administration started to contribute documents there and The publisher can decide to make some revision public or not So the the workflow usually is by publish and revise the document in private mode and when they're like Very fine with the document. They make the public and The same for revision. So they probably work And then publish a new release when we are fine, but the documents we Added to the platform Public taken from github. So everything should be public. I mean not like built and rendered But the source code always public Regarding taking into account like making edit possible from other people. I think it Depends but most of the documents I think are like loaves and regulations. So I Think They want to have a comments on the forum. I'm not like people editing the documents Okay, thank you. I saw before another question. Yeah Hey, hi. Thanks for the talk. I just a question regarding, you know You said the fork and then most of the new branch is in Italian language and it's differently organized And I just was wondering how that impacted the support of the user community in Italy like, you know, having a different language and you know, the local language if there was Any impact in terms of people providing more support or anything like that. I Like our users At the time were just like power users. So was people like very interested in the project And so usually they were kind of skilled So the platform itself didn't have much support issues But still the the the problem is like a convincing administration to Spend time on the writing of the documents. So a lot of time was spent like creating a Pandoc plugins to convert like Documents in oddity or doc format in restart a good text So most of the work Was done ahead of publishing on the platform So I think most of the work for support is like how should they write my documents to be on the platform and But Like I worked only on the Python side, so I can't Detail in that but I think for us it was like No, no, no support issues to from our users Yeah, so we have now run out of time So if you have any more questions or anything, I guess he will be around. Yeah. Thank you very much I and personally I have had that effort and yeah, I know what you're talking about So I think this is very useful advice that you gave so thank you so much for your talk. Thank you