SCION@5.0.0 Release Announcement

Table of Contents

• Introduction

• SCION DevTools Overview

  • Online documentation
  • CLI tool
  • Graphical debugging
  • Visual Studio Code Integrations

• Creating a sustainable future for SCION

  • License Evolution
  • Funding Models
  • Concerns Around Contributions
• Intention to migrate from Github to Gitlab
• Next steps

Disclaimer: If you are a new to programming with SCXML or SCION, please check out the tutorials, which provide a gentle introduction to these topics. This blog post is written with an audience of existing users in mind, and is somewhat advanced.

Introduction

tl;dr This release of SCION includes new libraries which enable tools for advanced debugging, as well as the development of better online documentation (API docs, examples, and tutorials).

When SCION started, it was basically a library implementing an interpreter/compiler for the SCXML standard in JavaScript, for node.js and the browser.

With the release of SCION@5.0.0, the scope of the project has expanded to be a complete system for developing SCXML in JavaScript. SCION is now a software distribution which includes the following core libraries:

• interpreter (core)
• compiler (scxml)
• visualizer (schviz)
• linter (scharpie)

These core libraries enable advanced debugging, as well as the development of better online documentation (API docs, examples, and tutorials). This is facilitated through the following new developer tools.

SCION DevTools Overview

Online documentation

There has been a dearth of learning resources for SCXML. Online documention (API docs, examples, and tutorials) is essential to enabling an open software ecosystem to flourish, and SCION attempts to provide libraries to facilitate the creation of this documentation.

To start this off, you can find some tutorials written by my friend @thure here. More examples will be forthcoming, and I hope that opening these libraries to the community will allow people to develop and contribute their own online tutorials.

CLI tool

The SCION command-line tool allows you to visualize, lint, compile and interactively run SCXML files. You can also monitor SCXML sessions using the new monitor tool, described in the section below.

You can install the CLI tool with npm install -g @scion-scxml/cli, and run it with command scion.

You can see an example of this in the video below:

Graphical debugging

The new sourcemap-plugin module adds support for generating source maps to the SCION compiler. This enables a visual JavaScript debugger, like Chrome DevTools or VSCode, to read the sourcemap, set breakpoints in the SCXML source file, and inspect the SCXML datamodel. This works in Node.js and the Browser.

Additionally, SCION includes a new monitor utility, which provides a user interface to view a log of events processed by the state machine, and display debugging information, such as the datamodel, inner event queue, and session hierarchy, to visualize how the state changes over time.

Here is a video of these features in action:

Visual Studio Code Integrations

SCION integrates with the Visual Studio Code (VSCode) IDE in the following ways:

• linting, using VSCode’s built-in support for eslint, and the @scion-scxml/eslint-plugin package for linting SCXML
• visualization, using the new @scion-scxml/vscode-preview VSCode extension
• graphical debugging, using VSCode’s built-in JavaScript debugger, and the new SCION sourcemap-plugin mentioned above.

You can see an example of this in the following video:

Creating a sustainable future for SCION

I am seeking an economic engine to sustain and fund the ongoing development of SCION.

I started SCION in 2011 as a research project toward the completion of my master’s thesis. When I created SCION, I was a student living in Kingston, Ontario, where cost of living was more affordable.

In the USA, money is like oxygen — you need it to live. I make a living through consulting, typically building custom business applications for enterprises. SCION has had a lot to do with my success. Every project I have worked on has come through a direct referral. People have discovered SCION, and then sometimes years later, they remember me and reach out about a job opportunity. The indirect economic benefits of maintaining an open source project are real and significant.

Still, there are problems with this model. While consulting, I bill by the hour, and every minute I spend working on a client project is a minute I am not able to work on SCION. Likewise, every minute I spend working on SCION is a billable hour I am missing. This is a consequence of working on a purely voluntary basis.

Another problem is that some consulting contracts make it difficult to work on outside OSS projects, and then, it really is a choice between consulting or working on SCION.

I continue to work on SCION because I enjoy it. It’s a labor of love. I like thinking about how to create a more perfect, complete implementation of the SCXML standard, which fits more developer use cases. I love putting it into the hands of developers and seeing what they build. Even so, the current model is not one which is sustainable, and I am therefore seeking a different model to sustainably fund SCION.

License Evolution

tl;dr the SCION license policy is as follows:

• the core engine will remain Apache-2.0 (e.g., the scxml and core modules)
• if the module is forked from an existing project, then that module will have the same license as the project from which it was forked (e.g. @scion-scxml/eslint-plugin)
• the new development tools will be LicenseZero Parity 3.0 (e.g. the schviz module)
• finally, SCXML tutorials and examples will be released as Apache-2.0

Here is a complete list of all modules and their associated licenses at the time of this writing (note that all of the package names are prefixed with the @scion-scxml/ organization name):

I have thought a lot about this licensing model, and wanted to share my thoughts on how I arrived here.

Funding Models

There are many different ways to make money from open source software.

One way is through donations. I created a project on OpenCollective in June, and so far have received $1,150 in donations from two backers. I am extremely grateful for this support, and plan to invest this money back into the project. But donations are rarely a business model for sustainable development. Typically, only the most popular open source software projects can sustain development in this way.

Another approach is through consulting for companies that do work related to SCION. Some companies have reached out for support, but the opportunity to do paid consulting work on SCION has never succeeded. I think that sometimes this is because the company is very large, and they have their own internal team of engineers, and would rather do the work entirely in-house. Or the company may be very small, and doesn’t have the resources to pay for a consultant. It could also be because I spend most of my time talking to engineers within a company, who do not themselves have purchasing power or the ability to execute contracts.

At the same time, some companies have adopted SCION and are using it successfully to run their applications. They have even made significant code contributions back to the project. I am grateful for these contributions. But these contributions have also created more work for me, as I need to test and maintain them when I add additional features to SCION going forward. Thus, they do not solve the problem of finding a funding model to sustain ongoing development.

A third approach to sustainable funding is through “dual licensing”. This entails choosing an open source license that compels businesses to pay for a commercial license if they are using the software to develop closed-source applications. This is the model that I have chosen for the developer tools in the latest version of SCION, as this approach feels the most fair to me. If you are a $250-million corporation, and you are using SCION to develop closed applications which bring in a modicum of revenue, it is reasonable to request a few dollars to help pay for maintenance of that software infrastructure.

The challenge has been figuring how to ask large enterprises to pay for a license, without alienating the community of open source software developers, of which I consider myself a part.

I have decided to license the new developer tools under the LicenseZero Parity license, version 3.0. Parity is a public software license which is similar to the GNU Public License (GPL), in that if you use it to develop new software, the license says that you have to open source that code, or purchase a private license. I like this license because it is short, simple, expansive, and fair. Also, LicenseZero makes it convenient to purchase a private license through its command-line tool, or on its website. You can find more information about the LicenseZero Parity License here.

I call this approach license “evolution”, rather than “revolution”, because the parts of the project that have been licensed as Apache-2.0 will continue to be published under the same license. If you are upgrading an existing application to the latest versions of SCION and SCION-CORE, you should be able to do so without needing to worry about the Parity license. Only the new SCION DevTools modules will be published under Parity. The new SCION DevTools are not necessary to build applications based on SCION, but I believe they will help developers a great deal.

Concerns Around Contributions

My main concern is about how this will impact SCION’s ability to build a community. For example, consider this tweet by @mikeal:

With dual licensing you either can't take external contributions or you have to require they sign over the IP.

It makes the original intention of Free Software, building a community, effectively impossible.

It's just freemium proprietary software at that point.

— Mikeal Rogers (@mikeal) August 22, 2018

It’s true that contributors to SCION will now need to sign a Contributor License Agreement where they assign their copyright to Jacobean Research and Development. Contributions to SCION have historically not required users to assign their copyright to the project. I am concerned that this will create a barrier for new contributors.

If you want to contribute to SCION, and you have concerns about licensing, please reach out to me on Gitter, or at jake@jacobeanrnd.com, or leave a comment on this website. I sincerely look forward to having these conversations.

Intention to migrate from Github to Gitlab

Last, I wanted to mention my intention to migrate from Github to Gitlab for hosting the SCION source code. Source code will be made available on Gitlab at a new organization SCION-SCXML.

I intend to do this to protest Microsoft’s (who recently purchased Github) contract with United States Immigration and Customs Enforcement (ICE). I signed a petition to this effect, and I have thought a lot about this in the months since.

On the one hand, I am not opposed to using Microsoft’s open source technologies. I use a lot of it in SCION, for example integrating with the MS Botbuilder framework and VSCode IDE. Also, I don’t have any illusion that my action, as an individual developer, will have any effect on Microsoft’s decision-making. It’s only when it looks like the cost to Microsoft outweighs the benefit that any action will be taken. And Microsoft does a lot of business with the US government, so this will likely require a sea change among developers before they start to take notice.

On the other hand, software is speech, and I feel that, as a developer born in the US, I have a moral and ethical responsibility to use my voice to protest what I see as abuses committed by my government. Separating infant children from their parents for misdemeanor crimes, and detaining them indefinitely in cages, potentially causing permanent psychological trauma, is an abuse of power.

Github is a de facto standard platform for open source software development. Moving SCION to Gitlab will create some friction for SCION’s users and contributors, and violate the principle of least surprise for new users. Normally, that is the opposite of what is desirable for an open source project, but in this case, it is the point. I want users and developers to momentarily consider the relationship between Microsoft and ICE, because the situation with ICE separating child immigrants from their parents and detaining them indefinitely is not normal, or acceptable, or business as usual. Anything that I can do to draw attention to this, and prevent it from becoming normalized and accepted, must be strongly considered.

Fortunately, this transition is facilitated by the fact that Gitlab is an excellent and complete product. It does pretty much everything that Github does and more, and the friction caused by migrating should be minimal.

Next steps

So, that’s it. Lots of new features, some changes, hopefully all for the best.

I will be publishing more examples, documentation, and tutorials over the coming weeks. If you want to receive updates, please sign up for the mailing list below, or :

Thanks, and I look forward to receiving your feedback.