Okay, good morning everyone. It's very good to be here. It's my first time in India. It really makes me happy to see so many people who care about JavaScript. If you look at the first JavaScript conference, it had a really short schedule. It was Brenda and I. What is JavaScript anyway? Launched in a quick wrap-up. So, back in progress, right? I think that's a really, really good thing. I'm from Sweden. So basically, where I travel, it's going to be nicer and warmer. If you can't hear me, I'm really funny. So I do run the Mozilla Hacks blog. The point with the Mozilla Hacks blog is that it's our developer-basic blog at Mozilla. We want to make sure that people can learn things about the open web. It's not only about Mozilla technologies or things that we do. It's for everyone who's part of the developer. We're trying to cover, now, JS, mobile performance, et cetera, et cetera, as much as we can. Also, tweets, usually actually see good things nowadays, I would say. I'm partial about Facebook live in the open web and Firefox web. When I go to a conference, I can usually talk about technologies and details and such. Then after the talk, a lot of people come up to you asking about Mozilla in itself. What Mozilla actually is and how do you make money and all of that. So basically, Mozilla is a non-profit. And the reason for Mozilla for existing is to keep the web open. We don't want just one player to own it all. We don't want one company to have control over the technology or how you do things. We want everyone to be a part of it and everyone to be able to take a part of it. And that's what we do on the money part. We make money through different donations and partnerships with search providers and such, over the time, in stockholders and something like that. So basically, we do the things that we believe are good for the web, not to make money or not to have a creative report. Do you look back a few years ago, it was only an explorer, and then Firefox came out to try and make things better. And I think the web browser climate right now is excellent because we have such good competition right now. And especially if you look at JavaScript, the JavaScript performance over just the last few years has improved so, so much. And I'm really happy about that. And some people think that, oh, for instance, with Google Chrome, that Google Chrome is getting a lot of user, that must be really bad for you. Like, no, this is perfect. We want to have diversity. We don't want to have 100% of the remarks with Firefox. That wouldn't be a good thing either. We want to make sure that it's balanced. So right now, we're in a really good place. Integrity on the web, their data. It's a problem with people sharing. It's just about knowing that the things that you share aren't going to be available to a lot of people. So, you know, just keep that in mind. We also try to stay up on what's happening on the web right now for how to make sure that we actually adapt to the things that people need right now to be slightly more serious as well. I think we have bias because I live in Western Europe. But if you look in North America and Europe in particular, that people have too much money and people are all for tube support. With the New York Times, people having subscriptions for New York Times. The average number of devices that are used to access the New York Times are six. People have six different devices to access it. That's not, it's fun, right? But it's beyond reason. And I think it's about the mindset where we are right now. Like, you know, you buy things you don't need with money. We don't have it because people don't like it. And I think that's a good summary. Where we're trying to go there is in order to make sure that everyone can take part of the web and also contribute to the web. And we'll tie it to what I'll be talking about Firefox OS. We bring up Firefox OS. It started a few years ago. And if you look in the mobile sector, with Apple and with Google, that they have over mobile. And we will look at Firefox. We offer Firefox and it's something completely open to use to some different platforms. And basically, more or less, we can't. We can't offer Firefox on iOS because we're not allowed to. We can't offer it in Android, which we do like. We can't offer it on Windows Chrome. So we're looking into different options. How can we make this better? And we came to the conclusion that we need to build a mobile operating system based on our technology. So it's only Asian, Thai, CSF, and JavaScript. And it's also made me sure that people wonder about Firefox OS phones, like, okay, you can pair a Firefox OS phone to an iPhone or Nexus 4 or something like that. And the way it is right now is not the same thing. That's not our initial target. We want to make sure that it's more about making it affordable in as many parts as possible of the world, so we're looking at South America or looking to Eastern Europe. And over time, I definitely hope we're going to come here and have something available in India and Africa and so on. And I think it's also about a lot of people that are going to come online the next few years. Like, there's an evaluation that's two million more people that are going to come online in the next few years. That's two million. That's a lot of people. And most of them are going to do it through mobile. And if you look at Africa, there's more people that actually have mobile phones than have access to electricity. So they have a charging pole for a charger phone than anything. So how can we offer a smartphone experience for them? You know, they might not even have one today or they might have a feature phone, like this old Nokia where one button is bigger than the actual display. You can rub your face to see what you're actually typing. It's a lot that you have two lines. So how can we get the most smartphone experience for more or less the same price? So that's where we're aiming, initially, with Firefox West. In emerging markets, you bring smartphones to them with open technologies. Over time, I think it's going to change as well. I think we're going to see Firefox West on a number of different devices. I think, you know, the next year or something like that, you're going to see different hardware partners that we have, like LG and so on and so forth, having more expensive phones. So I think we're going to have a wider range of devices as well. But initially, we're going to make sure that everyone can be a part of it, instead of just trying to compete with existing ecosystems. Months ago, in the beginning of July, the first part also was released, which was really a special moment for me because I've been around since it started a couple of years ago. And it's something unique to actually go into a store and see the device in people's hands and actually start using it. And they were selling for 69 euros, with 10 Firefox phones for one iPhone or something like that. So I think we're aiming in the right direction. If you look at other countries like Poland, it's even cheaper with a subscription. Talking about different hardware partners, we have a few, like with LG, Sony, VT, Alcatel and such. And one partnership that was announced a couple of months ago was with Foxconn. And Foxconn is a company that built the first iPad, for instance. And they were talking about bringing Firefox OS to a wider range of devices. So we're not only talking about mobile phones anymore, we're talking about potentially tablets. We're talking about having Firefox OS on TVs and such. And that's what I think makes it interesting. You can imagine just building something that you already know, the use of technologies, where you can ship it to any kind of device, any kind of resolution. And that's really promising, I think. And we'll see what you're going to release and update on what they want to invest in when they want to release first. I think for me, it's about the potential like where can we go, how far can we take this? And talking about the history, I wrote a short, actually long blog post on how we sort of all went down. How Firefox OS started, what happened during the last two years. If you're interested in seeing how it actually came about, that would be a fairly good read. With mobile phones, people want to have apps. That's already been established. For me, I'm more of a URL kind of person. I went out with a browser, tested the URL, and I'm done. I do everything on the web. But people want to have apps. So we're looking into how can we still use open technology like HTML5, but package it as apps. So we started working with something called Open Web Apps. And the idea with Open Web Apps is basically just reusing what you already know, what you already can. You don't have to learn a new programming language. You don't have to use a specific IDE or something like that. If you built for the web Firefox OS, it's just another platform that it would just work on. You might not trust me like I'm just trying to sell you something here. But I think the point here is basically we need to use what we can. We don't need to reinvent the wheel over and over and over again. I think we need to get away from things like this, like with QR codes. Or like a two-page instruction how to use it or you can type in a URL. And I think we want to get back to that kind of simplicity. We want to get back to making the web more powerful. So building Open Web Apps, it's quite easy. It's just once in design. Your, for instance, will work out a box on Firefox OS. Then, and it will be optional, if you want to package it as an app and have the app experience, you can add a manifest file. And a manifest file is basically just a JSON file described in your app. So it outlines different icons for different solutions and such. Who built it. And you can also have different localizations if you support more than one language. And that's it. Then you're good to go. Now you've created an app. So it's really, really easy to get going. You have two different ways of building apps. We have packaged apps and hosted apps. And hosted apps means that you can have it in your own website. You can have this file and be installable, but you will still run the content from your own website. So you will control all the updates, the content, et cetera, and then no one else will, you know, tell you when to do it or when you can release it. It's all up to you. And then if you want to make sure that you have offline support, you can use, for instance, AppCache in HTML file to make sure that it works offline as well. With packaged apps, it means that you can have all the files in your app and just zip them up in one file. Then you install that zip file on the device, which means you install all the files directly on the phone and then they will run locally there. The difference when it comes to security with packaged apps versus hosted apps is that with packaged apps you can have it in the Firefox marketplace and reading the code and you can make sure that it's secure and then you'll be able to access more hard work and more APIs on the device. So that might be one option depending on what you need to do on the device and what kind of needs you have for your app. Back in 2007, when the first iPhone came out and they said, well, whatever things get made of web, just build a web app so it's gonna work. And then about one year later they kind of gave up on that and they went with Objective-C and the App Store and all that. Just documents for people building for iPhones back then. They couldn't access contacts, they couldn't access anything on the device and we just ran great pages. And I think the path they could have taken instead which is the path we're trying to take now is to offer more access to the hardware to offer more access to the phone. So we started a project called Web API starting to build up all of these APIs to make sure that you do more things directly on the web no other dependencies on the actual device. And it's also making sure that, you know, run everywhere that's not really true with Java still make sure that you don't have to adapt for any kind of platform or device but just write it once access API and it's gonna work we're gonna take care of it and if you look at other players in the IT sector they come up with new ideas one thing that's really important for us is standardization. So with the APIs which we don't want to build something just for ourselves we want to make sure that as many as possible support the APIs we want to make sure that other web browsers other platforms also support the same things so you can build something and it will work everywhere. And a few of the APIs have already been standardized and a lot of the other ones are in the works. If you look at the security you have a few different levels one level was it's just normal web content something you render within a hosted app so if it's being run from your own web server it's still on the same security so you can access more APIs you can access contacts for instance or doing cross domain XML and we also have a page on the wiki about the web APIs as you can see in the column with all the colors there it shows which API it is so ID means that it's supporting a Firefox desktop A means that it's supporting Firefox on Android and B in the right hand which is the old code name for the Gecko which was a Firefox a couple of years ago if it's supporting Firefox OS so then you can see with the API it's supported across all the platforms with blue for instance it means that it's certified so right now we can access that for security reasons so it gives you a good indication what you can use across the board of the only work on one or maybe two platforms and talking about building web apps in your manifest file you can also have a permissions part and in the permissions part you list what kind of certain APIs you want to access so if you want to access the contacts you just say ok my app is going to access the contacts this is what I'm going to use it for and you also specify what kind of access you want like is it read-grade is it read-only so the user knows and same thing with alarms and we also have on MDN you can see what kind of permission you need to specify and how you specify so it outlines all kinds of access so the regular APIs you can access from your web page and there's a good number of evidence with the ones with W3C are the ones that already been standardized so I'm just going to go through a few of them to give you a feel of what it looks like to code it and we're also trying to make sure that when you access the APIs it's as easy as possible to write the code try to have any super complicated names and with five people in the board I actually understand so it should be as intuitive as possible to work with it with the API you can access the battery on the device you have a few properties you can check the level of the device how much power it actually has right now you can check whether it's charging or not you can also check the charging time which means how long time it's going to take until my phone is fully charged it doesn't only work with phones it works on laptops as well and you also have discharging time like how long time it's going to take until it went to the text was happening so basically we had a charging change so you can see if someone is actually connecting the device to an AC adapter or if they're unplugging the device and the basic part here of sports is that sure you can build a dashboard showing how much better it is left but also be depending on what you're doing with your app how much power deception you want to use like if you can see that the user has a low battery level like a server or something like that they're not used to most performance things in our day and we're simpler then we have a screen orientation API screen orientation it's more about trying to make the user experience better for the user so you can lock the orientation you can lock the orientation to portrait for instance if you want for landscape but you also have a few other options you can for instance say landscape primary which means that no matter how we're holding the phone right now when you start the app it's going to go into landscape and if you start moving it around it's going to adapt to how we're actually holding we have the vibration API which is about vibrating the phone but people have the wrong connections as you can see so we moved on from that it was kind of hard to explain so we have the vibrate method which accepts a number of milliseconds so the one at the top here means that the phone is going to vibrate for one second the second one is a bit more interesting because you pass it in an array and that's going to be a pattern which basically means that the first value is going to vibrate for 200 milliseconds and that's going to be silent for 100 milliseconds and that's going to vibrate for 200 etc so you can have all kinds of different worst code experience or whatever on the phone and some people are building really interesting apps like that that you can have your phone in your pocket and you have navigation you're writing your bike or something like that I mean you get an intersection with your phones if you're supposed to turn left or vibrate twice and one that I think is really interesting especially as a job being along for a long time we had HTML code and then we had HR elements etc and then finally we did image roll over it was amazing and now I think what we have is really interesting is so we can connect our code to the physical world so with the device proximity API I can have a device and I can detect how close it is to something else if I move it around it's going to tell me how close or how far away it is and the way you do that is basically you have a device proximity event which uses the metric system and the good thing is you get back the value at 70 meters but you also have a couple of other properties you have the max property and the min property and the max property basically just means the sensor in my specific phone how far can you detect it's going to be 10 centimeters it's going to be a meter and the minimum means how close can I get before you start actually carrying how close I am giving the actual value of your device so in my mind what I found about this API I thought it would be amazing and you could move around everywhere it doesn't support that far distance right now so it only supports 0 up to 10 centimeters and I think over time we're going to support much bigger business as well we also have the ambient light API and with ambient light it's about detecting the light conditions where you are right now so if I had my phone out in the bright sunlight it's going to give me a really high value and what you can do with this is that you can have moon themes in your app in the left theme depending on if you're in the living room or if you're out walking in the street one, you can just change to see a desperate signal like if you're in bright sunlight there might be another contrast that you can use as code to make sure it's more visible so you have a device light event and the device light event returns the value a lux value and a lux value ranges from up to about 12,000 and 12,000 is basically rubbing it against the lamp I tested 15 there of course it goes all the way between there but just sort of remember that below 50 it's going to be quite dark and over 10,000 it's really really bright we also have a page visibility API actually I have to have snow with my slides have you heard about snow? it's amazing there's quite stuff that you can really use here with the page visibility is that you can detect from within your app if your app has focus so if your app has focus you might want to do something and then you know the user might leave the app do something else and then when it comes back to the app you can do something else again you have a visibility change event and then it's one simple property you have document.hidden so is the document hidden? yeah okay well it's going to be in the background otherwise yeah I have focus you need to do everything you need to now I have a few privileged APIs and at this moment you need to be packaged up as been approved by the Firefox Marketplace to be accessing these APIs Browser, if you want to build your own browser so this is a Mexico artist and to take one example if you look at device storage you have a navigator to get this device storage method where you can get into the videos folder here in the videos folder you can create a cursor so you can just enumerate or roll the files you have within that folder and when you get a result for that cursor you can use the file aid guide you can read out any kind of data about the file like what's the size of the file what's the type of the file and in this case when you check the actual type of the file you get the file type of the file not just the extension you can check whether it's actually a video file and then you can create the test player on the fly in the background so like sure it claims to be a video file but does it actually play and you know if it plays then you know okay this is actually going to work and then you can present the list to the user which files that you know will actually run on device not just all it might be video good luck that is good crossover I would say between the normal APIs that anyone can access and then the privileged APIs and also some of the certified APIs which are only tied to us like accessing the telephone for instance you don't want anyone on the web to be able to make calls on your phone for you and that's something called web activities so for instance if you want to interact with the camera right now in Firefox OS you can use an activity you can use the JavaScript code you call a certain activity like in this case the pick activity and you can filter out what kind of files you want to pick so I want to only pick image files from the device then I get a list on the device with all the apps that support that activity for those kind of files so the wallpaper app and the gallery app and the camera app says like sure I can give you an image and then the user can choose what kind of app it is for instance accessing the camera you can't access the camera but through this way it's a mix of your code and user approval so the user will see a menu and they will take the picture or do the call or something like that and then you can do much much more with your app and the way you call an activity within your code is that you call a most activity object and with most activity you specify the name of the activity you have about 10 or 15 of them and you will pick or something like that and you have data specifying what kind of data you want to send into that activity like if it's filtering on the EEG file for instance and then you have a success event handler and error event handler and with the success event handler you get some kind of data back from the app and if you build an app to support a certain activity let's say you have a computer app or an image sharing app you can also say that for activities I support the share activity but I only support it for PEP and GIP files so if any app calls my app through an activity and calling share I want you to display the sharing.hml file to that user it also means with this position I can choose how is being presented to the user window means leave the current app and go into my app and do something but you can also have this position inline stay in the current context keep on working if I go into my app choose an image and then go back and from within your app you can set the message handler so if any kind of web activity is calling your app you have an activity event handler and within there you can print out some data and then you can use post results or post error back to your requesting app then if we look at the future APIs and I think it's really important to talk about the future the thing about the future is also to talk about what are the things that we could have in the first version what are we going to do in the next version what are we planning, what are we thinking about so a number of the APIs that we're working with are things like having NFC through a web API having access to USB to connect the device to something you can access to USB calendars, balacacca, etc one thing I like here where I think Android is much better than iOS is that you can have any kind of keyboard like on the Android you have switch key and swipe and similar which gives the user a lot more options and I definitely hope we can see more options as well on partners like of course we try to make the keyboard as good as possible but someone might have a different idea and then we can also name the APIs so they can hook in their own keyboard here and another thing that's really interesting is where part is seen like how can we have peer-to-peer communication directly on the web through any other weird protocol and just yesterday we actually shipped WebRTC enabled by default in Firefox and Android as well so I'm really excited about seeing WebRTC coming to mobile but it's not really there in Firefox yet so it's being planned it's going to be there sometime definitely if you get a Firefox device right now there are a few default apps being installed like of course web browser, messaging and calendar so these are the apps that we have pre-installed directly on Firefox devices and then depending on the markets being released there might be a couple of extra apps from that local operator as well and one thing I really like about Firefox OS is that since day one everything has been available online you've been able to see the code on GitHub like every command you can see it's being built up with three different layers so we have GONK which is the small Linux kernel that just basically makes it possible to access the screen and things like that and then if we get on top of that which is a rendering engine in Firefox but then as soon as you boot Firefox OS this will go into a web browser window and in that web browser window you can see something called GAIA and GAIA is the user interface in Firefox OS and everything is HTML5 in there and everything in GAIA is on the web so if you want to figure out how the operating system works how the user interface is being built you can go here to GitHub you can see all the code you can see if you like a certain app like I love doing the contacts app I want to build something like that you can go in there, you can look at the code you can copy the code and also if you have an idea how to make that certain app better you can just do a pull-refer and that's the important thing we're not going to get any feedback we'd rather hear what you have to achieve with it as well and to get started with Firefox OS we have the Firefox OS simulator which is an extension in Firefox you just install the extension and you can run the simulator actually you have developer tools debugging and such and a number of APIs you can try to mock support for them in the simulator as well so it's a good start if you're outside or existing mobile web app you can run it directly in the simulator and you can see how it actually works I also put together something called the Firefox OS spoiler like that and a number of these APIs that I was talking about and also the web activities it's just a small test case and the code is not dependent on any libraries so you can just take any kind of small snippet in here and into your own app so if you want to access the vibration for instance just take that snippet so it's a good way to get started and just see all the different things you can do on the device and we have the Firefox marketplace where you just have your app you don't have to have your app there unless you want to the Firefox marketplace is just one of many options there's more about findability and for users to be able to find apps and for you to be able to have payments and sell apps if you want to but you can also have the app completely in your own website and install it from there and we would also like to see different marketplaces we can have a marketplace that only targets games for instance so we're trying to bring as many options as possible to people that aren't simultaneously like you know our marketplace is the only way and we're the only ones we can approve etc because people often like that and as part of the marketplace we have something called the developer hub and the developer hub is just a collection of information for developers talking about how to design apps and also how to publish them the main point with this presentation today as well is just an introduction and I'm going to be there for a few days so you can catch me or any of the other people and ask whatever you want about all the details and we can dig into it but I think what I want to sell to you today is the idea of trying things out so a number of months ago my daughter had a birthday and she was turning age so we gave them this small leather cookies that we're sitting having cake and a little birthday party and they got this small thing where each cookie is a leather so one can be the cookie and one is the leather just to see they can spell things now it took about 30 seconds and this was the first word I like the unexpected I like when people just hack them things and see what they can do with it if you can break it, that's great you can find something that can be even better so there's nothing wrong with that there's nothing wrong with trying failing as long as you actually want to do something and have the ambition to hack stuff that's what makes it really, really interesting and then if you tear it completely apart that's fine too I have this thing I have to have this in here so just slightly over time what I do want you to do well, during this conference and also in the future as well just go out and have some fun I mean, we don't live for that long just hack away and then do some cool shit that's what I expect from you I would need you to come back from ACM and play with CSS after do you think it's much more supporting that ACM and the answer is better if it comes with battery and endless speed okay so on the topic of phones in India the thing is that we don't sell the phones so we have different hardware providers, different operator partners so it's a bit more about which operators that are willing to partner with us and initially has been telecom in Spain and South America it's been Deutsche Telecom in parts of Europe and also TeleNOR in Europe so we haven't really had any complete partnership yet in India as far as I understand it there's a vast amount of operators and officers and all that so I have no specific date, I could make things up but I would like to and I would love to see it come to India I think India would be a wonderful market for partners but it's not... I'm talking about the one interesting exercise with fireboxers as well like right now I mean the different phones that we might have are more powerful than the desktop computers we had a few years ago and the interesting thing here is that we need to have hardware which are low level specs to be able to offer for a certain price and make it affordable for people so for me I think it's quite interesting to see like you know instead of loading four megabytes of data and every job as you apply for those that are invented you need to start thinking more and more about performance again what things you actually use so they actually answered the question I've been avoiding there are no concrete benchmarks like people are trying to do with benchmarks and then also we have a release schedule so something that was true today might not be true six weeks ahead because we have a new version that thing was fixed or improved or something like that so I think the difference with fireboxers we're going to have more frequent releases that can be once per year it's more like with web browser we're going to keep iterating and make it better and we're also trying to give advice as well but not only for fireboxers with any kind of device that doesn't have the same performance as an iPhone 5 it's not everyone has six hundred dollars to buy one so we're trying to tell people how can you make things work better on mobile should you use your quest animation frame instead of something else for Canvas etc etc and I'd love to give you and I can tweet later as well links to advice that we have and we have a few people working for us that's the building one person building the CraftsJS game engine and he was just listing all the advice that he has to make things perform as well so I don't have any actual benchmarks to give you when I'm looking into that the thing to think about benchmarks as well is that you can do benchmarks to prove your point but it's also really easy to piss a lot of people off and then get into a contest of just talking about which benchmark there's no one single ultimate benchmark that's the truth it's all about the perspectives it's all about statistics and I'll stop talking about I hope that's enough catch me later if you I just want to extend on what he asked before so the thing this is where if you're building games on html5 if you're using virtual performance is pretty much close what you get on native and it's really good but when you're building applications which involve DOM you don't really notice much of a performance issue on your own laptop because your processes are really good but when you're on your phone you start seeing that the UI is never as fluid as you'd expect on native apps so are there any words to improve the performance of the way you render your artings because it's become really fast but the amount of work done into rendering is not so much and secondly another thing between native and web is that most of the native platforms have a standardized set of UI components and that makes everything more consistent is there a plan for that in PyPox as well to implement a set of components so that most apps will look familiar to the users all the performance part JavaScript is really fast no matter what platform you're talking about I agree and the thing with DOM of course we're trying to make it better and perform it over time as well but I think it also comes down to the habits of JavaScript developers if you look at most use cases of JavaScript they keep on accessing DOM all the time like it's not always the most optimal way especially when we advise this like on a desktop you might not even notice when you keep on accessing DOM all the time clearing things and changing all that you shouldn't need to keep in mind when am I willing to be able to prize or just tell Max this like it's worth it I think it's delicate to palace between of course trying to make it better from our side but also pruning practices with it when it comes to UI and guidelines it's a really interesting topic I'd love to talk to people to talk to me later and tell me what you think about it we have two camps there we have one camp thinking that well it's just a web web doesn't have any guidelines it's free and open you can build whatever you want and then you have the other camp for instance iOS had a lot of success for being very consistent like it's a consistent user experience and think that we should have really strict guidelines from our box press so what we're trying to do is find a middle ground thing no matter how it works you can do that but if you have something that looks like the native apps or pre-installed apps native is the support that's going to be but like the pre-installed apps one thing is that you can look in and guide for instance like if you like one of pre-installed apps you can look at that exact course another thing is that we have something called the building blocks and the building blocks are basically so you have HTML snippets and CSS snippets to make sure that it looks like the pre-installed apps we're also looking more and more into web components and we have something called the celebrate which is just making more modular components for building well app headers and content and things like that we're trying different options so it's not just to have to use this library we have to use this guideline it's more about if you have a smorgasbord options but you know you pick what works for you and of course it's Firefox one it's here right now so we're also trying to figure out what works best what gives the best results for app developers we have one last question and then you can work Robert for that thanks for the talk my question is to do with open web so in this context of surveillance and stuff I know Mozilla is going to be open web that's for sure but then in terms of communication technology what is Firefox OS promise to mobile users people are paranoid using even android or you can't trust all the androids or all of android so that way in that context is there something Firefox OS users can expect in terms of privacy and stuff we have something called Mozilla persona but just to make sure if you look at the web if you look at the technology any website you go to you can comment with our Facebook blogging or you can test an app or something like that but to do that log in they can access all of your data if I want to write a comment they want to know when I was born and where I grew up relevant I would say so with persona for instance we're trying to in general with persona trying to build out the identity system for you where the data is encrypted no one else actually access it and you're completely in control but initially with Firefox OS it's more about right now getting an open platform out in the market and making available for people and also about where we can go forward it's the only days for that we do want to do that we do want to help the technology in any way we can but it's only right now awesome everybody give it up for Robert


Hello, everybody. My name is Mrdula. I am a senior product leader at Amazon currently and I am extremely happy to be here today to talk to you about product management. Obviously, I chose this as my profession and my career, so I'm extremely passionate about it, but I'm also super excited to be talking to the product school community. This community really helped me when I was an engineer and trying to break into product management and I was trying to pivot to product management and this is my opportunity to give back to all of you so that we may all grow together. Happy to field any questions after the presentation. You can also reach out to me. My information is provided by product school in the blurb below the video, so happy to field any questions after. But with that, let's get into the topic today. Today I want to talk about PMs and product life cycles. And there are a lot of things that I want to cover. Here is what our itinerary on this journey is going to look like. I'm going to start off with the product life cycle with a focus on the voice of the customer. And almost always we always go back to what is the problem that you're trying to solve and I cannot stress this enough so I actually made an entire slide for it. I'm also going to double click on a few aspects of the product life cycle itself, mainly strategy and product definition. Then we're going to round it off with like the go to market strategy for the product life cycle. And because I've been a PM for a while now, I'm going to round the presentation with a few lessons that I've learned along the way. I really hope that everybody who's listening and who's here today learns from these mistakes and we grow together just like I mentioned earlier. As you might have known you probably read articles around this, you probably heard other people talk about it, but there are so many ways to actually conceptualize a product development life cycle. And there are so many aspects to making a successful product. Almost always it starts with vision and leadership. It's an idea that you have in mind and you want a solution for a particular customer problem that you've seen that others have told you about. Then you go into the product life cycle management where you probably start with the design and then the product roadmap. These are all parts of strategy in some companies, their individual topics and others, but they almost always are part of the product development life cycle. When I talk about design, when I talk about roadmap, they're all in place because almost every company has resource constraints, which means every product has a backlog. And our roadmaps, our planning, our strategizing, our prioritization techniques are a way of making sure we are on the right path to that vision for the product that we've established. Along the way, again, a lot of PMs also do a lot of modeling. They could be prediction models to kind of see if our product is the right fit for the market. They could be business models or financial models to kind of assess the impact and the money that the product is going to bring in for some times. And finally, there will be a lot of project management also and product management where you have to collaborate with a lot of partner teams, stakeholders, and continuously align people towards this goal and this vision that you've established. Having said that, there are some core elements. And you know, all of these core elements involve exploring, I'd like to think, four basic questions. Number one, what is it that you want to build? Number two, how are you going to build it? Number three, who's your customer? Who are you going to sell it to? And obviously a lot of questions about them. And finally, number four, how are you going to make money off of it? So one, what are you going to build? Two, how are you going to build it? Three, who are you going to target for your customers? And four, how are you going to make money off of your product? Along the way, like I mentioned, every part of the product lifecycle, you will need to coordinate your partner activities. This can be research, data science, design, experiments, everything that you can probably do in a silo or with a team, but also other important areas of management like operations, finance, marketing. If you are in a smart vehicle or autonomous vehicle space, then compliance, data privacy, all of those partner activities. You also want to keep in mind data and dates and milestones, because every time you work with multitude of stakeholders, dates, milestones and the why is almost always the way to make sure everybody is aligned towards the same vision and goal. I did mention this in our opening. What is the problem that you're trying to solve? If I had a penny for all the products that didn't actually work. And almost always, and this is my kind of observation, that almost most of these products, what they have in common is that along the way somewhere, they've lost track of the problem that they're trying to solve. But there are a few examples that I want to talk about today that did not lose sight of this. For example, Google or any other search engine started off with a basic tenant. They wanted people, they wanted to give people the ability to search for anything on the internet. That's it. It was as simple as that. Slick deals, which is Thanksgiving is top of mind for me right now. So slick deals is another website that I'm visiting a lot lately, but slick deals had the same simple tenant. They wanted to provide people with the best Thanksgiving deals year round. And as long as you identify that simple customer problem, and as long as you keep that problem center of mind, everything else will follow. Now, a lot of budding PMs come up to me and ask me, how do you figure this out? How do you know it's the right problem? How do you know or pick the one problem that you have to solve for among the multitude? Constant vigilance. Now, I'm a Harry Potter fan. I really like Madi Moody. So that's the term that comes to my mind. But the answer to that is you have to keep your customer in your focus all the time. You have to constantly listen. You have to constantly be aware and you have to constantly research. You have to not just ask customers what their pain points are, but you have to observe and you have to think for yourself. Unarticulated customer needs is friction and friction is opportunity. With that, we move into strategy. So now we have an idea of what the product lifecycle looks like, then we know the problem that we're going to solve. Next, where do we go from here? We strategize on how to solve this particular problem that we've identified for a customer. Now, strategy is always long term. Strategy is always forward looking. It's always big picture. You have to always think of where the product's going to be 1, 3, 5, 7, 10 years from now, depending on the lead time and the environment and the industry you're in. But strategy is always about audacious goal setting. And it's also about moving forward. Oftentimes, as soon as you think of a product and oftentimes as soon as you obtain buy-in from your customers, you start developing. You start engineering things and then you lose track of the big vision. Strategy is a way of tying your product, of tying your roadmap to this problem that you're looking to solve for the customer and all the milestones that you want to achieve along the way. Good strategy should be extremely obvious. Now, basically you have to take something that looks like a woolen yarn ball and then you have to just be able to straighten it out. Now, after you present a strategy as a PM, if an engineering leader comes up to you and says, hey, this is so obvious. Why have we not done this yet? Then you know you have a good strategy in place.  How am I going to kind of untangle this mess? You're not alone. Product strategies are guides to the future, yes, but they're almost always based on the information that you have at hand. And this is why it's extremely important for PMs to be adaptable and flexible. You have to meet the needs of the company. You have to meet the needs of the company that you are in at the time you are in. You also have to meet them as you go along. And this is why strategy is almost always revisited.  The second phase after you strategize is writing a PRD. Now, as a young PM, this is the area that actually I use to struggle with the most. Now, on paper, a PRD is a product requirements doc. What is that? That is basically converting your customer requirements, your use cases, your customer needs, everything that you've captured into technical requirements. Something that your engineering team can take and basically run with it. You are basically informing the engineering team of your vision and at the same time giving them the tools to be autonomous. You are setting clear guardrails as to the vision and how to proceed in a particular direction for a product. But you also are giving your stakeholders and your partner teams and your engineering teams the way and the path to actually take that product and build a solution for it. Now, a lot of people have asked me, what does a good PRD look like? And I'm going to give you the MBA answer. It depends.  It could be a living doc that you are constantly editing with your team. It could be a bag of napkin virtual cycle, but it almost always has one thing in common. A good PRD matches your company style and your team needs. I think the best practices for a PRD are to include a few things. Number one, the purpose, which is who is the customer? What are his or her needs? What is the problem you're trying to solve for them? Number two, what are the goals that this product should achieve? And not just the goals for the product, but also goals that can help the engineering team actually transform into engineering plans. These customer needs that you have laid out. Number two, something that the teams can use to measure what they've built. Three, success criteria or some companies also call this exit criteria. Now teams need to be able to measure the effectiveness of a product, measure the effectiveness of a strategy. Because building a product is just one thing. Understanding how good the product is always lies in the metrics. You've got to be able to understand what the product's contribution is to your business. Has it impacted negatively or positively? Hopefully, positively.  And I'm a strong advocate of making sure that your metrics are defined before you build the product.  Four, prioritization criteria. Resources are always constrained. You will never have enough developers in the world. You will never have more than 24 hours in a day. Resources are always constrained, which is why prioritization and figuring out the vectors along which you want to prioritize is extremely critical to a product's success. And for prioritization, there are a lot of things that you can look at to prioritize, but almost always what's worked for me is answering two most important questions. Where are we? What are our strengths? What are our weaknesses? And what can we manipulate easily and better? Number two, how do we get to where we want to go? What are our opportunities? What are our attributes? What is our leeway? What can we reverse? All these decisions, again, product management to my earlier point, you are creating a path into the future based on the data that you have at hand right now. But you must always be adaptable and flexible. These plans take you to account current day opportunities and current day weaknesses, but they're not set in stone. Finally, okay, now you've understood you've identified a problem. You've identified a customer. You've gone through the product lifecycle stages of strategizing, road mapping, PRD, and the engineering team has finally built the product. What do you do? You take it to market. What does go-to-market mean? Lots of different companies do it a lot of different ways, but GTM at its core is marketing the product. It's your playbook for how to reach customers and reach the right kind of customers. Otherwise, your product will not be viable. An excellent product needs an excellent go-to-market strategy for it to truly become a really good product market fit. I think another way of thinking about go-to-market strategy is to just take a pause and understand how can you ensure product distribution? How can you penetrate markets? How can you grow a product at scale? That is along the lines of good GTM strategy. So if you can answer those questions, then your GTM strategy is going to be solid. Now with that, I want to round the presentation with a few lessons that I learned along the way. Number one, product development is not linear. When I stepped into product management, I had the naive idealistic view of how products were built and I thought, okay, we have an idea. We go and ask the customer, hey, this I think is a pain point. Do you agree? And they validate that problem.   Because in real life, it is not at all linear at all. You have an idea, then you have to jump through a bunch of loops where you have customer research. Sometimes that goes back again into your feedback because you might learn something totally different. You might learn that it might not be a customer problem after the drawing board. There might be so many other loops that you have to jump before you get to product launch, but it is all worth it. Number two, always keep the problem that you're trying to solve top of mind because it not only helps you, but it also helps all the other teams that you're working with. Because it's the original point of agreement. That's where you started. That's how you convinced people. That's how everybody rallied around you to actually build that product. So it's key for alignment. And every time you find yourself, when you find things going off the rails or if extensive discussions are being had, always ground the team around the problem that they're trying to solve. Number three, nothing is perfect, but you got to build it anyway. And this is a hard lesson that I learned. I expected a minimum viable product to be minimum lovable. That always doesn't happen. You have a lot of challenges along the way. You have partner challenges like engineering teams probably want to work on technical debt and maybe not push features out. You might have cross functional challenges where the legal team probably doesn't want certain things implemented a certain way. Or maybe due to the politics and the environment that the product is in, laws changed. This is happening with privacy today. Maybe you have global changes such as your infrastructure probably is not designed or third party cookies can one day just be turned off. Finally, you can have timing challenges. Maybe you have to launch something in time for Thanksgiving or in terms of like I'm working with a taxation product where you actually have to launch it before the tax laws can change with the next presidency or in five years. So you might have a lot of timeline dependencies and timeline challenges. It will never be perfect, but you have to build it anyway. Finally, what is going to help a PM succeed? A lot of times PMs come up to me and ask me, hey, I strategized. I did a lot of customer research. I did extensive customer research and I put together a wonderful road map in place, but due to resource constraints that never saw the light of day. And that happens a lot. And then the obvious next question is, does that mean I failed as a PM? Absolutely not. Because one way of measuring impact as a PM is looking at the products that you've helped launch. But a better way that I have realized at least that works for me is about understanding what tangible benefits you are bringing to the team and yourself. Personal growth too. A few things that have helped me are clear communication. You definitely as a PM should be able to talk multiple languages. And when I say multiple languages, I mean be able to talk to the legal team, be able to talk to the marketing team and the engineering team, be able to talk their language, effectively communicate. Number two, advocacy. As a PM, you will almost always wear multiple hats. One day probably you are talking to a customer understanding their pain points. The other day you have to probably talk to the legal team and understand the legal implications of a product. The third day you have to talk to the infrastructure team to understand why something that works in one region is not working the exact same way in a different one. But all of these also mean that you are the epicenter.  You are the one throat to choke. And you also have the responsibility of shielding the team from all of this ambiguity. You should be willing to take hits for the team. You should be willing to take hits for the product. And that will definitely make your products, in my experience, the launches go smoother. Finally, you need to be three steps ahead of all the products and all the customer research in your area. You need to be able to, and this is a muzzle that people built over time, but you need to be able to understand where the next roadblock is going to be and how you can prevent it even before it actually happens. But that, I hope you had fun and I hope you took something away today. If not anything, I hope I've normalized being a PM and the ambiguity that comes with the job to a lot of who is listening right now. Thank you.


Welcome folks, we have the Dow Industrial finished down 83, Nasdaq up 14, S&Ps down 6.5, Gold contract up $8.70 traded at 18.34oz, we had Silver down 40, 21.62oz, Latesweet Crude off $2.47, $73.88 a barrel, notes and bonds, a 10-year note, up 3 ticks, trading 11.05, the 30-year up 16, at 124.19, and King Dollar, King Dollar up 385 ticks, trading 104.56, one Euro at 106, Yen at 134, British pound at 120 to one US dollar. We get over and take a look at the S&P, bottom line, you know, you get a lower price to really get a sideways market, it's a slow bleed, that's my take, that's what we're going to have out here, slow bleed folks, so you get a low today of 397, you close at 398.60, bottom line, you're in this lower range, next stop for the S&P is down to 274, right now, oh, 374 rather, better be 374, yeah, 374, you're at 398. We go into the NDX100, now the NDX100, this word's going to get really interesting tomorrow morning, because the NDX100 is right at the lower range, literally, you know, there's a lower range, so the lower range inside the queues start at 293.26, we closed at 294.25, we're up 22 cents, it hit a low of 292.56, but you can see we have volume, man, volume, you know, exploded out of these queues, man, we didn't have volume when I started the program, and all of a sudden, you know, yesterday we went down with 46 million, today we're down with 48, let me go back to the spy, because the spy didn't have volume, this would be really strange if this much volume came in at the close, yeah, it didn't come in at the S&Ps, yesterday on the S&Ps you had 82 million, we only did 75, S&Ps are already in the lower range, you go to the gold contract, we take a look at gold, you know, I suspect we're going to see out here tomorrow the next day, we're going to go after the B point and we'll see whether you get an ABC structure down in gold, you know, what we did, oh, look at this, dangerous, man, yeah, so the B point is 1827, we are at 1833, and you know, we'll see how this shakes out, but we might take November 8th the deal, if you're in the metals market, folks, November 8th is the deal, and I suspect, well, actually in the gold contract, November 10th, November 8th is where all the equities, a couple of them are already into that bar from November 8th, have a great night, have a safe night, don't forget about Larry's workshop, check it out at the TFNN, come visit Tommy tomorrow morning, kicks us off, nine in the morning, great show, folks, oh, look at them, folks.


Everybody welcome back to another adobe photoshop for iPad tutorial. That's right guys is brand new We're doing some photoshop iPad mobile version what I'm going to show you here is how to Change the background color from the default bright and light color to the I guess I like the darker color So really quickly here. You'll notice here that I am just inside of an artboard and I'm going to do some doodling Hi, and I just decided I don't want this color anymore Normally you'd want to click on this wheel up here at the top right But unfortunately it doesn't give you the option to change the colors in there What you need to do is I'm going to click out of that and I'm actually going to go now And I'm going to click this button up at the top left here This brings me to the home page when you're on the home page You can click up here in the top right for me It's a little circle and when I click on that you'll see here a few different options The one you want to select is you want to go to general app settings general And all you need to do is left click on that dark setting and everything in your app now is dark Thanks for watching the tutorial ton more stuff coming up. Stay tuned


All right, so welcome to our talk. We are planning to share some of our experiences on how to create OpenStack Project. So we're not exactly speaking about the low level details on what you need to do, but rather share some high level details, some pointers on what exactly it means and what's the experience of creating OpenStack Project. So who are we, guys? We are Susie Hackers. Let me present you Adam, Adam Spires, Terp Mueller, and I'm Pranav. And we have some really unique OpenStack projects. And they are quite different from the standard OpenStack projects that you see, which is basically the Python-based projects. So the biggest reason why we're here is to basically share the differences, the experiences that we generated by the differences between the standard OpenStack projects and what we have. I think that it's a great idea to take your cool idea of solving a problem in the OpenStack and the Cloud ecosystem. This problem need not be the hot topic like NFV or Docker containers or maybe even something like networking. It could be a very small tool. It could be a library, but it could be very handy. And that's something that I would like to encourage from the community because we need every possible problem to be solved to be a great project to realize OpenStack mission. And I hope that we could motivate you guys and get a great Cloud product and hope that it gets better and better every release. But before we get into the high-level details, should I create OpenStack project? What are the reasons? So the first thing that I would talk about is why I should not create OpenStack project. If I want to promote myself, if I want to promote my employer, create some sort of a competition between two projects, it doesn't make sense. To reinvent the wheel is probably not ideal. It's not exactly a bad idea. So in case of orchestration, we have Puppet, Chef, Ansible, and they're basically trying to solve the same problem. But it makes sense to have these different projects. But it doesn't make any sense to have another networking project while we have something as amazing as Neutron. And these are some of the reasons why you should not create OpenStack project. It's OK to make two long slides. It's OK. And the next thing is why should you create OpenStack project? Or why should I create OpenStack project? The biggest reason would be to help realize OpenStack mission. We all want to create open-based open source, open standard, open development-based cloud, which everyone can use. And I guess to grow my team, my project, maybe I have a great idea and I want to share it with the world. I'm solving some really good problems with it. And I would like to take it up into the community and let everyone take advantage of it. Also, at the same time, it helps me for my personal growth. And it's very obvious on how it helps. So I would like to hand over to Dirk, who is going to speak more about governance and what it all means. Thank you for enough. So before we start in getting all the nitty-ditty details on how to actually do it, I have to bore you with a little bit of theory behind it. And I apologize, but this is how it is. So when you think about creating a new project, the main thing you want to think about initially is how your mission or how your vision of the new project is correlating with the OpenStack mission. So what is the OpenStack mission? The OpenStack mission is on the web page, blah, blah, blah. It produces the ubiquitous open source cloud computing platform. It's for public private cloud. It's simple to implement and massively scalable. So this gives you a lot of opportunity to resonate and think about how your project goals and how your way of improving the OpenStack software ecosystem could be resonating to that mission. When we talk about the OpenStack governance, of course, there's this mission statement, but there's also the technical committee. The technical committee is elected by the developers of the OpenStack project. And it embodies the technical leadership of OpenStack. So what's its goal? It enforces the OpenStack ideals. And I'm going to go into more details just after that. And it decides an arbitrage cross-project each year. So it's an embody of trusted developers that have been elected by the OpenStack community. And they are a task to resolve conflicts. They are a task to set the mission into an implementation. They are a task to actually represent the ultimate board of conflict resolution if there are such on the table. OK, so one thing you cannot avoid when you talk about the OpenStack principles is the four opens. So what are the four opens? Open, open sign is clear. First thing is open source. I'm going to go into more details about that just now. Next thing is open design. And this is usually a tough one for people who are coming from a more enterprise-related environment where you have an in-house organizational structure that is slightly conflicting with that. The open development model, this is quite a change for people who are not used to work in the open, especially for developers. I mean, and last but not least, the open community. So coming back, what is open source? Open source means your project has to be under an open source license. The TC strongly recommends Apache version 2.0. I think most of the projects are following that. And what does it mean in addition? It also means the project is the whole thing. So there's no way of doing your business with like doing an open source variant of it that has less features and you sell the enterprise edition. That doesn't work. It has to be non-open core. It should not depend on components that effectively impact the distribution of the project. So if you think about creating an open source project that is only a wraparound like some non-resistible non-open source components, then you will have a hard time in entering the open stack governance projects. Going further, what means open design? And open design is what you exactly experience here going forward for the rest of the week. Everything is happening at the design summit, which happens twice a year. People from all over the world are coming together to gather the requirements to learn about the roadmaps, to develop the roadmaps, to resolve conflicts, to make a plan on how their projects are moving forward. And you need to be ready for that, which basically means all your road map is being developed in the open. You accept the input from others, like other companies, other contributors, other projects that have an interest in collaborating with yours. Your communication about the project goals, about the project development, about the project vision mission is done in the open. And you do all the communication, which are central to your project decision on how you move forward through public mailing list. Next item, open development. So this is the part where some developers might get a bit less happy about the situation. So every change to open stack projects has to be done as a pull request in the open. So everyone can go, and I actually invite you to do that before you even think about starting a project, can go to revieopenstack.org, and look at the upcoming pull requests. Anyone is allowed to sign up for an account. Anyone can comment on pull request, can suggest improvements, can basically act to change, and think this is common on it, and vote on it, that this is a good change. And Adam is going to go into more details on that fairly soon. You've got to define an open group of core approvers. So the core approvers are a group of trusted developers around the project that have special privileges. So they have the privilege to merge changes into the project. And this group is not closed. This group is not secret. It's documented in the public, and it's open. That means other people have the chance to become part of that core group. And the project needs to focus on cooperation. This is a bit of a hot topic, because at the one side, open source projects can compete when they think they have a better technical solution for the same problem. But in general, and in a majority of cases, this is not seen so well. So you should prefer to think about how to cooperate with other projects, or how to have interfaces with them, how to enable other projects in integrating with your project, and vice versa. And you should be very open to reusing code and code patterns that are developed alongside in the OpenStack project space by others, which means you should avoid reinventing the wheel just because you want to reinvent the wheel. One specific topic about the development part is the testing. So OpenStack has a very, very massive automated testing infrastructure. And it's part of the things where the TC or the OpenStack developers are really proud of. So every change has to have a test case associated with an data test, very strict guidelines on how the testing for each project needs to be set up. It needs to be in the public. It needs to be reproducible for people so that they can run the tests on their own. So it can't be on some secret environment that doesn't provide log files or anything like that. And in addition to that, projects are healthy to follow a strong coding style. For Python projects, that's easy because there is a standard for that. And every Python project is following that. For other languages, use something that is similar. So don't bike shed over coding style. Use a tool to cover that part in the site for a tool and then move on. And the last point is about the Open Community. So OpenStack projects are proud to build a healthy and vibrant community. What does that mean? So the primary principle on which the community is supposed to act is the model of lazy consensus. So this basically means if you're intending to do a change to the project, your primary assumption is that you're allowed to do the change. So instead of first going to other people and asking about whether you should or whether you're allowed to do the change, you simply do the change and you put it up for review. And other people are allowed to comment on it. But by default, you're acting in a model that you are empowered to do the change that you want to do. In addition to that, it means processes are documented, which means when there are specific requirements for your project, this knowledge needs to be documented in public so that other contributors who are interested in contributing to your project can read about it and can learn about it without learning it after the fact. It also means you as a project have to come up with a project team. And this project team has to choose a technical lead. For governance-run projects, every six months you have to vote as a contributor group for a PTL, so a technical lead who is for the next cycle, the ultimate liaison for the technical committee and for other projects to have an interface into your project and a communication point. And last but not least is that your meetings are held in public. And the standard way of doing that in OpenStack is to use the public ISE infrastructure. And Adam is going to go into more detail tonight. And with that, I hand over back to Pranav. Thanks, Dirk. So I would like to discuss a few things about setting up your project. So the biggest discussion on our topic is Big Tent or Not. I would say that it's not so important to think about Big Tent or Not to Big Tent to start with, because it's your project, it's your idea, and it has to solve the problem in compliance with the OpenStack mission. The right approach or more idealistic approach would be to think what exactly a project needs. What are the resources? What are the things that are already existing in the OpenStack ecosystem? Sometimes it makes sense to go for a specialty team or a sub-project, or maybe a project in Stackforge. And this is very important, because you need to do the right thing, to choose the right technologies, and you also need to base your decisions based on technical facts. That's what the technical committee is looking for. And also, of course, you need to take care of how your repository looks, various things, depending on what is your programming language. You need to decide how the CI system would interact. And testing interfaces, you need the right sort of unit test, functional test. And it fairly depends on what exactly you're trying to solve, and what are the technical decisions. So there is some really good documentation on how to set up your project. And it gives you all the information you need with some brief description of the history, of the mission statement, what are the four opens that Dirk explained. And that also gives you a starting point to allow you to start giving the pull request for creating your initial project or the repository of the project. The more important thing is to make sure that you get your patches reviewed and merged. If it's a project in BigTent, then you need your patch in the governance repository to be merged first, and then rest of the patches in the infra and the other places would automatically follow. This may require quite a bit of discussion, depending on the topic, depending on how easy it is to convince the technical committee. But you can make it easier by checking your repository, by checking all the things that you need for the CI system, for the review system, and to gather the right people who are your core approvers. And of course, you need to choose the right name for your project. It's a bit funny, but if you guys are following Neutron from quite some time, the rename from Quantum to Neutron, it was not so easy for the rest of the community to follow it. And it's misleading, it's confusing, and it would be great if you can take a look into this, make some research, and choose the right name. And if you're starting from scratch, then you should think of using the cookie cutter, but you may not really need it. And it depends on your project. So if you're using Python, and if it's following some sort of standard OpenStack projects design principles or the way the repository should be laid out, then it makes sense to use the OpenStack cookie cutter, because you'll save a lot of time. A lot of things, the way your repository should be laid out, the right structure, all of these things are already present in the form of templates. And you just answer a few simple questions, and you get the starting point of your repository. But of course, that's just a starting point. And I would invite Adam to explain more on what happens after you create your project. Yeah, thanks. And just before I go into this section, I just wanted to quickly mention, in case you didn't notice at the beginning, we have put these slides online. And if you want more details about the specifics of the things we're talking about, which repositories need to be changed, or how to get the cookie cutter, or that kind of thing, these slides have a whole ton of hyperlinks in them. So you can just look at the online version and then go follow the links and get all the technical details you need. So code review, as Dirk said, open development is a critical part of OpenStack projects. So code review is obviously essential for collaborating with other people. Everyone knows the plus one vote when you like somebody else's code. That's always very straightforward to give. The minus one is a bit more tricky, and especially in the OpenStack context, you need to be a bit more careful about how you go about doing that. So of course, constructive criticism and collaboration applies to any project, whether it's in an OpenStack or not. But in OpenStack, I think it's particularly important to remember that you're collaborating potentially with hundreds, if not thousands of developers all around the world from a huge variety of different cultures and backgrounds. So just being aware of how you offer constructive feedback, the sort of cliche is that you give some positive comments and then your negative comments and then some positive things and it kind of cushions the blow. But that advice is, as you can see from the diagram, putting something in between two suite layers is not always necessarily a way of making it more digestible. But at the same time, just being positive, welcoming, open-minded, and aiming to leave the contributor, wanting to come back to collaborate more is the ultimate aim. So as the person who set up the project, you will automatically become a core reviewer. And so you're responsible for giving the plus two vote when you think changes are suitable to be merged. You will also need to bear in mind who else needs to be in that core reviewer group. And as your project changes size and shape over time, the list of people on that core reviewers will need to change potentially as well. So there are other review mechanisms. There's the minus two, but that's like a really strong veto. So try and avoid that unless you really want to make sure that something is definitely, have no chance of being merged. And then there's these workflow plus one and minus ones, which is basically telling the CI should it go ahead and merge something or not. So you can use the plus one is the final of the workflow is the final indicator to the CI say, yes, merge this. The minus one is for stuff that changes that are still in a sort of draft form, work in progress. There's also like just a zero vote. You can add useful comments to review without voting and maybe people sometimes neglect that. But if you're indifferent to the change, but you have some opinion or suggestion that you want to offer, then you can use that. So there's a link there to the core reviewers guide for more information. And there's also this useful tool that's worth mentioning, this dashboard creator in Garrett where you can compile custom dashboards that give you a view of your, the particular review queue that you care about. So in the OpenStack World CI, as we've already heard, is incredibly important and all the infrastructure that we have for CI is very good, very sophisticated. So we need to take advantage of that. This is a screenshot of kind of a bit of a Hall of Shame thing on status.openstack.org. No one wants to be in the Hall of Shame, so make sure you're looking after your project's CI and that it's always passing and that will breed confidence in your project. And also remember that just having passing CI and just not enough code coverage is also important. So release management is an important topic, especially if you're in the big tent, then there are some recommendations around how you should build your release model. There's the various options there. I won't go into the details, but there are tags which can be applied to your project in the governance repository. And the, yeah, there are links, but actually the link at the bottom here will give you more information on the different release models. There's also an existing mechanism for building and publishing your Tar Balls whenever you make a release. There's a tool that was announced recently for, fairly recently, I think, for automating the build of release notes which might be worth looking into if you want help with that. Of course, there's the whole mechanism for doing translations if your project contains human readable strings that need to be translated into different languages. And there's a standard established open stack mechanism for that, which you should tie into. And yeah, as I said, the last link on the slide there, it will give you lots more information on this. So support, of course, is essential for the health of your project. It really is the difference between success and failure, I would say, or one of the differences. So bug tracking and issue tracking is an obvious part of this. Launchpad is always recommended, I think, as most of the projects tend to use Launchpad these days. And as with any project, really, just being responsive and ensuring that your bugs and your issues are always in a correct state so that if somebody's joining the project, they can see some accurate information. It can be quite demotivating when you come into a project and try and understand the status and all the information is out of date. Mailing lists are a core focus, focal point for communication within OpenStack, especially OpenStack Dev. If you haven't seen it before when you join, you'll be astonished by the volume on there. And that can be a problem. One thing you can do to deal with that is these badges or labels that you can see in the subject line that will make it clear what the topic is and then people can set up filters and avoid missing important emails. IRC, as mentioned earlier, is also a focal point for communication on a quicker feedback basis. And there is the possibility to set up your own channel for your project if you want. It doesn't always make sense. First, look at what's already out there and then talk to the OpenStack Infra-team to decide whether it makes sense to create a new channel. And yeah, if you have a channel, then obviously look after it and make sure that if somebody comes on there, then they get the responses they need. Otherwise, they'll just give up and never come back. At first, your project may be quiet, so watch the channel and hopefully things will build gradually. One way you can add a small bit of immediate value to the IRC channel is setting up the IRC bot which for Garrett notifications, so if people are submitting changes, then you can get the bot to automatically announce them on the channel, which can be quite good for making people feel connected with the project. Here's an example config and an example output at the top and then the config for setting that up. And so that's kind of reacting to giving reactive support when people come in and ask for help, but then if you really want to accelerate the growth of your project, then being more proactive is important. I think there are several ways to do this. As mentioned earlier, there's the IRC meetings and one important point here is that if you're setting up IRC meetings, which you can do by reading this Wiki link here, then you have to, or at least very strongly, encourage to hold the meetings in one of the existing dedicated meeting channels on OpenStack IRC rather than holding it in your own channel. The reason for that is to try and minimize the number of clashes between different meetings. So there are only about five or six IRC channels dedicated to OpenStack meetings. So if you go in one of those, then you'll avoid clashes with other meetings. And of course, we do all this online stuff, but meeting face to face. Everyone here obviously appreciates the importance of that, otherwise you wouldn't be here, but there's the other opportunities outside the summits for meetups in local meetups and mid-cycle meetups and so on. So if your project would benefit from that kind of thing, then do think about setting that up. And then of course, there are all these different other ways that we're all familiar with, which are mostly not specific to OpenStack in general, but a couple of points, maybe if you're blogging, which is a great idea, then get your blog aggregated out onto planet.openstack.org. Work with the, if you have some changes which affect multiple projects other than your own, then maybe the cross-project working group can help out and there's also the product working group which can kind of represent the user side of the community and connect the technical aspects of your project with what users actually need. So we'll talk about our three different projects that we set up and just give some lessons learned from those. I'll go first since I'm already talking and so my project that I set up, I guess about seven months ago, I think it was just a bit before Tokyo was a project called OpenStack Resource Agents.  And I'm also gonna do another great presentation technique which is just to read off the slides. So yeah, this project is for managing OpenStack services, which inside Pacemaker, which is a clustering technology, so making OpenStack services highly available. It's been around for several years. It was started well before I got involved in this area, actually by an ex-colleague of Florian. And it's used by quite a lot of people but the maintainer left the OpenStack world and went on to other things. And at some point after it had been unmaintained for a while I said, I think people are using this we need to move it into the OpenStack world and everyone agreed. So and I by suggesting it accidentally volunteered for the job. So and a lesson here I think is worth collaborating with the community even before you start thinking about creating a project just to check that it's worth it. So how did I do it? Well, I imported from the existing repository. There's a trick for that which is documented in the project creators guide. I had no volunteers for co-maintaining which was a shame but it was also great because it means that I'm in control of everything you can take over the world. There was no CI. So I had to use just this no op jobs thing in to set up the CI which yeah, just pretends the CI but doesn't do anything. There were no stable branches that's fixed now. There were no releases and no release model that's in the process of being fixed. And the point here is it doesn't have to be perfect before moving it into the OpenStack tent. It still can be worth it. On the government side, there was no suitable team with the PTL to put it under. So at the moment it's not in the big tent. And if I wanted to create a team then something like OpenStack HA would be too broad because that high availability in OpenStack means lots of different things. So and we need time to prove that the project is gonna be around to stay. So the lesson here is yeah, you don't have to go into the big tent straight away. There's still value. You can put effort into earning that place. And we have the IRC channel that I set up, Launchpad Tracker. We have weekly IRC meetings which are helping with the momentum quite a lot. We have a mailing list tag on OpenStack Dev which is helping filter emails. I've been giving talks and momentum is building. So things are going well so far and on to do. Thanks. Just quickly going over the RPM packaging project that we launched or the idea was spread in the Vancouver Summit, which is roughly exactly a year ago. And initially it was just like yeah, we should collaborate on RPM packaging. So currently there are big players on the market. They are differentiating themselves on providing an OpenStack distribution, which is good, but it's also bad in the sense that it makes the work for the upstream projects harder because every existing packaging mechanism was slightly different. And the idea is simply we shouldn't differentiate on the packaging level like how you name the package or how it's just more confusion than it's worth. So the idea was to start an effort to consolidate that. This initially started directly as a BigTank project directly from with Codds from the three major players for OpenStack packaging or RPM-based packaging. And after quite some time of discussion and defining the project team and the actual project scope, we got an governance approval for entering the BigTank right away without actually having anything. So we started with a really empty repository. So at the top of this, you can see the graph of the commits of this repository. It's also slightly spiky and not very exponential like we saw in the keynotes. But overall, the benefits of the BigTank project for me were very variable. For example, we suddenly had a single point of contact for other OpenStack teams defined. So other teams in the BigTank who were like forward, okay, I need to talk to someone who knows about packaging, how do I do that? And suddenly there's a single point of contact because there's a project around that and you can hop on the ISC channel and you find the right person to talk to. Also being part of the BigTank meant that it enables cross-project dependencies. We are not currently using that but we are trying to do that. Basically what this means is that all the Ansible's cookbooks or playbooks, playbooks, sorry, and all the other conflict management tools, they can gauge their changes against the common packaging going in the future. So different projects can make sure that they are all compatible for each other and this on a change by change basis which is a big step forward to what was happening before. And another benefit as we had is entering the BigTank meant we had to follow a lot of governance principles but that was actually a good thing because that gave us guidance and structure because initially we were like newly found a project and there are like 500 ways to reinvent the wheel which doesn't make a lot of sense. So just by following the governance, impose BigTank principles, we solved a lot of discussion points. And last but not least, it finally moved all the downstream development efforts that the distribution maintainers are doing back to upstream. So the lesson learned that I have to take away from that is creating a new project, especially if it's not like a standard Python OpenStack project is complex. Creating a team and finding regular contributors and getting everyone on board is challenging. We had both like to set up the actual tooling for that because there was no existing project to build upon or while there were too many existing projects to build upon and we didn't have a project structure initially and the lesson learned here was really by following the BigTank principles we had a chance to establish the project going forward. Thanks, Pranav. Yeah, so I want to talk about training labs. It's a very tricky topic, training in OpenStack and basically what I'm creating is a tool to automate deployment of OpenStack on a very small lean basis on a laptop or on a computer. And what we try to do on the technical terms is the other way around, we try to deploy OpenStack on as small and as minimalistic cluster of VMs as possible so that everyone can just do a one-click installation and set up the entire cluster so they can learn OpenStack, they can play around with it and that is quite challenging also on a few more things which is the basic point of trying to explain this project to the technical committee was very difficult. Although this project was existing as a part of training guides, which is related to training but to deliver the documentation or the presentation, I think the upstream university is based from training guides and we forked from training guides because we had a different way of working, different way of release model. And the biggest issue was that how to exactly push a project based purely on Bash which is using VirtualBox and KVM as the backend to deploy OpenStack while people are designing OpenStack to scale out and into massive data centers, we are trying to do the opposite. And this made us decide to add it as a specialty team so maybe we had a chance to create it as a separate project to try and gather everyone doing training around the world and create a big 10 project but it made more sense to be a specialty team and a documentation project because we are very closely integrated and working with installation guides and also with training guides to a big extent. And the other thing is that we kind of benefit from the existing infrastructure, the existing team of documentation team. I think documentation project has some really amazing people up there as the core approvers and their guidance has been very helpful. The biggest reason is that we have very small team about three regular developers and around two or three developers who sometimes appear to some work for a couple of weeks and then vanish for another couple of weeks. So this allowed us to also have some sort of backup reviewers in case one of the three guys or two of the three guys were on vacations. We were basically on the same time zone so we have a similar vacation pattern. Then there are other people from the documentation project to step in and provide reviews. Sometimes we need to do some changes based on maybe the some things which are like housekeeping or management of translation or the things that we need to take care of. These are automatically committed by the documentation team, the person responsible to update everything in there and that reduces our workload and that's actually amazing. And the biggest decision or the biggest lesson that I learned with training labs was after creation of this project. I had a very long chat with Defi Helman which I assume who is part of the release committee of OpenStack. And I realized that he was really trying to understand how the project is delivered or how we plan to deliver it to our users and that the release cycle is not set in stone. That it is actually something that we have to decide and it should be flexible as per our project and our users and not as per the standard way of releasing an OpenStack. And I think that was a really good experience to try and get one of these weird projects into OpenStack which kind of doesn't fit in but it's also quite important. So I would like to invite you guys to ask some questions or comments. I mean if you have a question, if you could go to one of the, I guess that's the only microphone. So that microphone. I'll just pick up, you can repeat it. Yeah, all right. You give a recommendation about creation project that's written in Python but could you give some recommendation how to create project that's written in some different language? Yeah, so I think I have to do that with training labs we started with Bash. And so you need to understand why the repository structure of a standard OpenStack project is laid out. If you understand the reason behind it. So the doc folder is basically having this, the Python Spinks based documents marked on RST and it's for delivering the developer documentation and other different documentation of your project. So you can really try to understand that, okay, I don't have to worry about this. I can deliver this or I can think of another way. Maybe you're using Golang and you could use different way to parse it and get the same output and deliver the docs to maybe the documentation team or wherever it's required. And if you are able to understand this and if you have a very good reason why you're not using Python and also follow the conventions, if your project is in line with the mission, then it should not be very difficult to convince but maybe there would be some resistance but it is possible to add your project into OpenStack ecosystem. I don't know if there are many projects which are not written in Python and are quite technical in nature but I think it's possible and I think people are talking about it. There were some talks in the past few summits about using different languages to improve the innovation of OpenStack. Okay, thank you. With that I think we are way over time so when I conclude, if you have any additional questions, feel free to just talk to us directly. Thanks a lot. Thank you. Thank you.