Search the Community

Jason Perlow, Editorial Director of the Linux Foundation, chats with Jory Burson, Community Director at the OpenJS Foundation about open standardization efforts and why it is important for open source projects. JP: Jory, first of all, thanks for doing this interview. Many of us know you from your work at the OpenJS Foundation, the C2PA, and on open standards, and you’re also involved in many other open community collaborations. Can you tell us a bit about yourself and how you got into working on Open Standards at the LF? JB: While I’m a relatively new addition to the Linux Foundation, I have been working with the OpenJS foundation for probably three years now — which is hosted by the Linux Foundation. As some of your readers may know, OpenJS is home to several very active JavaScript open source projects, and many of those maintainers are really passionate about web standards. Inside that community, we’ve got a core group of about 20 people participating actively at Ecma International on the JavaScript TCs, the W3C, the Unicode Consortium, the IETF, and some other spaces, too. What we wanted to do was create this space where those experts can get together, discuss things in a cross-project sort of way, and then also help onboard new people into this world of web standards — because it can be a very intimidating thing to try and get involved in from the outside. The Joint Development Foundation is something I’m new to, but as part of that, I’m very excited to get to support the C2PA, which stands for Coalition for Content Provenance and Authenticity; it’s a new effort as well. They’re going to be working on standards related to media provenance and authenticity — to battle fakes and establish trustworthiness in media formats, so I’m very excited to get to support that project as it grows. JP: When you were at Bocoup, which was a web engineering firm, you worked a lot with international standards organizations such as Ecma and W3C, and you were in a leadership role at the TC53 group, which is JavaScript for embedded systems. What are the challenges that you faced when working with organizations like that? JB: There are the usual challenges that I think face any international or global team, such as coordination of meeting times and balancing the tension between asynchronously conducting business via email lists, GitHub, and that kind of thing. And then more synchronous forms of communication or work, like Slack and actual in-person meetings. Today, we don’t really worry as much about the in-person meetings, but still, there’s like, this considerable overhead of, you know, “human herding” problems that you have to overcome. Another challenge is understanding the pace at which the organization you’re operating in really moves. This is a complaint we hear from many people new to standardization and are used to developing projects within their product team at a company. Even within an open source project, people are used to things moving perhaps a bit faster and don’t necessarily understand that there are actually built-in checks in the process — in some cases, to ensure that everybody has a chance to review, everybody has an opportunity to comment fairly, and that kind of thing. Sometimes, because that process is something that’s institutional knowledge, it can be surprising to newcomers in the committees — so they have to learn that there’s this other system that operates at an intentionally different pace. And how does that intersect with your work product? What does that mean for the back timing of your deliverables? That’s another category of things that is “fun” to learn. It makes sense once you’ve experienced it, but maybe running into it for the first time isn’t quite as enjoyable. JP: Why is it difficult to turn something like a programming language into an internationally accepted standard? In the past, we’ve seen countless flavors of C and Pascal and things like that. JB: That’s a really good question. I would posit that programming languages are some of the easier types of standards to move forward today because the landscape of what that is and the use cases are fairly clear. Everybody is generally aware of the concept that languages are ideally standardized, and we all agree that this is how this language should work. We’re all going to benefit, and none of us are necessarily, outside of a few cases, trying to build a market in which we’re the dominant player based solely on a language. In my estimation, that tends to be an easier case to bring lots of different stakeholders to the table and get them to agree on how a language should proceed. In some of the cases you mentioned, as with C, and Pascal, those are older languages. And I think that there’s been a shift in how we think about some of those things, where in the past it was much more challenging to put a new language out there and encourage adoption of that language, as well as a much higher bar and much more difficult sort of task in getting people information out about how that language worked. Today with the internet, we have a very easy distribution system for how people can read, participate, and weigh in on a language. So I don’t think we’re going to see quite as many variations in standardized languages, except in some cases where, for example, with JavaScript, TC53 is carving out a subset library of JavaScript, which is optimized for sensors and lower-powered devices. So long story short, it’s a bit easier, in my estimation, to do the language work. Where I think it gets more interesting and difficult is actually in some of the W3C communities where we have standardization activities around specific web API’s you have to make a case for, like, why this feature should actually become part of the platform versus something experimental… JP: … such as for Augmented Reality APIs or some highly specialized 3D rendering thing. So what are the open standardization efforts you are actively working on at the LF now, at this moment? JB: At this exact moment, I am working with the OpenJS Foundation standards working group, and we’ve got a couple of fun projects that we’re trying to get off the ground. One is creating a Learning Resource Center for people who want to learn more about what standardization activities really look like, what they mean, some of the terminologies, etc. For example, many people say that getting involved in open source is overwhelming — it’s daunting because there’s a whole glossary of things you might not understand. Well, it’s the same for standardization work, which has its own entire new glossary of things. So we want to create a learning space for people who think they want to get involved. We’re also building out a feedback system for users, open source maintainers, and content authors. This will help them say, “here’s a piece of feedback I have about this specific proposal that may be in front of a committee right now.” So those are two things. But as I mentioned earlier, I’m still very new to the Linux Foundation. And I’m excited to see what other awesome standardization activities come into the LF. JP: Why do you feel that the Linux Foundation now needs to double down its open standards efforts? JB: One of the things that I’ve learned over the last several years working with different international standards organizations is that they have a very firm command of their process. They understand the benefits of why and how a standard is made, why it should get made, those sorts of things. However, they don’t often have as strong a grasp as they ought to around how the software sausage is really made. And I think the Linux Foundation, with all of its amazing open source projects, is way closer to the average developer and the average software engineer and what their reality is like than some of these international standards developing boards because the SDOs are serving different purposes in this grander vision of ICT interoperability. On the ground, we have, you know, the person who’s got to build the product to make sure it’s fit for purpose, make sure it’s conformant, and they’ve got to make it work for their customers. In the policy realm, we have these standardization folks who are really good at making sure that the policy fits within a regulatory framework, is fair and equitable and that everybody’s had a chance to bring concerns to the table — which the average developer may not have time to be thinking about privacy or security or whatever it might be. So the Linux Foundation and other open source organizations need to fit more of the role of a bridge-builder between these populations because they need to work together to make useful and interoperable technologies for the long term. That’s not something that one group can do by themselves. Both groups want to make that happen. And I think it’s really important that the LF demonstrate some leadership here. JP: Is it not enough to make open software projects and get organizations to use them? Or are open standards something distinctly different and separate from open source software? JB: I think I’ll start by saying there are some pretty big philosophical differences in how we approach a standard versus an open source project. And I think the average developer is pretty comfortable with the idea that version 1.0 of an open source project may not look anything like version 2.0. There are often going to be cases and examples where there are breaking changes; there’s stuff that they shouldn’t necessarily rely on in perpetuity, and that there’s some sort of flex that they should plan for in that kind of thing. The average developer has a much stronger sense with a standardization activity that those things should not change. And should not change dramatically in a short period. JavaScript is a good example of a language that changes every year; new features are added. But there aren’t breaking changes; it’s backward compatible. There are some guarantees in terms of a standard platform’s stability versus an open source platform, for example. And further, we’re developing more of a sense of what’s a higher bar, if you will, for open standards activities, including the inclusion of things like test suites, documentation, and the required number of reference implementations examples. Those are all concepts that are kind of getting baked into the idea of what makes a good standard. There’s plenty of standards out there that nobody has ever even implemented — people got together and agreed how something should work and then never did anything with it. And that’s not the kind of standard we want to make or the kind of thing we want to promote. But if we point to examples like JavaScript — here’s this community we have created, here’s the standard, it’s got this great big group of people who all worked on it together openly and equitably. It’s got great documentation, it’s got a test suite that accompanies it — so you can run your implementation against that test suite and see where the dragons lie. And it’s got some references and open source reference implementations that you can view. Those sorts of things really foster a sense of trustworthiness in a standard — it gives you a sense that it’s something that’s going to stick around for a while, perhaps longer than an open source project, which may be sort of the beginnings of a standardization activity. It may be a reference to implementing a standard, or some folks just sort of throwing spaghetti at a wall and trying to solve a problem together. And I think these are activities that are very complementary with each other. It’s another great reason why other open source projects and organizations should be getting involved and supporting standardization activities. JP: Do open standardization efforts make a case for open source software even stronger? I think so — I just see them as so mutually beneficial, right? Because in the case of an open standards activity, you may be working with some folks and saying, well, here’s what I’m trying to express what this would look like — if we take the prose — and most of the time, the standard is written in prose and a pseudocode sort of style. It’s not something you can feed into the machine and have it work. So the open source projects, and polyfills, and things of that sort can really help a community of folks working on a problem say, “Aha, I understand what you mean!” “This is how we interpreted this, but it’s producing some unintended behaviors”, or “we see that this will be hard to test, or we see that this creates a security issue.” It’s a way of putting your ideas down on paper, understanding them together, and having a tool through which everybody can pull and say, Okay, let’s, let’s play with it and see if this is really working for what we need it for.” Yes, I think they’re very compatible. JP: Like peanut butter and jelly. JB: Peanut butter and jelly. Yeah. JP: I get why large organizations might want things like programming languages, APIs, and communications protocols to be open standards, but what are the practical benefits that average citizens get from establishing open standards? JB: Open standards really help promote innovation and market activity for all players regardless of size. Now, granted, for the most part, a lot of the activities we’ve been talking about are funded by some bigger players. You know, when you look at the member lists of some of the standards bodies, it’s larger companies like the IBMs, Googles, and Microsofts of the world, the companies that provide a good deal more of the funding. Still, hundreds of small and midsize businesses are also benefiting from standards development. You mentioned my work at Bocoup earlier — that’s another great example. We were a consulting firm, who heavily benefited from participating in and leveraging open standards to help build tools and software for our customers. So it is a system that I think helps create an equitable market playing field for all the parties. It’s one of those actual examples of rising tides, which lift all boats if we’re doing it in a genuinely open and pro-competitive way. Now, sometimes, that’s not always the case. In other types of standardization areas, that’s not always true. But certainly, in our web platform standards, that’s been the case. And it means that other companies and other content authors can build web applications, websites, services, digital products, that kind of thing. Everybody benefits — whether those people are also Microsoft customers, Google customers, and all that. So it’s an ecosystem. JP: I think it’s great that we’ve seen companies like Microsoft that used to have much more closed systems embrace open standards over the last ten years or so. If you look at the first Internet Explorer they ever had out — there once were websites that only worked on that browser. Today, the very idea of a website that only works on one company’s web browser correctly is ridiculous, right? We now have open source engines that these browsers use that embrace open standards have become much more standardized. So I think that open standards have helped some of these big companies that were more closed become more open. We even see it happen at companies like Apple. They use the Bluetooth protocol to connect to their audio hardware and have adopted technologies such as the USB-C connector when previously, they were using weird proprietary connectors before. So they, too, understand that open standards are a good thing. So that helps the consumer, right? I can go out and buy a wireless headset, and I know it’ll work because it uses the Bluetooth protocol. Could you imagine if we had nine different types of wireless networking instead of WiFi? You wouldn’t be able to walk into a store and buy something and know that it would work on your network. It would be nuts. Right? JB: Absolutely. You’re pointing to hardware and the standards for physical products and goods versus digital products and goods in your example. So in using that example, do you want to have seven different adapters for something? No, it causes confusion and frustration in the marketplace. And the market winner is the one who’s going to be able to provide a solution that simplifies things. That’s kind of the same thing with the web. We want to simplify the solutions for web developers so they’re not having to say, “Okay, what am I going to target? Am I going to target Edge? Am I going to target Safari?” JP: Or is my web app going to work correctly in six years or even six months from now? JB: Right! JP: Besides web standards, are there other types of standardization you are passionate about, either inside the LF or in your spare time? JB: It’s interesting because I think in my career, I’ve followed this journey of first getting involved because it was intellectually interesting to me. Then it was about getting involved because it was about making my job easier. Like, how does this help me do business more effectively? How does this help me make my immediate life, life as a developer, and my life as an internet consumer a little bit nicer? Beyond that, you start to think of the order of magnitude: our standardization activities’ social impact. I often think about the role that standards have played in improving the lives of everyday people. For the last 100 years, we have had building standards, fire standards, and safety standards, all of these things. And because they developed, adopted, and implemented in global policy, they have saved people’s lives. Apply that to tech — of course, it makes sense that you would have safety standards to prevent the building from burning down — so what is the version of that for technology? What’s the fire safety standard for the web? And how do we actually think about the standards that we make, impacting people and protecting them the way that those other standards did? One of the things that have changed in the last few years is that the Technical Advisory Group group or “TAG” at the W3C are considering more of the social impact questions in their work. TAG is a group of architects elected by the W3C membership to take a horizontal/global view of the technologies that the W3C standardizes. These folks say, “okay, great; you’re proposing that we standardize this API, have you considered it from an accessibility standpoint? Have you considered it from, you know, ease of use, security?” and that sort of thing. In the last few years, they started looking at it from an ethical standpoint, such as, “what are the questions of privacy?” How might this technology be used for the benefit of the average person? And also, perhaps, how could it potentially be used for evil? And can we prevent that reality? So one of the thingsI think is most exciting, is the types of technologies that are advancing today that are less about can we make X and Y interoperable, but can we make X and Y interoperable in a safe, ethical, economical, and ecological fashion — the space around NFT’s right now as a case in point. And can we make technology beneficial in a way that goes above and beyond “okay, great, we made the website, quick click here.” So C2PA, I think, is an excellent example of a standardization activity that the LF supports could benefit people. One of the big issues of the last several years is the authenticity of media that we consume things from — whether it was altered, or synthesized in some fashion, such as what we see with deepfakes. Now, the C2PA is not going to be able to and would not say if a media file is fake. Rather, it would allow an organization to ensure that the media they capture or publish can be analyzed for tampering between steps in the edit process or the time an end user consumes it. This would allow organizations and people to have more trust in the media they consume. JP: If there was one thing you could change about open source and open standards communities, what would it be? JB: So my M.O. is to try and make these spaces more human interoperable. With an open source project or open standards project, we’re talking about some kind of technical interoperability problem that we want to solve. But it’s not usually the technical issues that cause delays or serious issues — nine times out of ten; it comes down to some human interoperability problem. Maybe it’s language differences, cultural differences, or expectations — it’s process-oriented. There’s some other thing that may cause that activity to fail to launch. So if there were something that I could do to change communities, I would love to make sure that everybody has resources for running great and effective meetings. One big problem with some of these activities is that their meetings could be run more effectively and more humanely. I would want humane meetings for everyone. JP: Humane meetings for everyone! I’m pretty sure you could be elected to public office on that platform. <laughs>. What else do you like to do with your spare time, if you have any? JB: I love to read; we’ve got a book club at OpenJS that we’re doing, and that’s fun. So, in my spare time, I like to take time to read or do a crossword puzzle or something on paper! I’m so sorry, but I still prefer paper books, paper magazines, and paper newspapers. JP: Somebody just told me recently that they liked the smell of paper when reading a real book. JB: I think I think they’re right; I think it feels better. I think it has a distinctive smell, but there’s also something very therapeutic and analog about it because I like to disconnect from my digital devices. So you know, doing something soothing like that. I also enjoy painting outdoors and going outside, spending time with my four-year-old, and that kind of thing. JP: I think we all need to disconnect from the tech sometimes. Jory, thanks for the talk; it’s been great having you here. The post Interview with Jory Burson, Community Director, OpenJS Foundation on Open Source Standards appeared first on Linux Foundation. The post Interview with Jory Burson, Community Director, OpenJS Foundation on Open Source Standards appeared first on Linux.com. View the full article

We are proud to announce the launch of our Leaders in Tech editorial series. Speaking to leaders in the industry to capture their stories, career highs and lows, their trials and successes, their current company and their role, most recent projects, advice to others, and the individuals who they most look up to in the industry. Aimee Bechtle is the Head of DevOps and Cloud Platform Engineering at S&P Global. Aimee specializes in helping large organizations deliver value to the business faster with safety, by working backward from the customer to solve their problems and then unleash innovation using the power of Agile, DevOps and the Cloud. So, we sat down with Aimee to find out more about why she joined the tech industry, what her role entails, what are the challenges she faces as a tech leader and her advice to aspiring engineers and developers. What are your current role and responsibilities? I am the Head of DevOps and Cloud Platform Engineering for S&P Global’s Market Intelligence Division. I am responsible for the system that enables application teams to deliver high quality working software at a high frequency into a scalable, highly available cloud infrastructure. You work at S&P Global, what was your journey like? How did you get where you are now? My journey has been and still is, an unpredictable and exciting journey. I am a late bloomer. In 1998, I was planning to be a stay-at-home mom and raise a family when I got an opportunity to work part-time in a corporate IT department at a federally funded research company. I was there for 16 years of my 27-year career in IT. The job afforded me the work-life balance I needed to raise my kids while my husband traveled, and it allowed me to stay current with technology. I got my first leadership position in 2004 leading a small automated test team. I planned to stay at that company until I retired, suppressing, or denying my ambition. But In 2013, I led the implementation of a Continuous Delivery pipeline and got introduced to DevOps. I fell in love and this unleashed my ambition. When the opportunity to practice DevOps and learn the Cloud, and grow as a leader, became available to me at a different and much larger company I took it. The uncertainty that comes with change was scary and I struggled to adapt at first, I questioned and doubted my decision. But I had strong leaders who gave me time and space to learn, who coached me and championed me. I was at that company for four years and I absorbed everything I could and took opportunities, and risks, to lead and learn how transformation-at-scale works. I learned what I was capable of as a leader and driving change. When I got the opportunity to do it at S&P as a more senior leader I took it. The answer to how I got to where I am is having leaders who invested in me, I think they invested in me because of my grit, my ability to learn and be curious, my ability to collaborate and engage and align others to achieve goals, taking risks and becoming comfortable with uncertainty. What inspired you to go on this journey? What drew you to the tech industry? It isn’t so much of an inspiration but rather a calling. It is a natural inclination of mine to expand my scope, step in, and lead when there’s an opportunity to do so, and take personal risks to foster growth and development. I am drawn to the tech industry because I am a maker at heart and you can make some pretty incredible solutions and change people’s lives with technology. I also love technology because it is rapidly changing. I love change and am comfortable with new environments, challenges, and circumstances. I get to help others adopt technology and get through the change that comes with that adoption. Who do you look up to for inspiration or mentorship? I look to my existing leadership for inspiration and mentorship. If I can’t then I am working for the wrong person. Every leader I have had has shaped me as a leader and left me with a theme, lesson, or point-of-view that sticks with me. There’s a cliché that people don’t leave a job, they leave leaders. That has not been true for me. I have left jobs because I outgrew them, I outgrew them because I had great leaders. What do you think are the most important qualities of successful tech leaders today? The most important qualities are empathy, agility, authenticity, and grit. How do you keep your team motivated despite conflicts and obstacles? Always know and communicate the “why” and where you are going. Be really clear on the mission and vision and do not waiver. Acknowledge that change is challenging, validate feelings, and set an example. This is why I mention empathy and authenticity as important qualities in leadership. Your people need to know you are human and you understand change is hard, and that you know what they are going through. Sharing your personal stories of perseverance and persistence resonates and helps them to see themselves in you. What is expected of you? What are your expectations for your team? I am expected to establish goals and deliver results that benefit the business and create value, and to leave my team and environment better off than when I started. I am expected to drive high performing teams and bring out the best in my people. My team is expected to deliver to the goals and outcomes I establish and to solve problems. What are your current goals? What projects are you currently working on? My goals are to implement a system that accelerates the delivery of value to our customers and create an environment where our technology talent does the best work of their lives and innovates to create a competitive advantage. I am working on a cloud-native architecture leveraging containers, microservices, and a continuous delivery pipeline. What are you the proudest of in your career so far? Seeing some really talented people I led to grow and move into leadership positions and lead other people. What is your favorite part of your job? Working with really smart and talented people that make it fun to come to work. And working with cutting edge technology that challenges us to learn. What has been your greatest challenge from working as a tech leader? Keeping up with technology and skills. It is challenging to find the time to learn new technologies and understand them enough to be respected by engineers and be able to ask the right questions. I’ve been dying to learn Kubernetes and get my hands on the keyboard but it is hard to find the time. What’s the most important risk you took in your career and why? Leaving a job I was comfortable in and at for 16 years to join a fortune 100 company. It was a risk because I left a quasi-government, non-competitive environment and went into a competitive commercial environment of top talent. I had to quickly learn and adapt, especially learn the cloud. I was petrified I would fail and return to my previous employer where I would be told “I told you so” about the commercial world. How do you continue to grow and develop as a tech leader? I am never done learning and I surround myself with people who are smarter than me and go to them for answers. How do you align your team and company with your vision and mission? By being clear about the mission and vision, making it visible and actionable, and then executing on it and showing the results backed up by data. I look for a story to tell that showcases the mission and vision and I tell it over and over again to key stakeholders. What have you learned from your experience so far? The journey is never finished, and you can always grow and learn. Challenge yourself and know what you are capable of. Do you have a memorable story or an anecdote from your experience you’d like to tell? I’d have to write a book to capture them all. One that stands out is I worked with a Product Manager who wanted to deliver features faster and was willing to slow down development for a while to focus on continuous delivery and upskilling his organization. He said to me “you have to slow down to go fast”. I have it on a t-shirt and use it with Product Managers I’m trying to influence. Finally, do you have any advice to aspiring engineers and developers who want to grow in the tech industry? Yes, don’t be an expert. Experts stop asking questions and have all the answers. Be a learner, ask questions, and know that the journey is never finished. Listen, learn then lead. The post Leaders in Tech: Aimee Bechtle appeared first on DevOps Online. View the full article