Amazon Sumerian
postmortem

# 1
Failure to recognize
a new product category

AWS is composed of cloud-based, managed software services that can be broadly summarized as “business solutions.” Sumerian, however, is first and foremost a creative tool. To instead describe it as a “business solution” is to deny its raison d’être. Sumerian has far more in common with Adobe’s Photoshop than AWS tools such as DynamoDB or SageMaker.

I intentionally use Photoshop for comparison here, rather than other scene authoring tools like Unity or Unreal, to drive home the notion that the point-and-click “creative use” of Sumerian is its primary use. That Sumerian scenes may also be authored algorithmically by a proficient coder through scripting alone is somewhat incidental; does not lessen its inherent pursuit of facilitating creative use. Our ideal user is at least partially an artist. To misunderstand that is to fundamentally misunderstand the current culture of 3D scene authoring. Historically, AWS does not support creative tools and therefore was ill prepared to nurture Sumerian. This is elaborated on in Observation #4: Failure to properly identify “users” below.

Hamstringing creative employees

AWS does not traditionally aim to employ particularly “right-brained” people. Like good engineers, good artists never stop educating themselves. Each week is a scheduling battle between expanding one’s education and executing based on it. Each hour that a company spends forcing a “creative” AWS employee to cram for and partake in an internal engineering quiz is an irreparable disruption to the task they are being paid for: to be a creative mind for the good of Amazon. It is roughly akin to forcing all other AWS employees to study for and pass a quiz about Josef Albers’ foundational color theory and its application to modern high pixel density / high dynamic range interfaces. Or to answer multiple choice questions about our AWS response to Google’s “Material Design” initiative. Or compare and contrast skeuomorphism to the developing 2020 trend of “neumorphism.” (I say “roughly akin” because these are not direct comparisons of course—we don’t have other creative products within AWS to be quizzed on.) This argument dovetails with Observation #5: Misallocation of efforts below.

Qualitative marketing

Just as potential purchasers of databases must quantitatively assess products by comparing performance metrics, potential purchasers of creative tools must qualitatively assess the creative output of tools like Sumerian. New customers often do not know what a tool is truly capable of. It ought to have been our job to show them. (I make this claim as someone who has successfully employed this strategy many times; as a co-creator of multiple “Chrome Experiments” for Google, creator of Autocompose for Yahoo Mail, etc.)

Showcasing brilliant and beautiful uses of Sumerian ought to have been a top marketing priority, and implies the necessity of forming a small team dedicated exclusively to producing such output. (Tasking a team both with servicing customers and creating / producing showpieces ensures the latter will never satisfactorily materialize.) The endeavor to reach the correct market segment is furthered explored in Observation #6: Chasing the wrong customers below.

Engineers AND artists

In the above I do not intend to segregate artists and engineers, but to use these one-dimensional stereotypes to illustrate the argument. In reality these categories are not mutually exclusive and it’s only a sad artifact of lazy language that we don’t have better widespread expressions for these sentiments. Indeed the brightest engineers I have ever met had the mindset of artists and the most brilliant artists I’ve ever encountered had the clarity of engineers.

Folks who are more strongly “left-brain thinkers” may view learning an AWS service as absorbing technical facts—memorizing instructions—and not comprehend that learning a service like Sumerian is less about configurations and more about expression. Creativity is more akin to slowly training a neural network to operate with patterns that may not be easily distillable into logical rules—and may even on occasion be contradictory. In fact, this might illustrate the core difference between left-brain and right-brain thinking.

Unfortunately for Sumerian, the creative aspect of its existence did not appear to resonate within the AWS organization. Operating in the wrong context can be fatal to a product and I believe the operating context of “business tool” was a contributor to Sumerian’s eventual sunset.

# 2
The embrace of,

rather than replacement of,

the Neo rendering engine

Sumerian itself is not a 3D engine. (I’ve noticed enough confusion over this in regular conversation that it bears repeating.) Sumerian is not a 3D engine. It is a Web-based, 3D scene authoring tool that happens to use a 3D engine. That engine is named “Neo.” (Similarly, Sumerian is not a physics engine. It happens to use a physics engine—two, actually. Initially Sumerian used the Cannon.js physics engine and then later added an option to use the PhysX physics engine instead.) The Neo 3D engine is a surviving legacy piece of the original Goo Technologies suite that evolved into Sumerian after Amazon’s acquisition of Goo. Neo is not Sumerian. Sumerian is more than its use of Neo.

As a custodian of Sumerian I see Neo as being in direct competition with other JavaScript 3D rendering engines, such as Three.js or Babylon.js; they are all competing for the prize of being valuable enough for us to desire their use in Sumerian. In every imaginable metric—other than torpid inertia—Neo comes in an infinitely distant last place. 

Open-source alternatives

Three and Babylon have the advantage of being popular open-source engines with a community of enthusiastic users and contributors. Because so many users are actively poking at and building upon these engines, they regularly receive more stress testing and patches than any one paid service team could manifest—including our own team of talented engineers. The latest techniques in 3D rendering are expediently incorporated into these engines, while similar support in Neo has lagged significantly or remains incomplete to this day. Some recent examples of this include support for GL Transmission Format (glTF), glB packaging, physically-based rendering (PBR), Draco compression, Basis textures, global use of quaternions for rotation [Are you kidding me?], and more. 

Both Three and Babylon boast a roster of high profile uses which include just about any Web-based 3D project of interest created since the standardization of the HTML5 Canvas element. (This even includes whole other 3D scene composition frameworks such as Mozilla’s A-Frame, which itself is powered by Three.) Three.js is further buoyed by a wealth of interactive examples, source code, and API documentation available on, or linked from, its website. These features greatly reduce the barrier to entry for a newcomer.

Closed is costly

Meanwhile, any developer use of Neo is gated behind AWS’s walled-garden and its source code is entirely unpublished. This ensures that outside of the few published Sumerian end-user experiences, no consumer of 3D experiences has even unknowingly interacted with the Neo engine. Documentation for Neo’s API is scant in comparison to Three or Babylon and intentionally keeps users at arms’ length from the actual internal workings. This ensures that no useful patches for Neo can be created outside of Amazon’s labor hours. We are therefore limited to equal or less than what the company has paid for.

The Neo engine is a negative asset on Sumerian’s balance sheet. It ought to have been replaced rather than embraced. The replacement of Sumerian’s third-party physics engine with another third-party physics engine illustrates that Sumerian is more than any one of its components—and that Sumerian can win by embracing third-party, open-source components. Continuing to service Neo has yielded further consequences which are described below in Observation #5: Misallocation of labor efforts.

The above issues with Neo were first raised (by folks outside of the Sumerian product team) in early 2019, and then formalized in the Sumerian+Three slide deck in June 2019, which attempted to use humor (in the form of the cartoon cast of Space Ghost) to sidestep defensiveness while driving the main points home. It had no effect.

# 3
Confusion over which features 

were Sumerian’s selling points

As discussed above in Observation #2, Sumerian’s 3D Web-based rendering engine itself is not a unique feature. The combination of a Web-based rendering engine and Web-based scene editor interface is also not unique. Just as the Neo engine powers the Sumerian scene editor, Three.js powers the Three.js scene editor and Babylon.js powers the Bablylon.js scene editor. (And those scene editors have the benefit of being both free to use and open-source.) If being a Web-based editor powered by a Web-based 3D engine is not a unique feature to Sumerian, what, then are Sumerian’s distinguishing features? What features justify Sumerian’s existence in the marketplace?

Tap-to-publish

Sumerian’s most distinguishing feature is its “Publish” button. With just one click a user’s Sumerian scene goes live to the world, backed by AWS’ legendary redundancy and uptime, accessible to anyone through a URL— something that can be easily copied, pasted, texted, emailed, tweeted, posted, and QR-coded. The moment this feature was programmed into place, Sumerian became a tool for “Creating the world’s most sharable Extended Reality experiences.” This ought to have been the marketing line and guiding principle of Sumerian. (See also Observation #6: Chasing the wrong customers.)

The ability to publish is not just a boon for distributing the production version of a project, it is a game changer for iterative development. Sumerian is platform agnostic; one 3D scene can be made to render on desktops, phones, tablets, and XR headsets—all of various operating systems. Working with native assets, such as scenes created in Unity or Unreal, requires compiling an application and then loading it to each individual device for testing. This is incredibly painful for iterative development.

As an example, if you as an Interface Designer have decided to make one single interface tweak—say, change the background blur radius of a semi-transparent UI element for an augmented reality experience—this must be tested by running it on an actual device in a real-world environment (not merely simulated) in order to see if your adjustment of a single floating point value has translated into a UI that is either now more or now less legible during actual use.

Let’s say you’re composing your scene in Unity. To test this altered blur radius value you hit ⌘S to save your single edit in Visual Studio Code, then switch to the Unity Editor, hit ⌘B to build, and wait for Unity’s build process to complete. After several seconds of nothing happening you realize the build command did not execute because Unity’s interface silently froze while it was pre-compiling the edits just saved in Visual Studio; a “benefit” of Unity’s embrace of Visual Studio. So you hit ⌘B again, and wait for the build to complete—and also for the build’s success to trigger Unity’s opening of a pre-populated iOS project in Xcode. Then you wait for Xcode to build a new iOS app. You’re no slouch, so while waiting for Xcode’s build to complete you unlock your connected iOS device so that once the build does complete, Xcode can finish its publish task by loading the freshly baked binary onto the phone.

Sadly, by the time the build completes the device has relocked, causing the final “push” step of Xcode’s build process to fail. So you must manually trigger the Xcode build again. Thankfully after a short reassessment of the project assets, Xcode realizes there have been no changes made since the previous compilation, so it skips a full recompile and finally pushes the binary to your device. Then it’s just a matter of waiting for that push to complete and for the app to startup so you can finally see that one single UI change.

The duration from the moment you finished typing a new blur radius value until the moment you saw the app running in the real world is about one to two minutes. And this is per device. (Take it from me, someone who used to work at Unity on Augmented Reality development.) Meanwhile, to accomplish the same task with Sumerian you tap “Republish” and then refresh the browser on your device—a ten second process at the most. The speed and ease of iteration can make or break a tool. We had this silver bullet in our chamber and we squandered it.

Scene editors for open-source projects like Three.js and Babylon.js don’t have a true tap-to-publish feature and pursuing the creation of such a feature would be a costly slog with little to no upside for them. One might assume the same would be true for Mozilla, but in their enthusiastic support for Web-based virtual reality they created “Mozilla Hubs” with a free tap-to-publish feature. Hubs ought to have been a wakeup call for us. It offered many of the same basic features as Sumerian but without requiring new users to hand over credit card information—or even to create accounts. Hubs is entirely try-before-you-signup. Their strategy is to get folks into the Hubs editor, creating and sharing virtual environments with as little friction as possible. Hubs should have forced us to completely reassess Sumerian’s friction-filled onboarding process and therefore reassess AWS’ onboarding process. Rather than learning valuable lessons from Hubs we just ignored it.

With ease-of-publishing as a killer feature we ought to have pursued clients hungry for shareability. Movie and television studios, game studios, ad agencies, and so on. Instead we focussed primarily on industrial clients who mandated that their projects be locked down; unshareable and invisible. Focussing on sharable projects would have been a double win: marketing campaigns for big brands come with plentiful budgets, and well-shared projects become touchstones in prospective client conversations: “You know that XR thing you loved and went viral last week? We made that with Sumerian.” For further analysis see Observation #6: Chasing the wrong customers.

Tap-to-publish was a foundational Sumerian feature. The natural next step ought to have been the creation of a co-presence feature; a way to make it easy to author virtual environments for multiple users to inhabit together at the same time. Creating a multiplayer game server is hard. Sumerian could have handled and hidden this complexity from scene authors, making the creation of shared virtual worlds as trivial as tapping a button. See Observation #5: Misallocation of labor efforts. After all, Mozilla did it—and lets people use it for free.

Superior interface

Sumerian’s graphic user interface design is so superior to the editors for Three and Babylon that despite the existence of those competing editors and their cost of zero, Sumerian’s editor is indeed a justification for its existence in the marketplace. (I make this assessment as a former Principal Designer for Unity’s “Labs” group which has focussed heavily on interface design for 3D / AR / VR scene authoring.) It’s not that Sumerian’s interface is “prettier.” Graphic design is not merely veneer. Graphic design is effective and consistent communication through the use of text and imagery. While 3D scene authoring is complex and any scene authoring interface will necessarily involve complexity,  Sumerian’s interface is more or less intuitive to anyone with serious experience in established native competitors like Unreal or Unity.

This is not to claim that Sumerian’s interface is perfect, but its foundation is solid and an exciting place to build from. The further development of Sumerian’s interface—with a regular cadence of incremental improvements—ought to have been the primary focus of the development team. (This is further explored below in Observation #5: Misallocation of labor efforts.)

The design process is most effective as a dictatorship; not easily parallelized into a distributed open-source effort. (Compare the elegance of Apple’s graphic interfaces to typical Unix graphic interfaces.) This is in stark contrast to many software engineering efforts where distribution, peer review, and parallelism are beneficial. (Compare the efficiency of Unix to the spaghetti that is Windows.) While Babylon and Three might be better engines due to their open nature, Sumerian’s centralized nature is potentially a big win for its interface design. An empowered team of talented hybrid designers (designers with additional skill sets like code-based prototyping, copywriting, motion design, and so on) could have sustained Sumerian’s interface growth for years at low cost, yielding high reward.

Other

One might argue that integration with other AWS services is a third pertinent feature, but if so I would only see it as a distant third as Sumerian does not significantly lower this barrier as compared to accessing these services from outside Sumerian. (The majority of the complexity comes from configuring these services individually and/or configuring Cognito identities.)

Similarly, I see “Hosts” as only a remotely useful feature, if at all. The hosts themselves were strangely designed puppets with awkward movements and speech, unpleasant to use and ineffective for any sort of actual communication with human beings. Given the choice between receiving assistance from a human versus a Sumerian Host, which would you honestly choose? Between a Host and a text-based multiple-choice form? (In a sign of catastrophically poor taste, some internal decision makers felt these nightmarish cartoon Terminators would make excellent front-ends for medical emergency kiosks. Fortunately that dystopian reality never manifested.) Customers who opted to use Sumerian purely for its Host feature out to have been politely shown the door and their contact information removed from our metaphorical rolodexes.

# 4
Failure to
properly identify “users”

While Amazon aims to “put users first” this good intention was undermined by misunderstanding who the true product users were. In theory our job as ProServe consultants was to assist AWS customers in creating Sumerian scenes, and train them to author such scenes on their own—thereby making these customers the “true users” of Sumerian. In practice this rarely or never occurred. Instead the “true users” of Sumerian were ProServe consultants and Solutions Architects who labored in the Sumerian interface on behalf of AWS customers—who then consumed the published scenes and shared in that consumption role with their customers, if any. AWS customers were not Sumerian users.

Laypeople are not complex scene authors

This disconnect might be summed up as “Amazon Sumerian is not Microsoft Outlook.” A high-school-aged novice can be trained to write emails and share calendar invites in Microsoft Outlook over the course of a limited training session. This is because digital mail and calendars have become just another texture element of our laypersons’ society. Meanwhile, customer X’s average engineering or marketing consultant cannot be comfortably trained to understand 3D scene authoring concepts such as geometry, lighting, and so on in any of the pseudo-educational settings we attempt to create during ProServe engagements. They generally lack a 3D or visual art context to build upon. And these individuals already have a job to do for their company. Short of quitting their current employment and spending their 40 hours per week immersed in learning how to author 3D scenes they will not “pick it up in a workshop.” This is the reason universities exist; learning is a time consuming, immersive activity.

There were only two occasions over the past year where we were actually able to engage with a customer employee who understood 3D authoring. The first occasion was a project engagement session and the second one was an informal workshop session that did not result in a formal engagement. Neither one of these two employees were senior decision makers. To me this indicates that we were also chasing the wrong sort of customers. (See Observation #6: Chasing the wrong customers below.)

Amazon employees were the true users

While the published output of Sumerian was consumed by our AWS customers, the actual grind of creating scenes through the Sumerian interface was largely left to Amazon employees. But instead of our feedback being highly valued and accommodated, it was largely ignored. Only an AWS customer’s feedback had the ability to hold weight when filing Issue tickets or product feature requests (PFRs). The reality is that only a handful of individual non-Amazon Sumerian users—if any at all—could possibly have had enough experience authoring 3D scenes to make relevant or insightful comments or critiques of Sumerian that would lead to its improvement.

Our working policy was to devalue feedback from our true users by limiting our perception to only users outside of AWS employment. Because these external customers rarely used the Sumerian interface themselves (and also lacked the experience to make useful criticisms of any scene authoring tool) we were able to operate under the guise that the mere trickle of external criticism signaled the product was more or less optimal. (It was not.)

# 5
Misallocation of
labor efforts

The Neo 3D engine

As described above in Observation #2, the embrace rather than replacement of Sumerian’s “Neo” 3D engine resulted in Sumerian using a low-quality rendering engine that was difficult to service. In attempting to reach feature parity with competing Web-based rendering engines such as Three.js or Babylon.js, the Sumerian team was forced to sink countless labor hours into servicing Neo—slowly suffocating the potential to develop novel features or improve upon the graphic user interface. Embracing Neo starved Sumerian’s capacity to innovate. 

The new scripting API

In addition to labor efforts spent on Neo, a new scripting API was created for Sumerian. The impetus for this endeavor is curious; it is doubtful that a new API was requested by Sumerian customers. It is also doubtful the “true” users of Sumerian, ie. AWS employees (see Observation #4 above), requested this new API—and anecdotally it’s been unfavorably received internally. (I strongly count myself among that number.) Why then was this effort to create and deploy a new scripting API deemed necessary?

The new API only served to further distance a user from Sumerian’s inner workings which made using Sumerian more—not less—difficult. One of the advantages to Sumerian’s JavaScript / Web-based foundation is that it is to some degree “hackable” by users. (“Hackable” as in flexible and configurable for those with the ability to dig below the surface—not as in a security risk.) Using the new API reduces Sumerian’s hackability. When using the original scripting API it was possible, for example, to write “patches” that added or augmented how Sumerian functioned by directly overwriting some Sumerian engine functions and properties. With the new API the ability to do this is obscured.

Counterintuitively, the new API requires that users write more code to accomplish the same tasks, rather than less. And that code is more, not less convoluted. Rather than simply writing bare functions one must now use JavaScript modules, extend Sumerian’s custom “Action” classes using ES6 syntax, and also create custom “Actions.” All of this overhead is entirely unnecessary. It feels as if the decision to create this API was made by a group accustomed to classical inheritance and compiled languages rather than prototypal inheritance and the inherent flexibility of JavaScript. The whole concept of “Actions” in the new API is essentially an unnecessary wrapper for function queuing and object property detection which are native abilities of JavaScript. (How troubling it is to think that our product decision makers fundamentally misunderstand the language the product is being constructed in—and that the customers are required to use.)

How much time was spent designing the new API, implementing it, and drafting new documentation for it? This labor time spent on the new API exacerbated and perhaps even eclipsed the conscription of resources to patch rather than replace the Neo 3D engine.

Inability to incorporate “ready” solutions

As a result of the above, Sumerian was unable to make advances on its graphic user interface or innovate with new features. This includes an inability to execute on product feature requests that were either technically simple (like adding a toggle button to lock entities within a scene) or PFRs filed with working demo code—instances where the solution to a problem had not only been conceived of but working examples were created and submitted along with the request. For example, the Complex Cylinder Geometry PFR highlighted the inability to customize the default cylinder shape available from the “Create entity” dialogue box; to toggle its end caps on or off and to partially “unwrap” a cylinder into a curved wall. This PFR (Product Feature Request) and prototype code originated as a requirement for a specific customer project. The sample code patched Sumerian’s Neo engine to include this functionality; to actually augment Neo’s capabilities instead of merely running some functions on the “project side.” This code went into production for the client’s specific project, though sadly not for Sumerian itself.

Also worth mentioning on its own is the Surface text PFR which satisfies the often requested ability to apply dynamic text to a surface within a 3D environment. Billboards. Dynamic statistics. Branding. Instructions. Descriptions. Labels. The ability to easily add text to a Sumerian scene is still conspicuously absent. One can add an “HTML 3D” object but this does not respond to environment lighting and does not render at all in virtual or augmented reality. The PFR includes a functioning code example, and several demos have since been created, Sumerian projects have used it in production and we’ve even created an official blog post with the original PFR code rewritten for the new scripting API. Sadly, this ability to use dynamic text within virtual reality will never be a built-in feature of Sumerian itself.

Inability to pursue larger features

Tap-to-publish was Sumerian’s most distinguishing feature—though it was entirely unsung. (See the “Tap-to-publish” section of Observation #3.) That one piece of user interface collapsed mountains of complexity related to deployment, hosting, security, load balancing, redundancy, and so on. It allowed the user to focus on creating the content rather than bogging them down in technical weeds largely outside their creative concerns. 

Following this trajectory, the next major feature pursuit ought to have been the demystification of co-presence within a virtual environment; a way to make it dead simple to connect many separate users in realtime to a shared virtual world. When an entire audience participates in a Sumerian-based experience simultaneously—a possibility that AWS bandwidth can deliver on—the audience members ought to be able to see each other. They ought to be able to react to one another. But enabling this—building a responsive game server and managing this distributed state—is notoriously complicated, regardless of platform. We had the opportunity to lead the state of the art by creating a generic solution for WebXR co-presence in projects built on the Sumerian platform that could be engaged by a novice scene author with minimal fuss. (And for those all-in-one headsets, a URL shortener for Sumerian scenes (also filed as a PFR) would have made accessing that Sumerian output that much easier for a wider audience.) Like the Publish button, this mountain of complexity could have been collapsed into a few taps. We couldn’t manage to get there. Meanwhile, Mozilla’s new “Hubs” product—which came along after Sumerian—does it for free.

Another larger (and often requested) feature that could have had immediate impact was offline scene editing and playback. This came up frequently within client workshops—“Can we edit scenes while not connected to the network, then have those changes synched to AWS when we reconnect later? Do we always need a network connection to play a scene—even if we’ve loaded it previously?” This sort of feature set is entirely possible, was raised by just about every customer, and yet we did not deliver on any piece of it. (What happened to Amazon’s commitment to customer-lead innovation?) Similarly we could not deliver on the Sumerian engine / asset pruning PFR to reduce the payload size of scenes only using a subset of Sumerian’s capabilities; great for low bandwidth situations. Nor could we strengthen our AWS dependencies by creating a Sumerian WorkDocs integration feature for easily organizing and synching models, textures, and other assets; enabling a Sumerian project to dynamically pull from a shared cloud folder that syncs to the user’s own file system. (This is fundamentally different from the less user friendly and not terribly integrated Amazon S3 solution.) With Amazon WorkDocs integration it would have been trivial for users to edit Sumerian scripts in the native editor of their choice instead of relying on the rather limited Sumerian text file editor. 

Lack of forum for long-term thinking

Of the missed opportunities, this is perhaps most painful to myself: Sumerian’s inability to dream the big dreams. As a design student—long before the XR hardware of today—I began creating and exploring stereoscopic interfaces by coding simple experiments for use with red / cyan 3D glasses. For a few years afterward my career was anchored on building immersive panoramic digital experiences housed in custom-built rotundas with 360˚ projection. Later through Google’s Creative Lab, Google’s Data Arts Team, and Unity’s Labs team I was able to give serious thought to the future of XR creation and consumption as the actual consumer hardware began to finally materialize in the forms of the original Vive, Rift, Hololens, and Magic Leap. I created the original generic hand controller library for Three.js, co-created the LCD Soundsystem “Dance Tonite” WebXR music video, and otherwise contributed to the earliest days of Web-based XR. (This one blog post includes the generic hand controller, multi-channel haptic feedback, “Modes” and “Tasks” as alternatives to State Machines, and more.)

With this background I was excited to begin poking at the future possibilities of Web-based XR; gleaning through ProServe engagements not just what clients demand today, but what clients—and the whole ecosystem—will require tomorrow. I began assembling decks, such as Project Hermes, which describe or hint at several innovations:

1. A simple XR portal hyperlink schema for connecting separate virtual environments, allowing users to seamlessly journey from one to the next.
2. A “foot menu” UX system to be used across virtual worlds for carrying identity, settings, and bookmarks. (These prior two points were deemed by the AWS patent team as “patent-worthy”, but the pursuit was dropped as there was no timeline for integrating them into the actual Sumerian product; seemingly a requirement for patent filing.)
3. Integration with Amazon’s marketplace by making 3D models of products available to sites using Hermes / allowing users to purchase the real (or virtual) items.
4. A new analytics service for understanding the hardware and software contexts of virtual environments.
5. Standardized “XR attention units” based on gaze tracking, object interactions—the ad value of a gaze vs a glance, etc.—and a service for measuring them; web traffic analytics raised to the power of XR.
6. An Amazon social network built on the use of identities being carried across virtual worlds. And so on.

There was no true forum for supportively contemplating these ideas, vetting them, and experimenting with them. (This would have perhaps required a team dedicated to such futuring exercises.) Circulating concept-heavy ideas via email or in cross-team meetings did not establish much of a foothold for action. The Sumerian organization simply was not geared for the pursuit of big-ideas.

# 6
Chasing the
wrong customers

Rather than pursuing clients with a predilection for shareability—like movie and television studios, game studios, and ad agencies—we focussed on industrial and corporate clients with the exact opposite disposition. This made the bulk of our work unshareable and invisible. Had we pursued only the former, all of our output would have been of public record and our interest in promoting Sumerian output would have aligned directly with our clients’ interest in doing the same. Instead we repeatedly put ourselves in positions where the fruits of our labor could only be consumed silently and invisibly. 

Additionally, as an emerging technology service pursuing industrial and corporate clients we were rarely able to engage with individuals who were both decision-makers and literate in our field. The Vice President of a multi-million dollar insurance company is seldom also an XR expert with a zeal for anticipating what sort of XR experience might excite their customers. Meanwhile, an Executive Creative Director from a multi-million dollar creative agency might actually specialize in digital—or even immersive—experiences; stands a better chance of having a positive and productive engagement with Sumerian. We set ourselves up for success when we can have deep and serious conversations with knowledgeable and demanding customers. Demanding yet ignorant customers won’t know what paths are worth pursuing; won’t recognize the elements that lead to success, or have the foundation to critique the elements that lead to failure.

Sumerian is ① a creative tool with ② the ability to broadcast widely as one of its core features. We ought to have only engaged with clients attuned to those two foundational elements. 

# 7
Failure to build
a robust community

Sumerian’s Slack and Twitch communities have been fantastic rallying locations, but any such community outreach is ultimately hampered by AWS’ walled garden. The contrast between Sumerian’s need for accessibility and the reality of its friction were tangentially highlighted by the release of Mozilla’s “Hubs” scene editor and publisher. Hubs could be described as Sumerian-light with zero barrier to first use—including publishing scenes for free that support co-presence by default. As a young AWS product with no established following of its own, Sumerian should have found a way to offer a “light” version that side-stepped the laborious AWS sign-up process and need for a credit card. If prospective users of a creative tool cannot play with that tool before purchasing it, the likelihood of them converting into a paying customer remains small. Additionally, it’s the storage and cloud computation that are expensive; we lose little by allowing the curious to play small stakes for free. 

With no easy way to work around the AWS wall, we ought to have sternly curated a gallery of “Sumerian excellence”—projects that were either beautiful, sophisticated, or both—and promoted it to the extreme. (See also Observation #1: Failure to recognize a new product category.)

When comparing the home pages for Three.js, Babylon.js, and Sumerian, what percentage of screen real estate is devoted to showcasing work made with the tool? What percentage is instead description text? These are not mere veneer decisions. They are revelatory glimpses into the souls of the organizations—like non-verbal body language that contradict a speaker’s words. It’s always more meaningful to show than to tell.