All Posts By

rromoff

Q & A with Sara Chipps, CPC Director and newest OpenJS Board Member

By Announcement, Blog

Sara Chipps, the newest  OpenJS Foundation board member, took some time to give the OpenJS Foundation some valuable insights into her new role on the board. Sara Chipps is a JavaScript developer based in NYC. She has been working on Software and the Open Source Community since 2001. She is the cofounder of Jewelbots, a company dedicated towards drastically changing the number of girls entering STEM fields through play, and Girl Develop It, a non-profit that has taught over 100,000 adult women how to code. By day she’s the Director of Product, Community at Stack Overflow and works there to empower millions of coders to build and ship.

Q) Why is it important for the CPC to have a voice on the board of directors, in your opinion?

A lot of the work on the CPC is in service of the OpenJS projects. We work to make sure the individual projects have the resources and representation they need. The CPC having a voice on the board of directors means that the projects have a direct line to the people at the highest decision-making levels and that means as an organization we can provide effective governance. 

Q) What do you plan to focus on as a Foundation BoD member?   

I plan to focus on learning and listening from and to both the board and project organizations initially. As a person and a software developer, my focus is always on developer happiness, open ecosystems, representation, and inclusion. I imagine those things will reflect when I bring them to the board and I hope that I can be a positive voice.  

Q) What you hope your impact will be in this role?

I hope to continue the foundation’s work of sustainability in the open source JavaScript community. I hope I can bring the perspective of a long-time community member who cares deeply about representation and the ability to level up in open source development. 

Q) What advice would you offer others wanting to get involved with the Foundation?  

Join us! We have many open meetings throughout the week, you can just show up and listen. You don’t even need to do anything or have an opinion until you are inspired. People do it all the time and it’s great. 

Project News: Electron ships v12

By Blog, Electron, Project Update
Words Electron 12.0.0 is here with confetti surrounding it.

Electron, an impact project at the OpenJS Foundation, recently released an updated version, Electron 12.0.0. This new version includes upgrades to Chromium 89, V8 8.9 and Node.js 14.16. The team also added changes to the remote module, new defaults for contextIsolation, a new webFrameMain API, and general improvements. Full details of the new release can be found on the Electron blog.

Congrats to the Electron team!

Free Introduction to Node.js Online Training Now Available

By Blog, Certification and Training, Node.js, Training

This post also appeared on the Linux Foundation Training blog.

Node.js is the extremely popular open source JavaScript runtime, used by some of the biggest names in technology, including Bloomberg, LinkedIn, Netflix, NASA, and more. Node.js is prized for its speed, lightweight footprint, and ability to easily scale, making it a top choice for microservices architectures. With no sign of Node.js use and uptake slowing, there is a continual need for more individuals with knowledge and skills in using this technology.

For those wanting to start learning Node.js, the path has not always been clear. While there are many free resources and forums available to help, they require individual planning, research and organization which can make it difficult for some to learn these skills. That’s why The Linux Foundation and OpenJS Foundation have released a new, free, online training course, Introduction to Node.js. This course is designed for frontend or backend developers who would like to become more familiar with the fundamentals of Node.js and its most common use cases. Topics covered include how to rapidly build command line tools, mock RESTful JSON APIs and prototype real-time services. You will also discover and use various ecosystem and Node core libraries, and come away understanding common use cases for Node.js.

By immersing yourself in a full-stack development experience, this course helps bring context to Node.js as it relates to the web platform, while providing a pragmatic foundation in building various types of real-world Node.js applications. At the same time, the general principles and key understandings introduced by this course can prepare you for further study towards the OpenJS Node.js Application Developer (JSNAD) and OpenJS Node.js Services Developer (JSNSD) certifications.

Introduction to Node.js was developed by David Mark Clements, Principal Architect, technical author, public speaker and OSS creator specializing in Node.js and browser JavaScript. David has been writing JavaScript since 1996 and has been working with, speaking and writing about Node.js since Node 0.4 (2011), including authoring the first three editions of “Node Cookbook”. He is the author of various open source projects including Pino, the fastest Node.js JSON logger available and 0x, a powerful profiling tool for Node.js. David also is the technical lead and primary author of the JSNAD and JSNSD certification exams, as well as the Node.js Application Development (LFW211) and Node.js Services Development (LFW212) courses. 
Enrollment is now open for Introduction to Node.js. Auditing the course through edX is free for seven weeks, or you can opt for a paid verified certificate of completion, which provides ongoing access.

Tips for submitting a talk to OpenJS World

By AMA, Blog, Event, OpenJS World

Want to find out how to successfully submit a talk to OpenJS World? The OpenJS Foundation’s monthly AMA this time focused on OpenJS World and dug into some of the do’s and don’ts when submitting a talk. The deadline to submit is February 22, 2021. Moderated by members of the OpenJS World Program Committee, the AMA aimed to share insight into submitting talks and successfully presenting at OpenJS World. 

Participants included Rachel Romoff, Joe Sepi, Jory Burson, and Divy Tolia. People were able to ask questions via Twitter and live YouTube chat. Questions ranged from what OpenJS World means to the JavaScript community, to ways to get mentored before presenting an approved talk. Discussion outside of the Q&A focused mostly on the importance of participating in OpenJS World.

The full AMA is available here:

Timestamps

0:00 Brief Introduction

1:29 Introductions

5:40 What is OpenJS World?

10:45 Details about OpenJS World

12:58 What is a Program Committee?

17:00 CFP Process

19:40 How Many Keynotes Are Expected for 2021?

22:22 Can You Submit More than One Talk? 

24:10 Can Committee Members Submit Talks?

25:10 Is the CFP Process Blind?

27:30 Diversity Goals

29:39 Do’s and Don’ts of Submitting a Talk

45:15 Mentorship for First Time Presenters

47:00 Resources for Talks

51:25 Tracks at OpenJS World

55:15 Review Process

57:17 Getting Involved

58:25 Wrap-Up Comments

Ajv Version 7, Big changes and improvements

By Announcement, Blog, Project Update

The following post was written by Evgeny Poberezkin, lead maintainer of Ajv (incubation project of the OpenJS Foundation). 

It’s been over a month since Ajv version 7 was released, and in this time many users have migrated to the new version. Ajv v7 is a complete rewrite that both changed the language to TypeScript and also changed the library design. I’m happy to share that it has been relatively smooth, without any major issues.

What’s new

I’ve written previously about what has changed in version 7, to summarize:

1. Support of the JSON Schema draft 2019-09 – users have been asking specifically for `unevaluatedProperties` keyword, which adds flexibility to the valuation scenarios, even if at a performance cost.

2. More secure code generation in case untrusted schemas are used. Execution of code that might be embedded in untrusted schemas is now prevented by design, on a compiler type system level (and you don’t need to use TypeScript to benefit from it, unless you are defining your own keywords).

3. Standalone validation code generation is now comprehensively supported, for all schemas.

4. Strict mode protecting users from common mistakes when writing JSON Schemas.

That is a big list of improvements that was possible thanks to Mozilla’s MOSS program grant.

Better for community

I’m also excited to share that Ajv v7  has grown contribution interest from its users, with some cases when independent users are interested to collaborate between them on some new features.

There are several reasons for that, I believe:

– the code is better organised and written on a higher level – it is easier to read and to change than before.

– documentation is now better structured with additional sections specifically for contributors – code components and code generation.

I am really looking forward to all the new ideas and features coming from Ajv users.

What’s changed and removed

These improvements came at a cost of a full library redesign, that requires being aware of these changes during migration:

– Importing from your code

– Installation

– Code generation performance

– Validation of JSON Schema formats

– Migrating from JSON Schema draft 4

Below these changes are covered in detail – they were causing migration difficulties to some users.

Importing Ajv from your code

To import Ajv in typescript you can still use default import:

 ```typescript
 import Ajv from "ajv"
 const ajv = new Ajv()
 ``` 

But to import in JavaScript you now need to use `default` property of the exported object:

 ```javascript
 const Ajv = require("ajv").default
 // or const {default: Ajv} = require("ajv")
 const ajv = new Ajv()
 ``` 

And if you use JavaScript modules you need to import Ajv this way:

 ```javascript
 // from .mjs file
 import Ajv from "ajv"
 const ajv = new Ajv.default()
 ``` 

This is a compromise approach that leads to a bit simpler compiled JavaScript code size of Ajv, and, what is more important, allows to export additional things alongside Ajv and does not force dependencies to use `esModuleInterop` setting of TypeScript. Possibly, there is a better way to export Ajv – please share any ideas to this issue.

Ajv installation

Several users, in particular those who use `yarn` rather than `npm`, had issues related to version conflicts between old and new versions. Because Ajv is a dependency of many JavaScript tools, the users can have both version 6 and version 7 installed at the same time.

When version 6 was released 2 years ago there were a lot of version conflicts. Since then npm seems to have improved – it handles multiple versions correctly when performing a clean installation – at least I have not seen any example that shows version conflicts in this scenario. But when performing incremental installations version conflicts still happened to a few users.

This situation should resolve itself as dependencies migrate, and in all cases clean installation resolved the problem.

Code generation performance

Validation code that Ajv v7 generates is at least as efficient as code generated by v6, and in many cases it is faster – version 7 introduced several tree optimisations and other improvements for it. The primary objective to re-design code generation was to improve its security when using untrusted schemas and to make the code more maintainable.

As a side effect, it also led to the reduction of Ajv bundle size.

The downside that may be affecting some users though is that the code generation itself is 4-5 times slower.

For most users it won’t have an impact on the application performance, as schema compilation should only happen once, when the application is started, or when the schema is used for the first time. But there are several scenarios when it can be important:

1. When using schemas in short lived environments when validation is performed only once or few times per compilation – it may include serverless environments, short-lived web pages, etc. In this case you should explore the possibility of using the standalone validation code to compile all your schemas at build time. Ajv v7 improved the stability of generating standalone validation code and it is now supported for all schemas.

2. When a schema is generated dynamically for each validation (or to perform a small number of validations). There is no solution for such scenarios – Ajv (and any other validator that compiles schemas to code) is simply not a good fit for such scenarios, if the performance is critical. The main advantage of schema compilation is that the produced validation code is much faster than it would have been to interpret the schema. But if the schema is dynamic, then there is no benefit to the compilation – a validator that interprets the schema in the process of validation could be a better fit. While it may be 50-100 times slower to validate, it may still be faster than compiling schema to code. You need to run your own benchmarks and decide what is better for your application.

3. When you used Ajv incorrectly and compiled schema for each validation. The correct usage is either to use the same Ajv instance to manage both schemas and compiled validation functions, or to manage (cache) them in your application code. In Ajv v7 this incorrect usage is more likely to be noticeable both because of slower compilation speed and also because Ajv caches the functions using schema itself as a key and not it’s serialised presentation.

To summarize, if you use Ajv correctly, as it is intended, it will be both safer and faster, but if you use(d) it incorrectly it may become slower.

Caching compiled schemas

Ajv compiles schemas to validation code that is very fast, but the compilation itself is costly, so it is important to reuse compiled validation functions.

There are 2 possible approaches:

1. Compile schemas either at start time or on demand, lazily, and manage how validation functions are re-used in your application code:

 ```javascript
 const schema = require("mu_schema.json")
 const validate = ajv.compile(schema)
 // ...
 // in this case schema compilation happens
 // when app is started, before any request is processed
 async function processRequest(req) {
   if (!validate(req.body)) throw Error("bad request")
   // ...
 }
 ``` 

It is important that `ajv.compile` is used outside of any API endpoints, as otherwise ajv may recompile the schema every time it is used (depending whether you pass the same schema reference or not).

2. Add all schemas to Ajv instance, using it as a cache of compiled validation functions, later retrieve them using either the schema `$id` attribute from the schema or the key passed to `addSchema` method.

File `./my_schema.json`:

 ```json
 {
   "$id": "https://example.com/schemas/my_schema",
   "type": "object",
   "properties": {
     "foo": {
       "type": "string"
     }
   }
 }
 ``` 

Code:

 ```javascript
 const schema = require("./my_schema.json")
 ajv.addSchema(schema, "my_schema")
 // ...
 // schema compilation happens on demand
 // but only the first time the schema is used
 async function processRequest(req) {
   const validate = ajv.getSchema("https://example.com/schemas/my_schema")
   // or
   // const validate = ajv.getSchema("my_schema")
   if (!validate(req.body)) throw Error("bad request")
   // ...
 }
 ``` 

If you are passing exactly the same (and not just deeply equal) schema object to ajv, ajv would use a cached validation function anyway, using schema object reference as a key.

But if you pass the new instance of the schema, even if the contents of the object is deeply equal, ajv would compile it again. In version 6 Ajv used a serialized schema as a cache key, and it partially protected from the incorrect usage of compiled validation functions, but it had both performance and memory costs. Some users had this problem (https://github.com/ajv-validator/ajv/issues/1413) when migrating to version 7.

Validation of JSON Schema formats

Format validation has always been a difficult area, as it is not possible to find an optimal balance between validation performance, correctness and security – these objectives are contradictory, and, depending on your application, you would need a different approach to validate the same format.

JSON Schema specification evolved to the point of declaring format validation as an optional, opt-in behaviour, and Ajv v7 made the same choice – formats are now released as a separate package ajv-formats.

Unlike JSON Schema specifies, Ajv does not just quietly ignore formats – it would have been error-prone – you have to explicitly configure it for the desired behaviour (or do not use formats in the schemas).

You have several options:

1. Fully disable format validation with the option `validateFormats: false`. In this case, even if you use formats in the schema, they will be ignored.

2. Define the list of formats that you want to be ignored by passing `true` values for some formats in `formats` option:

 ```javascript
 new Ajv({formats: {email: true}})
 ``` 

The configuration above would allow and ignore `email` format in your schemas, but would still throw an exception if any other format is used. This approach is more performant than passing regular expressions `/.*/` or function `() => true` because they would have to be executed, and in case of `true` no validation code is generated when this format is used.

3. Use ajv-formats package – it includes all formats previously shipped as part of Ajv, some of the formats have two options – more performant and more correct (`fast` and `full` – see the docs to ajv-formats).

4. Define your own functions (or use some a 3rd party library) to validate formats that suit your application – you can pass functions to ajv for each format you use and you can even use asynchronous validation if, for example, you want to validate the existence and/or configuration of domain name as part of `email` or `hostname` validation.

The last approach to validate formats – defining your own functions or using a library – is strongly recommended as it allows you to achieve the right balance between validation security, speed and correctness that fits your application.

JSON Schema draft 4 should be used with version 6

Draft 4 of the JSON Schema is the first version that Ajv supported, and since then there were several important changes in the specification that made supporting multiple versions of JSON Schema in the same code unnecessarily complex.

JSON Schema draft 2019-09 has introduced further complexity, so the support for draft 4 was removed.

You can either continue using JSON Schema draft 4 with Ajv version 6, or if you want to have all the advantages of using Ajv version 7 you need to migrate your schemas – it is very simple with ajv-cli command line utility.

What is next

Thanks for continuing sponsorship from Mozilla, many new improvements are coming in Ajv – the new major version 8 will be released in a few months.

The most exciting new feature that was just released in version 7.1.0 is the support for the alternative specification for JSON validation – JSON Type Definition – it was approved as RFC8927 in November 2020. This is a much simpler and more restrictive standard than JSON Schema, and it enforces better data design for JSON APIs, prevents user mistakes and maps well to type systems of all major languages. See Choosing schema language section in Ajv readme for a detailed comparison.

Ajv version 8 will bring many additional features and stability improvements and also will support the changes in the most recent JSON Schema draft 2020-12.

The second exciting change that is coming soon is a new website for Ajv – to make the documentation more accessible and discoverable, and to make contributions easier.

Thanks a lot for supporting Ajv!

Pointer Events Polyfill (PEP) enters emeritus status at the OpenJS Foundation

By Announcement, Blog, Project Update

The Pointer Events Polyfill (PEP), originally part of the jQuery project family, is fully deprecating after 8 years. Current project maintainer, Patrick H. Lauke (who also chairs the W3C Pointer Events Working Group) worked with contributors to push the final stable and secure release to npm in December 2020.

The OpenJS Foundation is honored to have been the neutral home for PEP and is grateful for those who have kept the project up and running over the years. 

PEP History and Milestones

PEP is an early example of open source experimentation and developer adoption driving web standards development.

Originally part of Google’s Polymer Project, PEP gave developers an early opportunity to experiment with the ideas introduced by Microsoft’s W3C member submission for a Pointer Events specification – providing websites and application with a more cohesive way to handle DOM events from a variety of input devices – such as touch, mouse, and stylus – rather than having to handle use separate event models (mouse events and touch events) in parallel.

PEP came to join the jQuery Foundation on December 17, 2014 in order to ensure that the polyfill was maintained in a sustainable and browser-agnostic way, and that tool developers could use it as a path to implementation in all browsers.

Active development of PEP continued through the initial standardisation process, which also saw jQuery members directly involved in the W3C working group, and that led to the stable Pointer Events 1 specification in 2015. PEP played an important role in the Pointer Events standardisation process, allowing an early test-bed for both spec implementers and developers in the wider web community to familiarise themselves with the new standard.

PEP eventually came to the OpenJS Foundation by way of the JS Foundation, the successor of the jQuery Foundation.

The Pointer Events specification has since grown and evolved – with Pointer Events Level 2 reaching recommendation status in April 2019, and current development on Pointer Events Level 3. Many of the functionalities introduced in these newer versions were, unfortunately, too fundamental to be easily “patchable” with a polyfill, which gradually slowed development on PEP – focusing mostly on security patches and bug fixes.

However, while PEP may now be deprecated, the future of Pointer Events themselves is looking good, with the native API now supported in the majority of current browsers (see caniuse.com/pointer). For this reason, unless a project specifically targets older browser versions, we would strongly encourage developers to stop including PEP and to instead rely solely on native Pointer Events.

Thank yous

Open source projects don’t run, or archive, themselves. There are people behind the GitHub repos that ensure things run smoothly. We’d like to thank all the contributors of the project (including Daniel Freedman from the Polymer Project, Scott González who represented the jQuery Foundation on the W3C working group and led the bulk of the development during that time, and Patrick H. Lauke who coordinated the final release) for maintaining PEP over the years and for giving back to the open source community. 

Project News: WebdriverIO v7 Release

By Announcement, Blog, Project Update, WebdriverIO

Today, the WebdriverIO team has released v7! Webdriver is a hosted project at the OpenJS Foundation. To further grow the project, this new release brings with it an almost complete rewrite to the code base. With the v5 update, the project moved from a multi-repository setup to a mono-repo. This time, the rewrite of the code base is just as important and impactful but comes with almost no implications for the end user.

This major update will have the biggest impact on TypeScript users as types in all places have been updated and the way they are distributed has also been changed. As part of the rewrite, WebDriver has upgraded to Cucumber v7, which also moved its codebase to TypeScript. 

Hear from Christian Bromann, software engineer and core contributor of the Webdriver Project, as he explains some key updates:

Several updates include:

TypeScript Rewrite

Webdriver has rewritten the complete code base and almost touched all files to add type safety and to fix a lot of bugs on the way. This was a true community effort and would have taken much longer if they didn’t have so many people helping with code contributions. Bog thanks to the community for that ❤️! Before, WebdriverIO auto-generated all type definitions, which caused the creation of a lot of duplicate types and inconsistency. With this overhaul, all types are directly taken from the code itself and centralised in a single new helper package called @wdio/types. If you have been using TypeScript, you will now have much better type support for various commands and the configuration file.

Improved Google Lighthouse Integration

Since v6 WebdriverIO can run on the WebDriver protocol for true cross browser automation, but also automate specific browsers using browser APIs such as Chrome DevTools. This allows for interesting integrations into tools that allow broader testing capabilities such as Google Lighthouse. With the `@wdio/devtools-service`, WebdriverIO users were able to access these capabilities using Google Lighthouse to run performance tests. In this release we’ve also updated Google Lighthouse to the latest version to enable new performance metrics such as Cumulative Layout Shifts or First Input Delay.

New PWA Check Command

In addition,  Webdriver has deepened its integration to the tool and added audits for capturing the quality of your progressive web apps (PWA). These applications are built with modern web APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase. 

Webdriver will continue to add more integrations into tools like Google Lighthouse to provide more testing capabilities, e.g. accessibility, best practices and SEO.

New Docs

As you might already have seen, Webdriver has updated their docs to give this new release a brand new face. They have upgraded their Docusaurus setup to v2 and gave the whole design a new touch. Big shout out to Anton Meier for helping out and making the robot on the front page so lively.

Drop Node v10 Support

Webdriver has dropped support for Node v10, which was moved into a maintenance LTS phase by the Node.js team in May 2020. While this version still receives important security updates until April 2021, it is recommended to update your Node.js version to v14 or higher.

https://webdriver.io/blog/2021/02/09/webdriverio-v7-released/

If you have any questions don’t hesitate to start a conversation on the discussions page or join our growing support chat that has already reached 6.7k active members.

OpenJS Foundation Welcomes Bloomberg as Newest Member

By Blog

 Deep investment in JavaScript, one of the largest JavaScript codebases in the world, 6,000+ software engineers around the globe

SAN FRANCISCO – February 3, 2021 – The OpenJS Foundation, providing vendor-neutral support for sustained growth within the open source JavaScript community, is announcing today that Bloomberg has joined as a new member. The OpenJS Foundation is home for critical open source JavaScript projects including Appium, Dojo, jQuery, Node.js, webpack, and 30 more.

“Bloomberg is a long-time proponent of open source, and the benefits for their customers around the globe managing markets and financial data is immense. Their engineering innovation and commitment is widely respected,” said Robin Ginn, executive director, OpenJS Foundation. “We are excited to welcome Bloomberg as an OpenJS Foundation member. We look forward to their continued leadership and technical expertise in helping to contribute to JavaScript and Node.js development moving forward.”

As a global leader in business and financial information, data, news and analytics, Bloomberg has a long-term investment in JavaScript, through contributions to core projects and ongoing participation in standards, notably for the JavaScript language itself. Bloomberg has more than 10,000 frontend apps and tens of millions of lines of JavaScript code that cover both consumer web and the Bloomberg Terminal, the desktop application that is core to Bloomberg’s business. Furthermore, more than 2,000 software engineers are writing JavaScript at Bloomberg, another testament to the company’s innovation and commitment to the programming language and the open source community.

“Bloomberg is excited to join the OpenJS Foundation. As a tech company, we have been depending on JavaScript for many years across a wide variety of distributed systems infrastructure and client-facing applications,” said Rob Palmer, JavaScript Infrastructure & Tooling Lead at Bloomberg and co-chair of TC39. “We are dedicated to strengthening the health of the JavaScript ecosystem, and joining the OpenJS Foundation is a natural step for furthering that goal.”

“Bloomberg’s commitment to open source is important to the success of the ecosystem,” said Todd Moore, OpenJS Foundation Board Chairperson. “By creating a center of gravity for the open source JavaScript ecosystem, the OpenJS Foundation’s mission is to drive broad adoption and ongoing development of key JavaScript solutions and related technologies. We are thrilled to have Bloomberg join us in this mission as a member of the Foundation and look forward to continued collaboration.”

“It’s my pleasure to welcome Bloomberg as an OpenJS Foundation member,” said Joe Sepi, OpenJS Foundation Cross Project Council Chair. “As an end-user of many JavaScript and OpenJS project technologies, as well as an active participant in the open source community, Bloomberg is a natural fit as a member of the Foundation.”

Hundreds of software engineers across Bloomberg’s global engineering workforce have provided code, documentation, tests, or other improvements to open source projects. In areas relevant to Bloomberg’s infrastructure needs, Bloomberg engineers have become project leaders and committers. Bloomberg is also an Associate Member of ECMA International. Learn more about Bloomberg’s open source activities at www.TechAtBloomberg.com.

OpenJS Resources

To learn more about participate in the evolution of OpenJS: https://openjsf.org/about/join/

About OpenJS Foundation 

The OpenJS Foundation (https://openjsf.org/) is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 35 open source JavaScript projects including Appium, Dojo, jQuery, Node.js, and webpack and is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

About Bloomberg

Bloomberg, the global business and financial information and news leader, gives influential decision makers a critical edge by connecting them to a dynamic network of information, people and ideas. The company’s strength – delivering data, news and analytics through innovative technology, quickly and accurately – is at the core of the Bloomberg Terminal. Bloomberg’s enterprise solutions build on the company’s core strength: leveraging technology to allow customers to access, integrate, distribute and manage data and information across organizations more efficiently and effectively. For more information, visit www.bloomberg.com or request a demo.

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

# # #

JavaScriptLandia News: InfoQ Interview

By Blog, JavaScriptLandia

In December of 2020, the OpenJS Foundation officially announced JavaScriptLandia, an individual supporter program and a place where all JavaScript fans, no matter your flavor or technology preference, can creatively express support for the JavaScript ecosystem and OpenJS communities. The program is $25 USD annually.

Sara Chipps, the initiative champion sat down with Guy Nesher, with InfoQ, to share details about this brand new program.

Interview highlights:

  • The OpenJS Foundation is a vendor-neutral organization that supports open-source projects
  • Contributing to open-source projects can mean more than just writing code
  • There are more challenges to open source contribution than is often discussed
  • JavaScriptLandia is a new initiative that encourages individuals to participate in the OpenJS Foundation

Read the full interview here: https://www.infoq.com/articles/javascriptlandia-and-open-source/

Writing and submitting your OpenJS World 2021 talk

By Blog, Uncategorized

We are thrilled with how OpenJS World 2021 is coming together! The global event is happening virtually on June 9, 2021 and the call for speaking sessions is OPEN! You can submit your OpenJS World talk here: https://cfp.openjsworld.com/

Quality content is a keystone priority for the OpenJS World program committee and we want to help people get a leg up in submitting thoughtful and relevant content. 

While it’s never our intention to provide strict directives on how to prepare your speaking submission, we do have some general guidelines serves to help you prepare the best submission possible. 

As you get started, here are three things that you should consider before submitting your proposal:

  • What are you hoping to get from your presentation?
  • What do you expect the audience to gain from your presentation?
  • How will your presentation help better the ecosystem?

There are plenty of ways to give a presentation about projects and technologies without focusing on company-specific efforts. Remember the things to consider that we mentioned above when writing your proposal and think of ways to make it interesting for attendees while still letting you share your experiences, educate the community about an issue, or generate interest in a project.

First Time Submitting? Welcome!

OpenJS World is a way to get to know the community and share your ideas and the work that you are doing and we strongly encourage first-time speakers to submit talks. In the instance that you aren’t sure about your abstract, please check out the #cfp-mentorship channel in the OpenJS Foundation Slack Channel.

You can join the slack channel here: https://communityinviter.com/apps/js-foundation/join-openjs-foundation-on-slack

OpenJS AMA for Talk Submissions

In addition to the Slack channel, we are hosting an OpenJS AMA all around submitting great talks to OpenJS World. You can submit your questions here: https://forms.gle/fAjVWYEiNveo6BqS7 

Additionally, tune in live on Feb 3 at 9 am PT: https://youtube.com/channel/UCjxM1d3fv_mSEBsyp5MTFrg/live

Ready to submit? Follow this link: https://cfp.openjsworld.com/