What does this mean for the classic Jenkins UI? What does this mean for my plugins? What technologies are currently in use? Where can I find the source code? other job types in the future. The intention is that as Blue Ocean matures there will be less and less reasons for users to go back to the existing UI. For example, in the first version we will mainly be targeting Pipeline jobs. You might be able to see your existing non-pipeline jobs in Blue Ocean but it might not be possible to configure them from the new UI for some time. This means users will have to jump back to the classic UI for configuration of non-pipeline jobs. There are likely going to be more examples of this and that’s why the classic UI will still be important in the long term. Extensibility is a pretty core concept to Jenkins, so being able to extend the Blue Ocean UI is important. Based on some research, we worked out a way to allow  <ExtensionPoint name=..>  to be used in the markup of Blue Ocean, leaving places for plugins to contribute to the UI (plugins can have their own Blue Ocean extension points, just like they do today in Jenkins). Blue Ocean itself (as it is so far) is implemented using these extension points. Extensions are delivered by plugins, as normal, only if they wish to contribute to the Blue Ocean experience they will have some additional javascript that provides extensions. Blue Ocean is built as a collection of Jenkins plugins itself. There is one key difference, however. It provides both its own endpoint for http requests and delivers up html/javascript via a different path, without the existing Jenkins UI markup/scripts. React.js and ES6 are used to deliver the javascript components of Blue Ocean. Inspired by this excellent open source project (react-plugins) an <ExtensionPoint>pattern was established, that allows extensions to come from any Jenkins plugin (only with Javascript) and should they fail to load, have failures isolated. The source code can be found on Github: • Blue Ocean • Jenkins Design Language 108