Well, hello everyone. Good evening or good morning or good afternoon depending on where you're at. I'm Charles Echoll, really happy to be here today. Although I kind of wish we were in Edinburgh or somewhere else cool like this, I was one summit for this with this T-shirt, but presenting to you here from my home instead. Still very excited about the topic and that's about using GitHub at a large corporations to really work on open source and share open source collaboratively with the community. I currently work in the global technology standards group within Cisco and before that I worked within DevNet. And in both cases I was doing a lot with both open source and with standards. With that light, sometimes we were sharing open source that was really more sample code just trying to help you understand our APIs and how to use them. In other cases, we were actually starting substantial open source projects where we wanted to work with people from other companies and in combination with the standards organization to improve the standards work we were doing and create artifacts that developers could use. There was a variety of use cases there. And then there's also of course, all the great open source projects that are in the, you know, in the Linux Foundation, those tend to be the much larger efforts. So I'm not focusing on those Linux Foundation projects because I think we have great governance and tools and ways of doing things that the Linux Foundation takes care of us. That's why we bring those projects in. But I'm talking more about things you want to open source that you're doing within your company and you want to do it responsibly and work together with the community. That's really the focus of this talk. So I'll start out by just kind of reiterating that goal and then show you what was actually happening within Cisco. The majority of this talk, I'll be talking about GitHub and the way that we've been using GitHub. Not that this is really meant to say, be an endorsement that you have to use GitHub, but the reality is, GitHub is the way that a lot of people are sharing code today. It's a great way to share code. A lot of what I'm saying probably applies equally well with just slight tweaks if you're using some other system there. And I think that's one of the next steps because although I think we've made some improvements that they're still certainly a long way to go. So the idea here was really, as I mentioned to collaborate on code and share code and content with the developer community both inside and outside of Cisco very important that we could engage with none. This wasn't just for Cisco internal use we really want to engage and accept contributions and work collaboratively with people outside of Cisco as well. What I got up with very quickly was really what I've heard is Wild West and with GitHub, it was just so easy and continues to be so easy to create a GitHub board, name it whatever you want. It's free, have public repos, start sharing code right away. It's very empowering. Even if you have good intention and meaning to do the right thing, it can very quickly and it did for us lead to a lot of different GitHub orgs being created that all were related to Cisco run by perhaps Cisco employees or people who had some affiliation with or used Cisco equipment. And it was great that there's a lot of code out there but as you can see from the search results on the right hand side. It was also a little confusing because you get back a lot of results and you're not sure like, is this the official one or are there many official Cisco ones where should I go. And oftentimes it was hard to know what that board was for, or who to contact if you wanted more information. So, that's really what we wanted to address. And I'll walk through a couple ways in which we've done that with a couple of those GitHub orgs. So, first, if you're not familiar with with GitHub and the concept of a GitHub organization or an org. This is really just GitHub definition it's shared accounts for businesses and open source projects can collaborate across many projects. So the idea is you have an org, an organization, and within it one or more projects, which results in one or more repositories or repos as people often call it. And there are a lot of tools a lot of mechanisms there for setting up different rules and restrictions and permissions and ways of collaborating. So, so there's a lot you can do and that's great. And it's completely free, as long as you just use public repos. If you want to have private repos then repositories then that's where you start to have to pay. So you can see where this very quickly led to a large number of GitHub works out there. Now, the first question that really came to mind for us as we have all these GitHub works. And it's confusing that they all exist. But do we really need to get rid of all of them and make just one is that appropriate or do we just need to clarify what each of them is for. And our thought was, you know, we do have different orgs with different things they're trying to share. There really isn't a way a concept of nesting organizations like these are all, you know, within the larger GitHub. Sorry Cisco org, but now all these multiple different orgs within it. So, what we decided was, we'll have many orders. That's just a fact of life. But the key factor is governance and the governance for each org needs to be clear.  So let's just clean up the orgs that we have, and find a different mechanism for making it easier for people to find the right one. Here's an example of one that I'm an owner of the Cisco DevNet GitHub org. And just a few things just to show you what we've done and it wasn't I think these are this is a good starting point. We have a very clear description of what the GitHub org is for. It's a place for the DevNet community to access sample code and collaborate on open source projects that are used in some way in DevNet. So pretty broad, but yet also descriptive so you know what type of things you'll find within this org. Very important there's an email address. This is so you can contact us if you have questions. And a lot of people don't put anything here so then if you're unclear or just need some help, you're kind of stuck. So you see this is something that's relatively new this verified what this is telling you is that the people who set up this GitHub org actually own developer dot Cisco dot com have control of that domain and of Cisco dot com for this email address. So that gives you at least some assurance that if you go and the code here and if you contact us that it really does come from the DevNet team within Cisco, which if that's what you're looking for it now you have that assurance. So you know I think that that's a good place to start. If you don't have these things clearly done for your GitHub org, you know I suggest you start there. Now here's an example of another GitHub org. This is the Cisco Systems GitHub org and this one tends to have sort of larger projects in it. The description, not as specific but still at least gives you an idea it's open source projects from Cisco Systems, you can see the domain's been verified so you know that you know we're really are authoritative for Cisco dot com domain. Who to contact in this case it's fluffy if you happen to know fluffy, then that's a great assurance to you because you know, you know he's fantastic with open source standards and a great kind of work with. If you don't know one then perhaps having an email address like that is not the best so if you think about a first time user maybe this isn't exactly what you want to do, but at least there is someone you can contact so I say we're in pretty good shape on this one as well. So the next thing is public versus private, and I mentioned this earlier on there's a concept of everything is free as long as you make it public. And when I said that I was speaking in respect to the repositories or repos or projects. So if they are all open source everyone can see him for us when we're working as Cisco working in the open source space. That's really the goal right is to have public repos. And the other thing though is people, you can see we have almost. We have 800 repos 200 people almost. And that's, I see all all the projects I see all the people because I am a member of the org. If I log out though. And I'm no longer met or not a member of the org. That's what happens with the second screen. You can see a lot of the projects went away. But maybe more importantly in some ways, a lot of the people went away. And now you only see 12 people instead of 200 with, and what I've seen with a lot of orgs is this number of people actually drops to zero. So then if you didn't have a contact here, or if you didn't know any of the people are who to contact, you could see where this would be a real problem. So I looked out for that because, by default, people are private, which is nice for, you know, privacy considerations, but it is hard if you're trying to work with a community if you don't tell anyone who you are. So, so think about that. And you can see, even though I've been, you know, recommending this to people, we still only have 12 people who have changed their profile in the public. So, not always an easy thing to do. Because a lot of people have very cryptic user IDs, just do the nature of, you know, a shared namespace, right. So the other thing I recommend is make sure that even though GitHub doesn't require it include the name by which you're known, it may not be your official name but the name by which people actually know you include that in your GitHub profile. So when someone's interacting with you via GitHub, they actually get that assurance that they're talking to the right person rather than maybe making a mistake with a cryptic user ID where they maybe get one, you know, put a one for an eye or something like that. And then all of a sudden they're working with the wrong person. So another really important thing in addition to that kind of one line description that I had at the beginning was to provide some examples of what type of projects what type of code is actually appropriate for the Cisco DevNet work versus what's not appropriate or maybe is more appropriate for another work. So this one was Cisco DevNet. The idea is we're really trying to help developers with things like sample code with here's how to use a Cisco API. It's really focused on Cisco products and platforms, and how to use them, or at least Cisco technology so we do a lot with network programmability. So things related to standards like NetConf and ResConf. Those are great too. But we wouldn't want to see something that was had like no relation to any Cisco product or any Cisco technology. That wouldn't be necessarily a good fit. So similarly, we don't want to put things here that we have no intention of open sourcing. We could put a lot of code out here make it private so that no one we would see it unless we wanted them to see it. That's, that doesn't really make sense right that should be on like an enterprise GitHub or behind some firewall. So this gets back to the governance I would say don't mix and match things that are really meant for public consumption, whether they're, they're a public, you know, and shared an open source right now or not, but only put things there that you think would eventually be useful to the community that you're trying to serve. Now, an example of the Cisco org that we mentioned before there, you tend to see slightly different projects they tend to be larger they tend to be projects that are not as closely tied to Cisco products and APIs, because what we're really trying to do there is we see something an industry need, not yet industry need that we're trying to drive and work collaboratively and in some cases these projects might even graduate to become like a Linux foundation project. But in other cases we're just trying to set up something we're working collaboratively with the community for something that's important to Cisco but important to many other people too. And so we tend to have fewer projects there they tend to be larger the governance and the maintenance of them tends to be a bit tighter. We really keep a closer eye on these projects right, because they're not just sample code and you know quick things to use that they're more established projects with a wider base of contributors. So, just at a very broad level, at least we've established a clear way of when you should put something in the system of DevNet org versus in the Cisco org. So that was a great start for us. Now archives, this is interesting because when you first start, you're kind of anxious to get more and more code the more the better. But over time, some of that code is either no longer relevant no longer useful or just not being maintained anymore. I did a lot of work with open daylight, a number of years ago, and we did some boot camps that were, you know, really really, I think they were fantastic to bring people up to speed on open daylight. However, that was five years ago, we're not actively maintaining that and the information there's very stale. So fortunately GitHub offers this nice mechanism where you can archive free pose. And I recommend you make use of that. It's better I think than deleting it, because some people might actually still find something they're useful. But when you archive it, it marks it as being archived and read only. So that's great. Now if you do have code that's very like useless or empty, you created a repo no one ever did anything. Now those I would probably get rid of right no reason to have noise around so deleting those types of things I think is good. But archive things which are usually useful but just no longer, you know, actively maintained. Okay, going to shift gears now to membership and permissions and GitHub offers a lot of options here and certain things are done by default. So what I'm going to do is point out some of those things and show you where we've deviated from the defaults and why we did that. So members of some roles you have owners, you have members and you have outside collaborators. By default when you add someone in, they are a member. And then you can elevate privileges to owners, or you can also put people in as outside collaborators. And there's a good way to use each of these. So owners, those are like your super users, they have access to everything in the GitHub work, they can change things like the description and the email address that I showed you earlier. And, you know, they have broad range of access and permissions. Now, we currently have 20 owners in the Cisco DevNet GitHub work, and that actually worked well for us in that it was very empowering. Everyone in the team basically became an owner and could create repos and so very self service. But I would say it's actually not a good thing, because that's just a lot of people who could possibly be doing things different. You really want to have, I think, finer grand control and think of other ways of, you know, making it easy for people to get the work done that they want to get done. One thing we did do is we enable two factor authentication, because we did have problems with either through use of API's or other mechanisms people's accounts getting broken into. And so at least with two factor authentication, we've actually never had that happen. So this at least, you know, when people start doing things as owners, at least we have more assurance that they really are owners. What I would propose would be better though would be if we only had three to five owners, and they should be people who are, you know, real stakeholders of the DevNet team. And I think that would be better. But at least two factor authentication, make sure that your name is there. So you get that assurance that you're talking to the person you think you are. And then we require that you associate your Cisco email address with your GitHub account. It doesn't need to be the primary one, but at least it's a mechanism through which we make sure we can communicate with the GitHub owners using their Cisco email address. Because there could be something sensitive if we want to, you know, talk with them about, and that's a good way to do it. So members I mentioned this is kind of the default role, and we have about 150 members right now, most of them are Cisco employees, some are not employees. We basically made everyone members, initially, when we wanted to accept contributions from them or wanted to give them access to rebos. I don't think that was necessarily the best way to go. What ends up happening is your members by default have access to all of the private repos. And so, if you think about that and why you might be having private repos, you know, we probably don't want to have, say, non Cisco people is having access to private repos, even though eventually we want to make those public. If we're making them private, there's probably a short term reason for that. So we've not that we haven't gotten rid of a lot of members, but we, we don't add people as members as often anymore. Two factor authentication, very important there. And the biggest thing is, by default, all members can create new repos, and we didn't want this. We said, hey, only owners can create new repos also only owners can change a repo from private to public or vice versa. This is important to have it read because it's an important default that we, for us, it was very important to override this, especially when we have 150 plus people who are members and some arts is called employees. So, this way we restrict the least the permissions of the members a little bit. If you ever need to be able to do something and you don't have the necessary permissions, you just send an email to they get a bonus alias, right, and there's a set of us that will help you along. So that's important to if you're going to restrict access, you need a mechanism for people to request what they need, as opposed to what we did initially just giving everyone, you know, the access and self service that they wanted. So I'd say it's better to restrict a bit. So outside collaborator. This is one I really I didn't know what it was at first and now I'm a big fan of it. And we have over 500 people who we've added this outside collaborators. A lot of them are actually Cisco employees that many are not. And the way that this works is whenever we give anyone right access to one or more of our repos, if they weren't already an outside collaborator that they out like automatically become one. So it's a way that they can be associated with our organization, they can have right access but they only have permission to work with those repos that they're, they're actually supposed to now they probably have they can have read access to everything right, but they can't. So we don't have commit access necessarily a right access to anything except those where they've been granted. And that makes total sense from an open source perspective right now everyone has right access to every project, usually have an established number of committers who have that so that's essentially what this allows us to do. Here as well though, two factor authentication, include your, your name with your GitHub account. That's just for everyone, I would recommend doing those two things that that helps a lot. Okay, so that was individual permissions and types of roles. Now teams is a way that you can help with some of the say TDM of when you have a lot of say outside collaborators, and you want to associate. A common set of permissions with with them. So perhaps like we have a bunch of learning labs and perhaps we want a set of people that have access to or commit access to all learning labs, but not to anything else. So we can put them in a team that has access to learning labs. So we found that that's very useful. Now, what GitHub says is that this should reflect your org structure. That I don't think is true, or at least it depends on how you look at it. It, I would say your team should not reflect like for us should not reflect Cisco's organizational structure, because that has nothing to do with access rights to our open source code. It should instead be based on the function of the task, as I mentioned, like people who need access to learning labs, having a team for that I think is a good way to go. Another model that we've used very successfully is within the Cisco or what we do is every single repo has a team associated with it. And basically, if someone's supposed to have access to that project, we add them to the team. And so your access is controlled by the team. If you aren't a member of the team, you won't have access to the repo. This results in a lot of teams, but we have very fine grained access and it's really easy to tell exactly who has what access to each repo, and to maintain that over time. So there we needed to be a little bit more careful with who the committers were. And so that was a way we were able to do that. So looking back and not just what I'm saying you should do, but what certainly we've done and works well for us is repos are the main guardrail and source of freedom. What I mean by that is that only owners can create new repos. So to get a repo is kind of a big deal. But then once you get it, if you have, you can be given very broad permissions within that repo, and that's what we do. If someone needs a new repo and I think it's a good idea, we create that repo. I can even make them an admin of the repo. They can do everything with that repo, even though they are have no permissions say with any other repos they have no right access to any other repos. So someone who was not a member of our org I can even assign them as an admin of a repo. And this happens quite a lot. The repo admin has brought control over the repo that they're an admin for, although here is another thing where we overrode the default. It was important for us that in addition to creating repos only owners can change the repos I think I mentioned this before from public to private and vice versa. By default the admin could do that for the repo that they're admin of, but we restrict that. So admins can't do that. The only way for them to have the status of their repo change from private to public or vice versa is to ask one of the owners to do it. Okay, so that's it for permissions. No contributions. I mentioned up front one of the big goals for us is of course we want contributions right we're trying to work with the community. We're trying to put code out there that's helpful but we want contributions back. And these contributions can come in many forms. It could be, you know, starting a repo to let us know it's useful. It could be submitting a bug report. It could be giving us a patch for a fix or, you know, for corrective spelling mistake and a read me, or it could be, you know, adding a really cool new feature. So that there's lots of different ways to interview or could even be starting a whole new project. So one thing that's very important is, you know, we welcome we encourage contributions. It could be a member of our GitHub or to contribute. What's important though is to have make it clear how people can and should contribute. And so the common way to do that is by having a contributing file, and there you list how people can and should interact with you, what types of contributions you're looking for what's a relevant or what's the way to go about doing that or the best way to go about doing that. And you don't necessarily have to have a contributing file. That's the way I would recommend, as long as you make this information available either in the read me or I would recommend creating a contributing file. So we try to do that and make sure that that's always there. Code of conduct. Now, we don't require this but but I think it's really good practice. And having a code of conduct file it's very straightforward easy to add. It really helps foster an open and welcome environment, and it just establishes those basic ground rules that we all probably hopefully consider as common sense, but it's nice to just put them out there. And it just helps make participation, you know, our harassment free experience for everyone. And you know that's really what we want we want to make it easy for people to contribute for them to feel comfortable contributing and for them to have you know their voice heard and all that so Code of conduct, pretty straightforward easy way to go about, you know, making an improvement in that direction. Now, contributing the whole new repo. I mentioned you have to contact us if you want to get a new repo created. But then we also want to help make sure that when you create a repo it's not only useful code, but it meets our guidelines or our conventions.  So we actually write them down and they come available to you. And I think that's important to do. An example here is we have templates. So you don't have to use the template but at least by looking at the template it gives you a good idea of appropriate use of a read me of a license we always require a license that contributing file that I mentioned before. And in this case, the code of conduct is also in there. So we make it very easy for you to copy this clone it do whatever you want. You can use cookie cutter to last you a few questions. And then it kind of automates the production of a start of a repo for you. The goal being we want to make it easy for you to do the right thing. And actually most developers are happy to do that. If they already have that code, then at least they can use this as a reference, so that they know before they bring it to us. Oh, these are the types of things they look for. So that served us really well. Now, in the case that where they did have their own repo if they're bringing it to us the common way we work with that is you can transfer it from where it currently exists into our GitHub work. You just contact us like you would if you wanted to create a new repo. In order for this to work. What I found is, you can't transfer from like your personal GitHub account into our GitHub org, you can only transfer from one org to another. And so the easiest way to do this that we found is, if you don't already have a GitHub org that you can use create one sentence and they're free. In one case where it's very handy, create your own GitHub org, put your project in there. Make one of us who is an admin of that are an owner of the Cisco DevNet GitHub org, make one of us an admin. And then if you're an admin of a of two different orgs, you can transfer repos between them. So we can take your repo and transfer again in its entirety. And that's worked really well for us. So long live forks. As a general rule, we don't want to fork of their open source projects and maintain and work on our own forks of projects within the Cisco DevNet GitHub org, right, better to work upstream work with the community. However, in some cases, we've done this, not because we actually intend to start a different project, but just because it's helpful to have a group of people work on something. And then, once it gets to a certain state then you know upstream or contribute the set of fixes or a larger change. In this case, NC client, that's one place where we have several people within Cisco who are working in collaboration with the NC client community. We actually have a fork of that project. And what we did was we put in the README a note to let you know, hey, this is a long term fork. It's just here to facilitate us working on it and sharing things upstream. So this way we at least let people know our intentions. I don't think it's ideal, but it's the best thing we could come up with. And if you have a better idea, let me know. But this is what we do. And it seems to work, you know, reasonably well. Okay, now I'm not a lawyer. I have been a fair amount with open source licensing and copyright and I'll just start off by stressing that this is super important, because without appropriate licensing or copyright. No one has the right to use your code. You haven't told them what the terms are, and therefore you have not given them, you have not open sourced it, you have not given them any right to use your code. Anything actually isn't a good thing. It's not a automatically open sourced or something like that. So it's important to license things and to work with your legal department to license things correctly. One challenge that we've had is if you think of the use case I mentioned of like sample code, just putting small bits of code out there that are useful to the Cisco community. Maybe you're not appropriate to be open sourced, or what's more typically the case is that they're perfectly fine to open source, but we don't have the time to go through the due diligence of working with legal to really make sure that, you know, get permission to open source something. I think it really lightweight for engineers to create sample code to share that with with with customers with partners just with the community at large. And so, and we were having a problem with doing that, because you couldn't get approval for open source quickly enough and efficiently enough. So it was we came up with the Cisco sample code license. And this is not an open source license, and we try to make it very clear it's not an open source license. However, if you're using it in combination with Cisco products and services, it does give you the right to use it to modify it and that type of thing. It's not restrictions like you can't use it to create a product in competitive with with Cisco. So it's certainly not open source it's proprietary, but by putting this this license on it, it allows us to share the code very quickly and easily without jumping through a lot of hurdles with the Cisco legal team. Now, in our mind, there's no downside to this. It's, we're not abusing open source, we're sharing code that we probably couldn't have shared otherwise or at least not shared so quickly. And we certainly lean toward open source when when possible, or when appropriate. And the other thing is, when we license something using this license. And if we find out that that's problematic for someone, we ask them to come to us and you know let us know that hey, you know this Cisco license I can't get my legal team to approve it or this is giving me grief because of my use case. And we can always open source it then if we see there's a need, then we can spend a little bit more time go through the due diligence of going through the licensing and open source it. So, so far this has actually worked out quite well, and I was a little nervous at first about bringing this out and talking about it and open source conference, but so far the feedback I've gotten has been good, because, again, it's all about just being clear with why you're doing something and, and what its intention is and I think it's worked well for us. So in terms of open source licenses, there's there's a lot out there. Just to simplify our life, we tend to lean toward when there's not a reason to choose a different one, one of two licenses the BST three clause of the Apache to another license. And like, because say we're using a lot of MIT code in our dependencies or something like that. Then we actually tend to go with whatever aligns with the other code that we're using so we might go with MIT or something like that. But, but just in general if you have a choice to make and you don't have a reason to go with something else you want to open source it. We use these two and we use the BST three clause for kind of smaller efforts sample code, and we use the Apache license for kind of those larger efforts, because there's a little bit more in there around community and patent rights and, and we tend to get more due diligence into something. If it's a larger effort and then we release it under the Apache license because it tends to be a little bit easier than for people to come around it and work collaboratively on it together. That's just a very broad brush over simplified thing but fewer licenses we have found is easier than more licenses just for people to wrap their head around, and then choosing between these two. Again, there's no hard set rules that's just a general rule of thumb. Beyond licensing though what's what we found is really important is for the types of things that I'm talking about the sample code in that a CLA or something like that was was wait, you know is overkill. So we don't need that, but definitely having a contributing file having the code of conduct that sets the right framework in place. And we found that that works quite well for us. And so figuring out the licensing is is is important, but we just want to make it easy to, and we want to make make it as easy as possible for people to do the right thing. And that's why we've tried to simplify it as much as we can, even the licensing is a very complicated subject. Okay, I'm going to jump forward to navigation now. For us navigation is is important and it's important for us to think about because, as I mentioned at the beginning we have all those different GitHub orgs, and I focused on the Cisco DevNet one and the Cisco one, but all those other ones still exist and a lot of them have great And they exist for a great reason, and they've, you know, now have good governance behind them too. So we're not trying to eliminate or reduce GitHub orgs although now we do try to steer people toward using one of the existing ones. And we have consolidated in a few cases, but there's still multiple works out there. And, thankfully, there's a lot of great code outside of Cisco outside of Cisco boards that is tremendously useful to the Cisco community and works well with our products too. So, being able to find this code regardless of where it exists is is important. Our early efforts were what you see here we basically said, here's all of the GitHub boards that we know of. Let's just scan them. And if they have a read me that's more than 50 or 100 characters. And if they have a license that is OSI approved. That's, that's good enough, right, let's just add them to this set and let's, let's put them up on this page. So it was basically an auto generated page that just stand repose. And we had multiple different pages with different criteria in mind, some that looked specifically for sample code as an example. And this was partly just seeing what we could do but also trying to provide a useful tool to the community. And it was certainly better than nothing. And an important thing was to it when people did find these and they said, Hey, why, why isn't my code there or why is my code there to make it easy for them to contact us and say, Hey, I want to opt out or I want to opt in. And as we started to think about it more we're like, you know, this probably isn't the best way. We created something called code exchange. And the idea with this is it is really is an opt in mechanism. It's a curated set of repose related to Cisco technology. And, and we provide some search capabilities and some, you know, metadata and intelligence behind giving you back results that are intended to make it easy for you to find code that that you need code that's useful to you to get you started on like your access to Cisco products and solutions. Anyone can contribute repose don't have to be a Cisco employee. And we actually really encourage and do get a lot of contributions from from partners and people in the open source community in general. To submit a repo into code exchange basically to opt in to have your, your repo there. It needs to be related to Cisco technology, because that's what all the repose and Cisco code exchange are. We really look at your read me quite closely to make sure that not just that they exist, but that when we read your read me we understand what your code is what it's for how to use it how to install it, all those good things. And actually how to contribute back to so whether you have a contributing file or you just include that in your read me. It needs to have an open an OSI approved license. So one of the licenses recognized by the OSI, and the law asterisks there is for the that Cisco sample code license, which we do accept as well. For the reasons I stated earlier. It's publicly accessible on GitHub, not not much use and sharing code if it's not a public repo. And this is the hard one evidence of the repo being actively maintained. We can actually see that that is the case when we first accepted, making sure that that remains the case over time I think that's, that's not going to be tough for open source in general, but not with the projects that we bring into. So then you hit submit, we see that you want to, you know, contribute your code, and we'll work with you if there's any changes that we think are needed or in order to accept it. And just to get an idea we're not trying to, you know, force you to like copy and paste or maintain a whole like bunch of separate information. All we do is we really intelligently look at what's in your GitHub repo and as you can see here, the repo is on the left. The, what it looks like in code exchange and the tile of the search results is on the right. And we're basically taking the description or the beginning of the read me from your repo and using that to populate the results. And the other thing you can see here is that this is kind of good to show actually the top three results that just happened to be here at the top of this page. This is telling me what GitHub org gets from. So this is from the Cisco DevNet GitHub org. This is from the Cisco Systems GitHub org, and this is from the Cisco GitHub org. So, just showing you that these results can come from multiple different GitHub orgs. And we're not trying to, I guess all we're trying to do is make it easier for you to find the code that you're looking to use in GitHub. So that's actually worked great for us. Now, next steps before I run out of time and hopefully have some questions, some time for questions. So we've made a lot of progress, both in terms of tying up our tidying up our governance, working with the community more consistently making it easier for you to find code with code exchange, but there's there's definitely a lot of work for us to do. So before you vulnerability for security vulnerability, GitHub has actually added some really nice automated functionality there to let you know when you have vulnerabilities in your dependencies. And that's that's a great thing. I think we need to systematically work to make sure we address those and probably do a bit more than that too. I don't have that in place yet, an audit process. I mentioned it's easy to check the code when it first comes to you, then to make sure it stays fresh that people are, you know, addressing issues that they're with a security vulnerabilities or otherwise. That's important. Perhaps even more important is establishing and tracking metrics, because, I mean, certainly from my perspective, I want to be able to show that all this great work we're doing in the open source community. Has value that people are using it that it's growing that we have traction with it right that way I can justify that we spend more time working on open source and in creating tools that help you find and use it. Now the governance around Cisco DevNet and the Cisco GitHub orgs I shared that with you here and my rationale for it. I would actually like to make that type of governments more pervasive across all of Cisco, and all of our GitHub orgs so that even though we have a lot of orgs, you have a similar governance hopefully behind all of them, even if the type of projects they accept are consistent if the way that you work with us and you know kind of the the mechanisms they are consistent. I think that would be helpful. And then to improve our Cisco corporate open source contribution process. And that Cisco sample code proprietary license that we created was a great work around for this, and it probably even deserves to continue to be used, but we're seeing more and more people wanting to open source things which is great, but we need to streamline the process and make it easier for people to do the right thing and to get the help that they need from legal or from open source experts, so that they open source correctly. And so those are just a few of the things that we need to work on, and that hopefully I'll be able to share progress and talk with you at a future date. So here's a few links that I just wanted to share. The the Cisco GitHub orgs both on Cisco DevNet and the Cisco one to code exchange tool that I showed you are a template repo that has helped us a ton. So take a look at that. Use it as inspiration. If there's things that you question in there that you think like hey these guys kind of missed the bone on something by all means let me know. I'm not operating on it. A lot of people using it. I'd love to make it better. I know it could be better. So, you can contact me via email, Twitter. And with that I have a few minutes, I will open it up for questions. Before I do just want to say thank you to all of you weird being to presenting remotely, but look forward to engaging with you through questions and afterwards so I'm going to go back to this slide. And just so that you can have those links and then again just say thank you and look forward to chatting with you about open source more.


They've got to show their diversity and it builds up the choice to break down that wall and build harmony between indigenous people, communities and the QPS. It's very open to see, it's very well explained, people are starting to grow with it and hopefully we'll see a lot of good programs come out of this that will co-join police and community together. It brings me to a sense of calm because it just shows like what can be put into something if you really believe and try hard.


Hi, welcome to the webinar, Translate Customer Feedback to Product Features. I'm Priyanshi Mithil, I'm a senior product manager at Microsoft, part of the cloud and AI group, and part of commercial acceleration team. Customer feedback is very important and crucial for your product at every given state. Today in the webinar, we are going to talk about why it is important and how we can translate and take that feedback to actual product features. We are going to start with why do we really need customer feedback? We will then cover a lot of different aspects of going through the flow of translating the feedback that we can collect from different channels to actually derivative the product, starting with how to sort feedback from different channels, understanding specific use cases, categorizing and prioritizing the feedback that we get from the customers, creating wireframes and prototypes, feedback to with customers, implementation and launch, and how do we measure success over time? But first, let's start with a meme. And I believe you might have already seen various versions of this meme, but I edited this to fit this topic. You see how the information and implementation gets changed in every step, and in fact, even the customer is not fully aware of what they really want. So if you look at the first picture, that is how customer actually explained what they want, then how product manager understood it, then based on the product manager, how the designer designed it, how the engineer actually implemented it, and what actually customer really wanted. And there's a huge difference if you see what customer actually explained and what the customer really wanted. We are going to cover in this webinar about what customer really wants and how we can decipher it. Why customer feedback is important for product element. First of all, identifying the features and functionality of customers concern. Feedback is also essential to the iteration phase of product design. Customer feedback is an insight into what is working well about your product or service and what should be done to make the experience better. Secondly, you are able to discover customer's pain point. Customer feedback is the fuel that will help you connect the dots between design, technology, business to create amazing products, amazing products that your customers would love. Once you understand your customers, you will be far effective in communicating their needs to your engineering team, design, and business teams. Thirdly, it provides useful ideas for product improvements. If you are constantly asking customers to provide you with feedback, you are establishing a continuous improvement for your product. You are able to highlight product innovation investments. When you are involving customer in this process, you are communicating that their attitudes and opinions matter. You can identify what's working and what's not to ensure your product adheres to their needs. Not only does this create a positive user experience for the customer, but it also boosts loyalty for you, your product, and your organization. Can give you a competitive advantage by ensuring customers are satisfied with your product, listening and responding to their requests and need. Taking these steps to solicit feedback throughout each phase actually results in your best product going to market and hence will give you that competitive advantage. Now let's look at different channels to get the customer feedback from. Firstly, field and sales. They are a great way to get feedback. They work with customers day and night and know them and their pain points much better. Similarly, customer support and success teams would have a great database of issues, feedback that they hear from customers on a day to day basis. You can also leverage this by going through the support tickets and the incidents that the customer create to understand what pain points were problems to their face. During the product lifecycle, it is also very beneficial to get feedback on an ongoing feature through usability studies that you can conduct with your customers while you are actually designing and we will go through that as well. As an enterprise product manager, you spend a lot of time weekly talking to your customers and understanding their issues and problems. This is a great way to interact and get details one-on-one. You can also set routine processes that work for your organization. So for example, different feedback channels like voice of customers to get consolidated feedback on your product by chosen set of customers. At Microsoft, we have something called unified voice of customer where we collect a lot of different feedbacks from our set of customers for our products. Lastly, asking NPS and feedback on the product interface itself is a great way to get direct and filtered feedback. Let's move forward and now see how do you actually understand the use case? You've got a lot of different feedback from different channels. Now it is important to once-ordered all of that and find the most meaningful and actionable feedback. Filter out generic positives. Oh, I love your product. Generic negatives. I totally hate that product. Junk, this is useful for nonsense feedback like blah, blah, blah, which you cannot actually use in any way. So let's go on to why do you want to understand the feedback and what it takes to understand that? Generally, customers will only give you what? It is also important to understand the how and why to make sure that the actions from the feedback is scalable and you are not just solving pain point for just one customer and not relying on the face value of the feedback to implement the features. Let's take the example here that we see on the screen. So let's say one customer is saying that I need to download data in CSP. Another is saying I need to integrate this tool with a specific analytics tool out there. Third would say I need to download data via API. How do you scale? The first step is understand what they actually do to get things done. So for example, if they are saying they need data in CSP, let's take talk about how they would say, oh, today I copy paste data from a table online to a CSP. Okay, why do they need that? Why do they need to actually download data in CSP? They need to upload it to a third party tool. So essentially what they're saying is though they just need data in CSP, the actual pain point or the problem that you may want to solve is uploading data in a third party tool, which is essentially integration with any third party tool. Categorizing the feedback. After finding most crucial feedback, now comes to categorizing the feedback. You've already seen how you can actually get the most useful and inside put feedback from the last slide. And then the different categories that you can identify are usability issues. Issues mostly due to experience could be any experience. APIs, UI, CLI, et cetera. For example, oh, this is not a detailed error message. Obviously, now you know, a very specific problem is that the error message that you are giving to your customer when the error occurs is not clear to them and how they can solve it. Secondly, new feature request. Something that is completely new. In the last example, integration with third party analytics tool was one such example of a new feature request, bugs. I'm not taking into consideration P0 and P1 bugs because they should be solved on priority anyway. I'm talking about the bugs that don't affect customer workflows or do not break the experience but still cause bad customer experience. User education issue. Identifying if it is something that can be resolved by product experience improvement or how product handles the feature or is there a gap in documentation and support guidance. Example, let's say that a customer wants to change the password and they cannot find option on the UI. Do you feel like it's an education issue or do you feel it can be actually resolved in experience changes in UI? Ideally, changing a password is very common scenario where they would not need a lot of documentation steps, et cetera. So if we can make it very visible on the UI itself, they won't have to go and chase support for that issue. Lastly, others. There will be some feedback that's hard to categorize. So you can go back and recat categorize it later as patterns emerge in the rest of the data. Now that we've categorized and we've understood the most important actionable feedback, it's time to prioritize the feedback. It is difficult to quantify every feedback that you get from the customers. So you can use a easier version of Rice Framework to prioritize the feedback and request. First of all, reach. What exactly reach? How many customers would are asking for this customer, sorry, feedback? Or how many customers are actually affected if it's a bug? Impact. So what exactly, how can you say that impact is higher? So if it is giving higher revenue or if it is adhering to customers that have a lot of revenue impact on your product? Cost of work, obviously. What is the cost of works in maybe dev weeks or dev months based on engineering feedback? Alignment with business goals. This is also important to understand that some of the things that you get from the feedback may not align with business goals or the vision of your product. So you may also want to see how it aligns with the business goal. So for each of these, you assign high, medium, and low. You can start with requests that are high in reach, impact and alignment with business goals and low in cost of work. Sometimes you would also have to look at top customer requests. Even they have higher costs. So for example, though they might not have like a higher reach because only a set of customers are impacted. They would, they might have a higher impact because large customers may have higher revenue but the cost of work may also be higher. So you may also want to adhere to that feedback because those are your top customers. Now let's move on to next step.  Now it comes to creating US wireframes and prototypes. Work with the design team to understand the flow. Start with what, why, and how that we've already seen. Make low-fidelity wireframes to visualize. Even on paper and whiteboard is very, very helpful for your design team to actually see what your vision is about that feature. Designers are definitely the SMEs. So based on what is discussed in first and second steps, they can now go and create designs. This step is crucial to get on early feedback by conducting usability studies from the customers. Next, it's always a good idea to walk through these designs with engineering just to look at the feasibility and call out if something is not feasible. It can be either handled by adjusting the designs or maybe thinking about what are some other feasibility needs. Based on the engineering feasibility, feedback from the customers, you would have the final set of mockups and prototypes ready with your requirements. Next, coming to implementation launch. I'm not covering details on processes, agile, sprints, et cetera. I'm going to focus on high-level process and action items when you launch a new feature or a new proofant. First of all, make a plan of launch. When to launch? Will it be available to all customers? Do you plan to roll out two set of customers first? How will the flighting be done? How are you planning to get feedback in that process? And so on. If it's a multi-print effort, go with the phased approach. Plan to get feedback on regular basis, even for each phase. Once implementation is done, make sure to update any documentation so that customers do not end up creating support tickets. Make announcements. Whatever is set up in your organization, you want to make announcements maybe on the product or website or send emails, et cetera. Also make sure that the support guides are updated so that support can help customers in efficient way. Lastly, record any feedback via different channels that we've already discussed in the past because feedback is a continuous process and you want to collect as much feedback as possible in every step. Now let's move on to what are some of the metrics that you may want to measure to actually measure your success or failure for the product? And this step is very important to enable continuous improvement of the product. First of all, define metrics and how these can be measured. These metrics can be, okay, number of customers using the feature. What is the retention? Is there any revenue impact? Then what is the revenue impact? What was my daily active users, monthly active users and now has it improved? And so on. Secondly, you can record funnel. At what point does the customer drop in your, using your product? It is a good indication on what step would need some improvement in your product. Has the NPS or CSAT changed? Has it improved? Has it not improved? That is a good indication of whether the feature was successful or not as well. Recording, if there is any change in support tickets and incidents, it can be increased or decreased again. That is a good indication of if you're actually solving for improving the CSAT or you're resolving a bug. Lastly, any qualitative feedback through different channels is also very important on an ongoing basis. So what have we covered? Definitely, feedback is a continuous journey. You want to collect feedback at every step to make sure that you are improving your product on an ongoing basis. It is crucial to understand why and how to fully understand the customer pain point. Feedback is the key to improve the product on an ongoing basis. Feedback does not only improve customer satisfaction, but it can also result in increased revenue and competitive advantage. Thank you.


This is Witchspace news for Friday the 21st of October 2022. I'm CMDR Buur. In Elite Dangerous News this week, Frontier announced the launch window for update 14. There's a genuinely shocking twist in the Frontier livestream. We ask if Thargoid advocacy is doomed to failure, a creepy horror movie-style treasure hunt appears in game for Halloween and more. We know you get bored of hearing this but it really does help our channel. If you enjoy our stuff hit like, subscribe and don't forget the pingy bell bit. You can also join our Patreon which directly supports the work we do here. As always you'll find links to everything you need below. If you're in the market for more Halloween themed ship cosmetics then there's multiple opportunities as we kick off the show this week. First up, all manner of Halloween paint jobs, suits, bobble heads and decals are on sale in the Frontier store until the 31st of October with 15-30% off. Frontier are also releasing Halloween paint jobs via their social media channels at random intervals for the next week or so. To be in with a chance of grabbing those just keep your eyes on Facebook, Instagram, the official forums and Twitter. A limited number of content creators, us included, have been given access to five codes that will grant the malevolent ghast exclusive ship paint job pack so keep an eye out for those. Your best bet for grabbing a freebie paint job however is via the Twitch drop system. The content creators on that platform that you can see listed on screen now have all got access to the Noctule Blight paint jobs which you are guaranteed to get just for tuning in and watching their streams. My thanks to Commanders Homborga and Alec Turner for this next gem of a story this week. If you're in the market for some new elite dangerous reading material then the Rodent Report is a new newspaper magazine style journal being published by the Fuel Rats. Whilst only still in its second issue the Rodent Report is already a polished, well constructed and professionally written journal featuring input from multiple writers and covering articles as diverse as the founding of the Fuel Rats pilot rescue organisation, Fuel Rating ship builds, interviews with Fuel Rats and even a recipe for a tasty looking lentil dal. There's even crossword puzzles in universe horoscopes and classified ads adorning the pages. Currently the magazine seems to be published every two weeks and is available to view, download or print in pdf format. To check it out for yourself see the links in the video description below. Cast your mind back one week and you'll likely remember that in this very broadcast I was reporting the confirmation of the discovery of a fifth incoming Stargoid. What a difference a week can make. Since then not only was Stargoid number six discovered but as we were putting the show together today a seventh Stargoid was identified and is now being tracked by commanders and the canon unidentified interstellar anomaly tracking site a screenshot of which you can see on screen now and it presents a fairly stark image that point where all the lines meet that would be Sol. Arriving as they do in the wake of salvation's shenanigans in HIP 22460 it's a widely accepted but not yet proven wisdom that the Stargoids are Stargoid in origin. The community goals this week that kicked off on Thursday concern themselves with the establishment of a proposed Xeno peace envoy vessel for use by the Stargoid Advocacy Project an organisation that is currently pushing for more communication with our terror triphid neighbours and less well attempts to bring about their extinction. The prospect of communication with the hilariously murdery spacefaring sour salad has long been a requested feature in certain quarters of the player base and of late the idea has become a running theme in the game's narrative. So is communication and a peaceful common ground after so much bad blood and i-core actually possible? The jury is very much out on that subject at the moment but in the text for this week's community goal pro Stargoid Advocacy Liberal-Minded Candidate and Federal Governor Dalton Chase invokes a quote from the UK Prime Minister Neville Chamberlain in 1938 waving the Munich Agreement in the air and claiming quote peace in our time unquote. Less than a year later following the Munich Agreement Europe was plunged into the Second World War. I'll let you draw your own conclusions from that particular piece of signposting if indeed that's what it is. The regular Discovery scanner post from Frontier that is released at the start of the week every week and sets up the player base for the week ahead contained a particularly juicy morsel this week. Update 14 to Elite Dangerous Odyssey which is the final announced update to the game this year is planned to arrive at the end of November. The update was announced way back in May this year and its headline feature has always been billed as quote the next major narrative phase unquote. Whilst back in May we had no idea what that narrative phase could possibly be referring to these days we are slightly more enlightened and as we reported earlier in this broadcast we are now staring down the throats of seven incoming Stargoid interlopers whatever they are so we think it's a fairly safe bet that the new narrative phase will be heralded and indeed concern itself at least in part with the expected arrival of the mysterious swirly green whatever they are. As we reported earlier in the week Frontier had announced that they had a big couple of weeks of cosmetic giveaways and events planned for the game in celebration of the Halloween spooky season. The events and giveaways were all to be kicked off by a special Halloween themed edition of the fortnightly Frameshift live livestream on Thursday night. As well as all the cosmetics giveaways and themed livestream Frontier had also made it clear that there would be a spooky themed in game treasure hunt event for commanders to participate in that would also reward cosmetics. What we didn't realise until we watched the stream last night was that the treasure hunt and the live stream were actually linked and that the live stream would kick off the treasure hunt in such spooktacular fashion. If you missed the live stream I've linked to a youtube archive of it below and if you don't want the surprise spoiled then I'd recommend going to watch that first before carrying on here. With the spoiler warning out of the way if you're still with us here's how it went down. Hosted by Bruce and Sally with producer Adam working behind the camera the live stream featured the regular gal net news round up and stellar screenshot sections as well as extensive details on how to obtain the twitch drop free paint jobs and cosmetics if you are watching live on twitch. In addition to those regular expected features the live stream also featured games such as Pictionary played with the watching audience and further cosmetic giveaways. The real surprise in the live stream however was what at first at least appeared to be a production error. Early in the stream the video feed of the hosts Sally and Bruce was suddenly replaced by in game footage of a ship landing at an odyssey settlement. Sally and Bruce made no mention of it and their face quickly returned as they continued talking. Later in the stream their images were again replaced by footage this time of a nefarious looking character in reaver style armor walking slowly up to the settlement and taking a prolonged look at the settlement name. Again the hosts made no mention of the interruption in video and continued talking as if nothing untoward had happened. It was at this point that we figured something else was going on and immediately headed in game towards the settlement shown, Henry's peace in the Ra system. Later the video was interrupted again showing the same dubious character heading toward the bar area and this prompted extensive searches of the habitat and bar area of the settlement with nothing unusual being detected. It was as the stream progressed however that proceedings took a more sinister turn. It's become the norm on fdev's live streams of late for the hosts to be green screened into a setting in the game somewhere. Some weeks they'll be on a fleet carrier, another week they'll appear to be sitting in vista genomics etc. This week they were sitting in the bar area of an odyssey surface settlement and during one section of the stream the character that had been seen approaching the settlement in game in oddly placed seemingly unconnected shots suddenly walked into frame behind the two fdev hosts, paused for a moment and then ominously pointed at them before slowly walking out of shot again. It was then that it dawned on us here at the burpit that they weren't green screened into just any random bar somewhere in the game they were sitting in the bar at Henry's peace in the Ra system. But the stream had one more surprise before it went off air. As Sally and Bruce were wrapping up the stream and saying their goodbyes the armoured character again walked into shot behind them this time much closer and this is what happened next. And just like that the stream ended. Immediately afterwards galnet news sparked up in game with a story about three talk show hosts being murdered and a clue being found at the scene and that galnet piece starts commanders off on the promised halloween treasure hunt. I won't spoil what happens with the treasure hunt suffice to say it's typically dark and somewhat sinister as is a lot of elites lore and completing the treasure hunt will indeed reward some exclusive cosmetic items. All in all a very enjoyable stream and in game event definitely one for the history books hugely imaginative and brilliantly executed on stream by the team with a fantastic tie into the game itself as an extra spooky special payoff. Have you followed up on the clues on galnet? Are you a believer in thargoid advocacy? And do you believe the stargoids will stop at lucky seven? Let us know in the comments below. That's it for now thanks very much for watching we'll be back later this week with more videos until then 07 commanders follow the greens on the way out and do keep clear of the toast rack we very much look forward to seeing you next time


Thank you. Yeah, Je Compris. You told a lot of what I was supposed to say. Je Compris has started in 2000. It's used in many, many places, many schools, even in a place where I didn't even imagine it could be used. Like in hospitals to do some reeducations or stuff like this. So you can use it in many, many places. It was originally written in GTK. It started to build quick in January 2004. And it's still in progress. We'll see how we are progressing on that. I see something special about Je Compris. That there is also a commercial effort behind the project. We'll see a little bit how it works, why we do this. But originally the idea was to give an advantage to the new Linux version. Because if you do the same software and you provide it for free, as in beer, on Linux and on Windows, then in schools how do you push the teachers or the administrations to make the effort to use Linux if they can get everything at the same level on Windows. So the idea was to say if you want to stay on Windows because it's easier for you, it's okay. But for me it's more complex to maintain and package the software for Windows. So you will have to pay for it. And it's working a little bit. It helps to find the development, it motivates the development. And also it increases the audience because in some places just being sold it opens a new door to your software. That's strange but some people or some places they like to pay software. And if you don't sell the software they don't use it. That's strange. So the software started in 2000 so it's getting a little bit old. It started in GTK. And the idea was to bring the software to new devices that people are using like especially tablets. So last year we decided to rewrite everything and to do it in QML. We reused only the graphics, the data set, all the activities, the logic of the activities, the algorithm. But of course we don't reuse any code which was in C and Python and now we are in C++ and QML and JavaScript. So there is really nothing common. It's a major effort and we took a lot of requirements in the loop like saying it can run in landscape or portrait mode which is quite unusual for games on tablets. It makes things a little bit more complex to develop but we wanted to make it well, take the time to do it well and it's easier to say okay all the screens will be this size but doing this is more complex but in the long run we expect it to be a very good feature. The completion chain is in CMake. So it's easy to develop it like a regular, cute application. The architecture of the software, we have a C++ core which is in SRC core. All the QML activities have a specific folder. They are zipped in RCC files which is loaded at runtime by the core. So the design of the software is quite modular and quite easy to extend because we only distribute, if you look at the bundle, once you create a bundle you will have a binary, the executable, one RCC per activity and one RCC per translation. And GCompre will run all of this at runtime. So it's very clean at the distribution level. To create a new activity, if you want to collaborate on this, there is a little script, you run it, you run CMake, you start GCompre and you will have just your activity which is displayed and you can just start and all you have to do is to change some QML files and they did some QML files so you have to do QML and JavaScript if you need more code than the QML can support. That's very easy to create an activity. In our porting, I found out that a typical activity in QML plus JavaScript takes half the size in line of code than what we did in Python in the old version. And we have more features, more fancy graphics, animations and so on. So the code is really clean, smaller, easier to maintain. So it's a big success. The technology is very good. Statues, we ported 100 activities on the 140 of the GTK version. We got 60 contributors. Currently we have two students working on GCompre, part of KDE server of code. We did a rework of the graphics. Some of you maybe have helped us get some funds and to pay Timote working on the redesign of GCompre to make something more logic in terms of graphics. It's a great success also that we've been able to get some funds to have Timote working more than a month on GCompre to reduce the graphism. That's very good. Android release in January 2005, so it's really new. So we add in-house content to make an Android version. So that was the first release of GCompre in the wild. We'll see how it works in terms of distribution. 16 languages for the last version at 200% thanks to KDE translation team. We have reused all the content of the old version to avoid duplicating efforts when it was possible. Multi-platform. So what we found doing GCompre and doing the sport, Qt is very well in doing multi-platform. We have very few specific code just to handle the distribution, the packaging where we have to find where are located the RCC files. That's almost all the if-death we have in our code. So Qt is really holding its... It's doing what it says it does in doing an excellent job in doing multi-platform environment. App purchase. There are some specific stuff to do too. But here we are going deeper in the integration of the different mobile platform. And it requires still some work in terms of packaging. It's a lot of work. Even if Qt is very good to do software, it really fast get GCompre to run on iOS. But then when you want to bundle it, to package it, to go to be able to upload it on the store, it's where the most of work is still ahead. So of course we want to have GCompre to run on as many platforms as it could as people are using. It's quite hard to do because if you don't have the hardware, you are out of luck. Maybe some contributors will package it. But if you really want to keep the effort going and to be like professional, you need to be able to provide the new binary as soon as there is a new release. So it's hard to just count on the community of someone as the hardware at time. But six months later, perhaps the hardware is broken and you have nobody to make the package anymore. And you left all the users of this platform in the dark and they cannot use the software anymore. So it's quite complex. You really want to go professional. You need to have the hardware at some point if you want to support a platform. So if you look at Apple, it's quite expensive to buy all the gadgets you need to develop and test on an Apple platform. So you need to learn and integrate the tool chain. On Apple, you need to use Xcode. Even if Q did a lot to integrate and to avoid using the specific tools of each platform, at some point you have to use them. And they cannot do all everything for you. It does a lot, but not everything. And then there are a lot of work to maintain your product in the app store. So it's more like a marketing, but while doing everything. So we are doing the marketing, the communities. So it's a lot of work to create product entries in the stores to maintain them, to have the product being accepted. You have to follow up the remarks of the customers or users of the application. They say, this is not working, I want this, I want this. So you have to make some community around your product to make sure it's available, it's working, and it takes time to do this. And it's hard to find why G-Complete is not number one. I don't know why on the Android store, because it's where we have it for now. I don't know why it's not number one. They are before G-Complete on the store. They are applications that are for sure not as good as G-Complete. Even if we are not perfect, but they are product. They say, why they are before us? I test the application and say, it's just crazy. We should be better, but why are they before us? I don't know. So I found out at some time that, for example, I used in the title of the application, I used G-Complete educational software. But as a title of an application on the Android store, I found out it's the main reference, the main index for the store. So G-Complete is not something that people are looking for. If they are looking for it, it's in the description and the product will come. But if they are looking for children or educational, or if you don't have it in the title of your application, you will not be proposed. So I removed G-Complete from the title of the application. So the application is educational software or educational for children or I don't know, something like everybody uses because you cannot use just names that people don't know. It becomes complex. All part of the development. Qt is perfect, but there are bugs. And there are a lot of bugs. And all different on each platform. Of course, a little, even if it's perfect at 99.9%. And this .1% are very, very annoying because it may be a reason not to ship your software or it may be a reason that makes your software crash on some platform. And it's very hard to... You cannot escape this. So for example, on Android, we made some particles which was very fancy. It works well, but on some devices, it crashes. So we removed the particles for everybody because we cannot know which devices makes it crash and why we cannot find it. So for those, we could not find a suitable geocodec because we are using Ockvorbis. That's a native geocodec because it's a free software and that's the best for us. But on Apple, you cannot use Ockvorbis. On EOS, you cannot use Ockvorbis. You have to use AAC. So we had to change the G-Complete to be able to work on AAC or Ockvorbis. So everything is customizable at completion time. So we can use the codec or another. But on Windows, we still don't know what to use except mp3, but mp3, you have to pay realities to distribute an application that includes mp3. And we are not yet ready to pay for this ride. So on Windows, we have no sounds for now. On Mac OS X, packaging acute apes, acute apps is broken. When you try to... You can make a package and distribute it out of the store but when you want to upload it on the store, Apple says your application is not okay because there is a acute library that has an underscore in it. You're locked. On iOS, we have an SVG rendering that is doubly on Retina display. We have a demo downstairs on the G-Complete booth. You can see it. So we did open for this. We did open bugs on acute bug tracker but no solution for this. This also requires a commercial acute version to be able to bundle and distribute an application for iOS. This costs 30 euros per month but recently the DJI said that this version was not selling very well. So this was kind of indie developer and it was not worth for them to continue this product line and they say they will discontinue it and so developers would have to pay 350 euros per month to do this which is for G-Complete not possible to pay. It's too much for G-Complete so I paid the 30 euros so they changed that. They said you have up to last of August they still accept people to join the program at 30 euros per month but you can see it's like it's very complex to get there. We also have contributors who try to go to look at other platforms like Selfish. We looked at the Ubuntu mobile platform. We looked at Jola and on each of these platforms it's even if cute is there even if you can really fast G-Complete running on it if you want to package it and to make a product and to make it clean and to not use the correct version of cute it's always a little bit complex and especially when we don't have the hardware we will have to buy each of these hardware to be able to maintain it. Like I said it's kind of complex to get there. Commercial approach. I started this in 2003 as I said at first on Windows so I sell binaries and proprietary platforms. The demo version is always available with all the contributed activities so what I'm doing is that if people contribute activities to G-Complete they are in the demo version so everybody has them. All the activities that I do myself make them as they require a fee. But it's very easy to get to access to everything on Windows. There is a code which is saying that get access to the full version for Android. The APK is easy to find on G-Complete.net. If you just browse the files you get to the APK. So when I do releases I do an announcement that in the community I give the links so people can who contribute and who participate in the community they get the software for free they can do whatever they want. There is no limitations really. So only people who get it from the stores for Android or from G-Complete.net for Windows or Mac OS 6 they are required to pay. So it's very interesting. How it works, there are 30 downloads per day on G-Complete.net for the Windows version which is still the GTK version. There are about 2 sales per day and 30 school sales in 2004. What I require for schools I sell about something like 50 euros for a school. So schools contact me and they say I want G-Complete for all the schools and I make them a quotation and they pay it. So there is about 100 installations per day so we are 20,000 so far but there are 50 de-installations per day. So 100 is good, 50 is less interesting. What happens is that the Google Store they count an application as being installed if somebody keeps the application more than 2 days. So if you just download an application from the store and you uninstall it it will not be counted as an installation. So it means that people are dis-installing G-Complete. People are keeping it. Some people don't like the application maybe it doesn't work on their platform maybe it is not what they expected. I don't know. The rating is quite good 4.35 so there is a rating on 5. There is about 2 sales per day which is about the same number of sales that what I have on Windows. But on Windows I sell it 9 euros on Android I sell it 6 euros but on Android Google takes 30% and there is a VAT of 30% or 20%. So on 6 euros you get 3 euros.5 which is quite less. Some numbers it's very popular in France I don't know why. Because of the name. Yeah, perhaps because I'm French and I do better marketing in French or French sites or whatever. We do everything in English so it should be as popular in all the countries that is in France but it's not. Maybe there are some cultural effects that I put in the software that makes the software more Frenchy the popularity is growing in other countries it's very popular in Brazil, Spain and Russia many countries this is growing so that's quite good to see the software moving on like this. App store ranking what's doing Google on their store is that they stop the ranking at 500 so if you are less than 500 you don't know what you are you don't know where you are ranking so they are looking at by countries they have stores for each country and you can see where you are so it's a lot of work when we started doing everything again last year we were looking for about two years of work to complete the port I'm not sure we will achieve this at the end of the year perhaps we will have completed the port maybe not but we are getting closer and the project is very dynamic and active and we are really willing to kill the GTK version because the GTK version is still maintained there are new versions of the GTK version on a regular basis when we have very poor so I continue to package it and maintain it so I will have to just kill it and do only the Qt version to be better what we are looking at we had something like this in the GTK version is a teacher console so that the software can be really used in a teacher environment and especially with tablets where the teacher has to be able to let's say we are in a classroom with children and you have tablets and it's hard for the teacher to know if the children are doing the exercise or not and we really have to provide some things so that the teacher can just control a little bit what the children are doing on the tablets we need you that community is very important for us because if we don't have any marketing or marketing team or anything so if you talk about G-Compre in your community, teachers news site about Linux in your country that's very, very important for us to give us some visibility so that people find G-Compre tested, find if it's useful for us for them what's also important is to have the voices we really want G-Compre to work in as many languages as possible there is a lot of effort to support language, even minority languages that are in small groups where they want to keep alive a language G-Compre is a very good tool for them because that's the quality software and they can translate it and they can put the voices on it so we have everything in place to accept the contribution in terms of translation of course but in terms of voices and this week I made a new website a new page to have a summary of all the voices translation in which country now we can know where, what's missing what voices miss is missing in each country if you want a mic I provide for everybody who want to contribute to voices I can send you and I offer the mic like a semi-professional mic so that you can get the mic at home and make the voices when you want and continue to provide updates and if you want a mic I just buy you and I offer the mic how many? currently there is one in England there is one in France for the German voices and there is one in Brazil so, no questions not because it's not my computer no questions I just okay I checked the developer's corner and I saw that you were still making work you will get up do you have a source code or are you still moving to the KDE no, no I didn't talk about it but JCompre is now part of KDE this year it has been accepted in next year so we are no more in KDE review so we are in next year the official repository is KDE so if you go on JCompre.net developers and you search for the the git it will be KDE1 but we are maintaining a mirror on GitHub so that some contributors can just fork the project easily and provide pull requests what part of the KDE is? KDE KDE because mostly people who just make a small contribution GitHub is fine but if we want if this person want to make a regular contribution then they will be integrated by us in the KDE process but for small just one short contribution it's just not very interesting to make this person if she's not interested to participate in the KDE community it's not worth to make the effort but the idea so you will want the first projects you go through the creator being waited against by the festival and everything until you reach an extra year do you just beat about your experience with that? it was present experience nothing bad to say about it I find it natural and straightforward I have no problem with this I got some help every time I needed help I could find somebody to help me moving forward so it was just no problem


How did a lost global civilization once cut solid stone with such ease and precision? Unimaginably large megalithic structures, laser-like cut stones utilized within the baffling, polygonal masonry, not to mention the mystery surrounding the construction of the Great Pyramids. Many mysterious drilled stone cores can be found through Algeza. These enigmatic tool marks can also be found at the incredibly ancient dolmen of Valkonsky in Russia, exposing the capabilities and clear technological prowess that this lost civilization, who we feel were possibly experiencing an ice age had left in order to survive its fallout. Yet I digress. Discovered within Austria, we were initially presented with just these three images, two of the exterior, which, if one looks closely, not only displays the porthole of a hidden chamber hidden upon the side of a solid rock face, but that the surrounding rocks had also been cut and finished to an incredibly high standard somewhere in the very distant past. This indicated to us that this chamber that is not only reminiscent of the hypogem in Malta with the addition of the stone within the circular chamber, which we cannot avoid feeling, could have some form of connection to resonance creation, with erosion indicative of a site with an age similar to Cappadocia's ruins, but later revealed to have been, as we expected, but one chamber, in a maze akin to that of the underground city of Derinkuyu. Hidden within an Austrian book of antiquities, we discover a series of, fortunately mapped, solid stone cut chambers, which litter this enormous chunk of exposed bedrock. Clearly an astonishing prehistoric site, one cut by an incredibly capable, and we feel, clearly technologically advanced civilization. For why would a civilization with simple, primitive tools, such as those made of blunt or brittle stones or soft malleable metals, such as that of copper, go to such extremes in the creation of a maze of hidden chambers, each not only finished to an incredibly precise degree, but to have worked stones into unnatural shapes outside of these chambers, many serving no essential function as far as we can identify. Who created this prehistoric site found within the landscape of Austria? How old are the chambers? What technology or tools were utilized in the creation of such a magnificent ancient ruin, or indeed that of the Valkonsky Dolmen, along with the many similarly drilled cores and their stone blocks found throughout Giza? Do all these pieces of evidence indicate the past existence of a lost civilization, one who possessed advanced stone cutting technology? We find such possibilities highly compelling. Archaeologists have discovered yet another ancient anomaly, which has linked a now lost, but once clearly advanced, global civilization. Pertaining to a wall relief in Peru, belonging to the oldest civilization in the Americas. The wall, although dated to approximately 3,800 years ago, depicts what many now believe is an illustrated narrative of the difficulties they experienced prior to a cataclysm caused by an ancient climate change. One meter high and 2.8 meters long, the wall relief was discovered in the seaside archaeological site of Vichama, 110 kilometers north of Peru's capital, Lima. The Vichama side is part of the recently discovered, yet now lost, Karal civilization, also known as Norte Chico. Dated at over 5,000 years ago, this dating alone makes it the oldest civilization known to have dwelled within the Americas, now claimed as purely coincidental. This civilization flourished around the same time as that of the thriving civilization of Mesopotamia, ancient Egypt, and also Chinese civilizations. The Karal civilization was located in the Supe Valley, along the north-central coast of Peru. Made of adobe, a clay-like material, the wall seemingly documents climate change, one which could not have been contributed to by human activities. Archaeologist Ruth Chandy, who oversaw the excavations at the site, hypothesized that the serpents within represented a water deity that irrigated the earth and made seeds grow. She believes the relief was likely done towards the end of a drought and famine, that the Karal civilization, among others we have covered in the past, once experienced with other reliefs displaying emaciated humans. Many self-funded archaeologists now believe, like we have postulated, that the discovery reinforces the notion that these early humans were depicting the difficulties they faced due to climate change and a depletion in available water for irrigation, which had a large impact on their agricultural production. The excavation has to date unearthed the ruins of 22 buildings in a 25 square hectare space. It would appear that just like that of the site of Tikal, and the now lost plaque, which once depicted the dramatic scene of a cataclysm, a great flood, along with erupting volcanoes, with a boat seemingly attempting to escape this event, surrounded by many of the population drowning, a cooperating artifact fortunately photographed before its mysterious disappearance. Was there indeed a great flood? One which seemingly followed a great famine. It would seem the evidence for such an event is mounting, thanks to not only the evidential sediments which once drenched many of the still unexplained ancient sites of the world, but also by its depiction by those who lived through it. It is, indeed, a highly compelling mystery. The awe-inspiring ancient city of Hegra, also known as Mada'in Saleh, close sister of the equally astonishing and cinematically famous ancient site of Petra, is now finally open to the public, able to go and investigate for themselves. We have covered this site, and indeed the gigantic scale of the rock-cut temples that claim tombs and tall doorways to enter these sites. Furthermore, we have covered uncanny similarities found upon rare, unfinished areas of these once astonishingly precisely cut solid rock ruins. In addition to the enormous scale of the stone-cut buildings, and the absence of doorsteps which would have enabled the now average-sized human claimed as having created them, no chance of entering them with ease. This giving credence to the many theories pertaining to these gigantic structures, along with their gigantic scales and their enormous megalithic counterparts found at other sites, linked to, by cutting marks previously mentioned, were instead constructed by an ancient, now lost race, far larger than any of today, one capable of these incredible ancient feats. Could these structures have instead of, as so many as indeed we have postulated, not actually built by ancient man, but were actually made by ancient giants? Not only with the muscular ability to have once lifted such enormous stones into position, such as that of the enormous megalithic stones incorporated into the great pyramids of Giza, found within the temples of Baalbeck, Garnia Shoria, but also almost globally? Could this explain how they were once able to liberate these giant stones from the quarries and bedrocks, selected almost many miles from where they were eventually placed with seeming ease? How they were somehow transported, enormous stones high atop mountains, assembling them into the remarkably precise-laid polygonal masonry that now drenches the tops of Peruvian peats? How they once raised the ancient obelisk of Aswan? But I digress. Many have now conceded that the methodology of the great pyramids of Giza construction continues to be an enigma in regards to a modern explanation as to how the modern man accomplished such feats. Could this mystery be linked to the cover-up in which many have claimed and we ourselves encountered in regard to the remains of this possibly lost civilization, smothered by the Smithsonian, one that we would now perceive as ancient giants? It is a hypothesis which would indeed be a fitting explanation for these mysteries and a cover-up, the stifling of a reason for their continued inexplicability to modern explanation. It is a theory which we find incredibly intriguing. Frolic Gladstone Rainey was an American anthropologist, a master of narrative prose. He was the type of ancient specialist anyone in the field would have relished working with. Regarding the Arctic, he put it to the National History Museum as follows, quote, We have now found an Arctic metropolis, many times larger than anything previously thought possible in this part of the world, and once inhabited by a people whose material culture differed markedly from that of the Eskimos as we know them. He continues, One morning in the June of 1940, when Magnus Markey and I had returned to begin the second season of digging at Iputac, we soon became aware of the astonishing extent of these ruins. We could see long avenues of yellow squares marking the ancient buildings spanning east and west for well over a mile. Over the next several days, we hurriedly attempted to chart these ruins before they all became hidden once more. We eventually realized that more than 600 buildings would have once stood on this ancient site, a site well over a mile in length, end quote. Dated at many thousands of years old, you have to wonder, why is not more publicity shared regarding these mysterious people? One of the most striking facts regarding their artifacts was the high standard of craftsmanship. Sophisticated objects have been on earth, which demonstrate a far more complex civilization than the proto-Eskimo culture academia would have you believe inhabited the area. The architectural abilities of this mysterious group also far exceeds the capabilities of other ancient cultures, even as far as Mexico. The largest ancient settlement ever found who have existed in Alaska, it was even bigger than any Arctic coastal village in Alaska or Canada today. The town of Iputac would have once been home to more than 8,000 people. Just who were the Iputac people? How did they survive so successfully within an Arctic climate many thousands of years ago? Are we looking at a culture far older than we are told? Regardless, one reason to conceal such a fact would be the Bering Strait Hypothesis, a hypothesis conveniently crucial to evolution theory and one which numerous people have lost their careers over. Dr. Scott Elias at the Colorado Institute of Arctic and Alpine Research, as far as Orthodox scholarship is concerned, the validity of the Bering Land Bridge route is not up for debate. Regardless of such cult rhetoric, the Iputac people are certainly an interesting and controversial bunch and worthy of future study. We will keep you posted.