Before I switched to being a full-time developer in 2010, I worked as a user-interface designer for seven years. Something that always bothered me during that time is that so much of what I was learning was just how to use Photoshop really well. After I switched to development, I was hesitant to ever invest that much in just learning a big software package again. “What if I choose wrong? And waste all those years of learning by switching to another software package?” I asked myself. Recently, I’ve re-evaluated that decision, based on my analysis of the market share of major creative applications. It turns out if I’d just chosen which software I want to learn ten years ago, for most categories, it would still be the same today. For some categories, it would still be the same if I’d chosen twenty years ago, and it’s often the first software that was ever introduced to solve a problem, even if that application is over 30 years ago, that’s still the best choice today. So it turns out I was overcorrecting relative to the risk in learning big complex packages, so now I’m investing in doing it again.
This is the list of software I’ve chosen to learn:
Some of these I already know quite well (Vim, Photoshop), and some I’ve barely touched (Premiere Pro, Final Cut Pro). I’m not happy with the duplication, and frankly, this is probably just too much for one person. Learning any one of these applications is an lifetime of work, let alone all of them. But I can’t decide what to cut, so here we are.
The new Productions feature set for Premiere Pro was designed from the ground up with input from top filmmakers and Hollywood editorial teams. Early versions of the underlying technology were battle-tested on recent films such as “Terminator: Dark Fate” and “Dolemite is My Name.” Special builds of Premiere Pro with Productions are being used now in editorial on films like David Fincher’s “MANK.”
When Apple pushed FCP to the industry pros five or six years ago, they did some hardcore outreach. They brought out Walter Murch, for God’s sake. The man cut Cold Mountain on it for God’s sake.
Versus Adobe Team Projects
Adobe already has an existing feature for video collaboration called Adobe Team Projects, that’s designed around a cloud workflow, Bedient describes the difference:
Productions is designed for collaborators working on shared local storage. Team Projects is built for remote collaboration: assets can be stored locally with individual users; project files are securely stored in Creative Cloud. The two toolsets are distinct and currently cannot be combined. Productions is part of Premiere Pro and is included with all licenses. Team Projects is part of Team and Enterprise licenses for Premiere Pro and After Effects. In order to support users working from home due to COVID-19, Adobe is making Team Projects available to all users from April 14 through August 17, 2020. See this post for more information.
Collaboration & the Future of Creative Apps
Collaboration is the word of the day, and it’s great to see Adobe taking it seriously, especially with a vision that isn’t web-based. The web is the platform that makes collaboration the most straight-forward, the easiest way to share something is through a URL, but a web app isn’t necessarily the best trade-off for all use cases.
The question at the heart of Figma’s success is whether it winning the user-interface design market means web apps are also destined to win other creative markets which have otherwise been the stalwarts of desktop native apps. But another way of looking at it is that the native app they are competing with, Sketch, was doubly harmed by Apple’s policies:
It’s built on AppKit, which Apple was aggressively enhancing in the 2000s for high-end desktop apps but since the 2010s they’ve switched to focusing on frameworks that benefit iOS. This essentially means the platform Sketch is built on has spent a decade stagnating.
As software for professional creative users, Sketch isn’t compatible with the Mac App Store, this means they’ve been denied access to the most important promotion channel for Apple platforms.
Figma may have only been able to succeed because Sketch was built on a platform that’s at best indifferent to their use case, and at worst actively hostile to it. That’s a big difference compared to the cross-platform native desktop apps that are still relevant: Microsoft will fight tooth and nail to make sure Microsoft Office stays relevant, and Adobe will do the same with Adobe Creative Cloud.
Pre-2004:BBEdit, Emacs, and Vim are all great text editors in their own right, but all have idiosyncrasies that, while beloved by people like me, prevent them from ever being the most popular text editor.
2004:TextMate is released, with its focus on packages to extend the editor and add support for different programming languages, but its API is still too limited to truly be a platform.
2008:Sublime Text is released, with a more sophisticated API, facilitating more powerful packages, but package management is still an afterthought.
2014:Atom is released, bringing package management to the forefront, but Atom has performance problems.
2015: Visual Studio Code is released, keeping packages front and center while also solving Atom’s performance issues. As far as I can tell, this essentially represents the final form for (mainstream) text editors.
I don’t see how VSCode can ever being contested again, unless its team makes a grave strategic error. We’ve seen over and over again, that once a platform takes off, its momentum creates a moat that’s almost impossible for challengers to overcome.
Zapier releases a new tool for annotating screenshots called Zappy, in the tradition of Skitch, and, my favorite, the unfortunately discontinued Napkin.
I’m fascinated by this problem, it seems so simple on the surface: Just share what I’m looking at on the screen and be able to mark it up. But this problem is wonderfully devious in ways that emphasize our expectations when using computers. For example, once something is digital, we expect it be perfect. A poorly-drawn digital line is somehow worse than the same line drawn on a whiteboard.
Consider editing text, one of the first things a new computer user learns, and almost immediately they can produce pixel-perfect text every time. The comparative skill for just editing a line, is a Bezier curve tool like the one found in Adobe Illustrator, which is extraordinarily difficult to master by comparison.
Sharing an annotated screenshot brings out two truths about computers:
We expect digital artifacts to be perfect.
Editing anything graphical with a computer is very hard to master.
Eclipse Theia is an extensible platform to develop multi-language Cloud & Desktop IDEs with state-of-the-art web technologies.
The screenshots look just like Visual Studio Code, and it supports VS Code extensions:
We believe VS Code is an excellent product. That is why Theia embraces many of the design decisions and even directly supports VS Code extensions.
As to distinctions from VS Code, as previously mentioned it’s designed as both a desktop and cloud IDE, there’s some details about what exactly that means in the Architecture Overview:
The frontend process represents the client and renders the UI. In the browser, it simply runs in the rendering loop, while in Electron it runs in an Electron Window, which basically is a browser with additional Electron and Node.js APIs. Therefore, any frontend code may assume browser as a platform but not Node.js.
I’m curious what benefits this entails in practice over using VS Code with the open-source code-server.
Another major component is the Open VSX Registry, which is described in a The DEV Community post as “an open-source implementation of a VS Code extension registry that we have developed under the umbrella of the Eclipse Foundation” with the rational being:
Unfortunately, Microsoft prohibits non-Visual Studio products from installing any binaries downloaded from their marketplace (see terms).
Acorn grew out of upgrades to another app of mine, FlySketch, designed for screen capture and sketching. Customers asked for new features, I started adding brushes and layers and multiple windows, and all of a sudden I had a full-blown image editor. But Acorn still serves different needs than professional-level editors. Acorn is powerful, but nimble and approachable. It also has excellent documentation that we’ve worked hard on for years.
Unlike most browser-based email, which is server-based, Superhuman can store and index gigabytes of email in the web browser itself. This is possible by leveraging today’s more powerful APIs in the browser, along with the faster CPUs and hard drives on our computers.
The Omni Group’s 2020 roadmap has a great section on automation that’s worth reading in its entirety. It covers both their future plans for their own apps, and a declaration of why automation is important in general:
By providing automation technology in our apps, we make it possible for customers to extend our apps’ capabilities. People can build customized solutions to meet their own needs—and then share those solutions with others. We had thousands of customers using Kinkless GTD in OmniOutliner, even though most of those customers didn’t know AppleScript. I’ve been told that one of JTech Communications’ most popular blog posts was for a script for OmniGraffle which counts items on a canvas. With automation, people are able to create their own keyboard shortcuts to quickly perform actions like creating a task calendar from OmniFocus, or exporting Markdown from OmniOutliner—and those solutions can often be shared with others, making everyone’s lives easier.
The Omni Group is apparently going through some hard times, bless them for taking automation so seriously in their apps.
There are a couple of interesting products to look at for the future of creative apps: The first is Figma, the first-ever web app to gain traction with creative professionals, another is Lightroom CC, Adobe’s newer alternative to Lightroom Classic. Lightroom Classic is the same application Adobe has been shipping since 2007, it has more powerful features1, in particular fine-grained control over how your image files are managed on disk. Lightroom CC is a newer alternative, and it’s the only version available on mobile. Lightroom CC has no control at all over your image files (“the era of the file is over”—Scott Belsky, Chief Product Officer at Adobe). Instead, all of your image files are synced to Adobe Creative Cloud. While it’s still behind Sketch, Figma has clearly been a resounding success with professionals. It’s harder to gauge how successful Lightroom CC has been, on one hand, it’s not marketed to professionals to begin with, but on the other, it’s hard to interpret Adobe’s choice of the word “Classic” in the name as anything other than an attempt to drive users to the newer app.
So how’s that going? Jenn Mishra recently wrote an article about sticking with Lightroom Classic for PetaPixel. Looking at the comments, this article received a hundred of them before the comment limit kicked in, and there’s only one comment that’s positive about Lightroom CC: It’s easy to find, it’s at the bottom, with the most downvotes.
The reason why I use it is that I’m used to it. I used Final Cut Pro from the very beginning of my career. For now — regarding sound mix and the workflow — it’s really simple to use. However, I haven’t been able to update my OS for four years.
BushelScript is an open-source AppleScript alternative:
BushelScript is open-source and community-driven, meaning it can undergo necessary changes and gain useful features rather than remain stagnant as a side project on life support.
The real tragedy of AppleScript is not its becoming obsolete or irrelevant; tons of Apple-supported macOS apps still have healthy scripting interfaces. No, the tragedy is that the language through which such functionality is presented, with all its quirks and weak points and even utter failures, is extremely unlikely to receive any badly needed improvements in the future, if any changes at all. It is stuck in maintenance (read: bugfix and security hole-filling) mode and will be for years to come if we, the users, don’t replace it with something better whose fate we can control.
On the WebKit blog, Apple announces they’re putting a “7-Day Cap on All Script-Writeable Storage” for privacy reasons:
Back in February 2019, we announced that ITP would cap the expiry of client-side cookies to seven days. That change curbed third-party scripts’ use of first-party cookies for the purposes of cross-site tracking.
However, as many anticipated, third-party scripts moved to other means of first-party storage such as LocalStorage. If you have a look at what’s stored in the first-party space on many websites today, it’s littered with data keyed as various forms of “tracker brand user ID.” To make matters worse, APIs like LocalStorage have no expiry function at all, i.e. websites cannot even ask browsers to put a limit on how long such storage should stay around.
In iPadOS 13.4 and Safari 13.1, all forms of offline storage for web apps will be purged after seven days. When I wrote about how iPadOS’s new mouse support will benefit web apps, there’s an additional observation that I neglected to mention: There are only two ways apps can target that iPad, either as a native app available through the App Store, or as a web app accessed through a browser. Since App Store rule 2.5.6 prevents browsers from using third-party rendering engines on iOS, this effectively means Apple has complete control over all methods of software distribution on iOS. And, since native apps are more of a differentiating feature for iPadOS than web apps, as the coming iPadOS mouse support starts to make desktop-class web apps usable on the iPad for the first time, we can expect Apple to correspondingly start hindering web apps in order to give native apps an advantage on their platforms.
A huge beneficiary of iPadOS’s new mouse support will be web apps, because, with App Sandboxing, those are the only desktop apps that can run in their full versions on iPadOS.
Alex Russell, a software engineer on the Google Chrome team, has a devastating presentation about how little people are using the mobile web. What struck me while I was watching was that, while Russell gives some optimistic suggestions for increasing the mobile web’s relevance, it’s clear that this battle is already over and the mobile web lost. The web simply isn’t an important platform for most of the world on mobile, and it’s especially unusable for anyone who doesn’t own a high-end phone.
Russell provides some stats to support this, including these 2014 numbers from Flurry showing that only 14% of time on mobile is spent on the web, while the other 86% of time is spent in apps. He calls out 10% as a meaningful threshold, that if a platform ever drops below that number, it doesn’t get the investment it needs in terms of tooling and libraries; you enter what he calls a “doom loop”. According to Russell, Google has internal metrics that show mobile web usage has now dropped below 7%1.
Russell talks about the reasons this it the case, the argument boils down to two issues. The first is performance, you just can’t get around the fact that native apps are more performant, and requires less bandwidth. The other is that Apple leverages their control over iOS to deemphasize the web, Russell cites two App Store Review Guidelines in particular:
2.5.6: Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
This is the rule that blocks third-party rendering engines like Firefox’s Gecko and Google Chrome’s Blink.
The second piece that Russell references is the introduction to section 4.2 Minimum Functionality, which starts out by saying “Your app should include features, content, and UI that elevate it beyond a repackaged website.” In other words, Apple just comes out and says that just a website isn’t good enough for the App Store.
The losing battle for the mobile web brought about some personal reflection, because I’m also fighting a battle that’s already been lost: The battle for a macOS desktop of Cocoa2 apps. From 2001–2010, it felt like we were headed in that direction. Mac exclusive utilities and productivity software took off right away from the release of OS X, with companies like Panic and The Omni Group leading the charge, and TextMate and Apple’s iWork being important milestones along the way. Then, in the latter part of the decade, the real holy grails began to emerge: The groundwork Apple had been laying for visual tools at the framework level started to bear fruit first with Acorn and Pixelmator, both released in 2007 and built on Core Image, and Sketch released in 2010 and built on Core Graphics. The vision of an entire desktop of “Mac-like” apps seemed within reach, finally offering an alternative that doesn’t include cross-platform behemoths like Adobe’s Creative Suite and Microsoft Office.
Affinity Designer comes in at %2 for user-interface design in Uxtools.com’s poll. It’s worth noting that Affinity Designer is about 1/20th the cost of its most similar competitor, Adobe Illustrator, which is also about nine times as popular in the same poll. Even sandboxed applications competing with Adobe’s widely disliked subscription model have difficulty gaining significant market share.
With a single gesture, Apple assured that a desktop of all Cocoa apps would never be a reality, at least not for users of professional creative apps. The creative apps that abide by Apple’s sandboxing rules have been marginalized, unable to compete with the more popular and powerful apps outside of the sandbox.
Apps can still use Cocoa without being sandboxed, by choosing not be in the Mac App Store, but by doing so they lose access to Apple’s marketing clout3, which removes one of the factors that helped apps like Pixelmator and Sketch get off the ground in the first place. Both benefited from heavy promotion by Apple early on. All of these factors change the tradeoffs of using Cocoa, and there’s little upside at this point.
This isn’t just about sandboxing and the Mac App Store, the frameworks Apple releases today for developers to build on, like ARKit and Core ML, also just aren’t as useful for Mac apps as the pre-2010 frameworks like Core Graphics and Core Image were. ARKit is obviously intended to make apps for iOS, due to its camera and form factor requirements. While Core ML does have some desktop uses, it’s still more useful for iOS because it’s harder to accomplish things manually on that platform4.
Finally, Apple’s own fleet of pro apps has been paired down to just:
Final Cut Pro X (Acquired in 1999)
Logic Pro X (Acquired in 2002)
Motion (first released in 2003)
While the following have been shuttered:
Aperture (first released in 2005, discontinued 2014)
Soundtrack Pro (first released as part of Finale Cut Pro in 2003, discontinued in 2011)
The last time Apple introduced a new pro app was in 2004, and the last time they acquired a new pro app was in 2002, a strategy that had worked well for Apple in the past, resulting in both of their pro crown jewels, Final Cut and Logic. Aperture, Shake, and Soundtrack Pro were all canceled, ceding their market share back to the cross-platform behemoths. In addition, Final Cut Pro X has gone the prosumer route. While this isn’t necessarily a bad thing, it is more evidence of a pattern of Apple not supporting their pro users. Here’s Adam Lisagor of Sandwichcomparing the release of the release of Final Cut Pro X to previous versions:
When Apple pushed FCP to the industry pros five or six years ago, they did some hardcore outreach. They brought out Walter Murch, for God’s sake. The man cut Cold Mountain on it for God’s sake. They evangelized by showing what had been done, not by what could be done. But this time out, there is no evangelizing. No Murch. They do a dog and pony with vapid car footage or a Pixar trailer or something. This is meaningless to industry pros who need to know one thing, and it’s a very simple thing: can I edit a _____ on it? You know what I want to know? Can Louie CK edit his show on FCP X? Would he? Would he be happy to do it? Would he speak to a crowd of people about the experience? Would he plan on the product getting better? At what point does Apple ever even hint at admitting that they’ve released a product that will improve with age? Do they owe it (or anything) to their pro user base to acknowledge even a transition period? I want to be emailed a questionnaire and I want my Apple rep to write to me and invite me to a seminar called “Let’s cut a commercial”.
You know how many licenses of FCP Murch and Cold Mountain sold? Millions. Know how many licenses the most beautifully-crafted, tastefully-shot home movie of your family trip to Lake Havasu will sell? @#$%& all. Nobody wants to make the best home movie ever. It’s just not an aspirational thing anymore, the way it was in the early days of hub computing, when the Mac was aspirationally this centered hub of creation. We don’t want to do that anymore, our eyes are bigger. We all want to think we can make The Social Network now. So show me Fincher cutting The Social Network on FCP X and you’ll have me on board.
Across the board Apple’s support for creative apps is fading, whether it’s their own creative apps, new frameworks for pro apps, or supporting third-party apps investing in their platform. The dream of a desktop of consistent Cocoa apps is farther away than ever.
I’m using the term “Cocoa”, instead of the more precise “AppKit”, or the more understandable “Mac-like”, for historical reasons. If you followed Mac software during the 2000s, then you heard a lot of discussion about Cocoa and its benefits, in particular in contrast to Carbon. A Cocoa Mac app connotes a certain set of characteristics: sharing UI components with the rest of the OS (with consistent text editing in particular), support for system-wide features like Services, a customizable the toolbar, and, if you’re really lucky, AppleScript support. ↩︎
Apple appears to market two types of Mac apps: Mac App Store apps, and apps that aren’t in the store, but are important enough to move Macs. For example, their macOS page currently lists Adobe Illustrator, Cinema 4D, Maya, and Zbrush. What Apple seems to never do is market new apps that aren’t in the Mac App Store, which are exactly the most important apps for the future of the Mac as a platform. ↩︎
To illustrate how Core ML is more useful for iOS apps than macOS apps, consider the most natural way you’d edit photos on each platform: On the Mac, you’d use a complex app like Adobe Photoshop or Adobe Lightroom to edit photos entirely manually, whereas on iOS, it’s more common to just select from a few preset options that edit your photo automatically. This whole approach of letting the machine make the decisions for you, leveraging tools like machine learning, stems from input being more limited on iOS and iPadOS. ↩︎
Once upon a time desktop apps reigned supreme, they were the only game in town. When the calendaring web app 30 Boxes was released in 2006, a couple of months before Google Calendar, the idea of a web-based calendar was still novel. Back then, your calendar was managed by a native desktop app like Microsoft Outlook or iCal. Now Google Calendar is probably1 the most popular calendar app there is, and desktop and laptop sales are declining overall. People are using their mobile devices for tasks they once would have used a desktop or a laptop for.
The post-PC era means the desktop, and to a lesser extent, the web, are in decline, and mobile is on the rise. But what do we make of the fact that some areas of native desktop software seemingly have a gigantic lead that doesn’t seem to be budging?
We now have three separate, distinct platforms: web, mobile, and desktop. Desktop was here first, so it’s inevitably losing marketshare as the other two gain it. The web came next, so it’s also losing it as mobile gains it. But things aren’t as simple as they seem when you look closely: Desktop software hasn’t really changed much since the web and mobile came along. The top 10 free apps in the Mac App Store include both the iWork and Microsoft Office suites, and the top paid apps include both Logic Pro X and Final Cut Pro X2. These are the same apps that would have been the most popular 20 years ago, long before mobile, and before the web really took off as an app platform. The iOS App Store, on the other hand, is dominated by games and social media apps (although both Google Docs and Gmail make the top ten).
The Types of Apps in Transition
If the desktop app market hasn’t changed that much, then where is the transition to mobile coming from? The simplest answer is that many of the new use cases that arose with the web, the biggest example being social networking, have transitioned from the web to mobile3.
This categorization isn’t perfect, for example, it doesn’t account for chat apps like AIM and ICQ which were native desktop apps, not web apps, and have now been replaced by mobile apps like Messages, Slack, and WhatsApp. “Network-enabled apps” is probably a more precise term, but web apps is fine for shorthand. The collaborative nature of the web still captures the spirit of the native desktop chat apps.
The contrast between the decline of native desktop chat apps, and social media on the web, compared to the continued relevance of traditional desktop use cases, like Logic Pro X, and Final Cut Pro X, where it’s mobile that’s struggling for relevance, highlights a flaw in the post-PC narrative of a declining desktop. If that narrative were accurate, you’d expect to see a decline in all desktop use cases that looks something like the desktop chat apps, but we don’t.
The Platform Advantage Matrix
What’s happening isn’t a transition, it’s a migration. Apps are migrating to the platform whose advantages best fit their use case. I’ve tried to summarize the advantage of each platform in a single word4:
The desktop is for apps with long lists of features, the defining characteristic of powerful apps is that they support an ecosystem of third-party plugins. The web has the best features for allowing people to view and edit the same content, the URL is the easiest way to share anything. Mobile is the gold standard of making apps easy to install, easy to run, easy to use, and has convenience features like prefetching.
Simplicity is desirable in all apps, except for those used for creation, where it runs contrary to the flexibility necessary for expression. So mobile apps are the baseline, and the best the platform for an app, unless one of the advantages of the other two platforms is more important: If its main purpose is to be powerful or to facilitate collaboration. The reason so many apps support both mobile and web, without having a native desktop app, is because collaboration and simplicity complement each other, while power is at odds with both6.
Apps & Their Platforms
Here are some examples of apps categorized by the platform advantage that’s their highest priority:
Facebook, Instagram, and Twitter all end up in simplicity, because while social media is inherently collaborative, the space is so competitive that zero compromises in the all important simplicity category ends up being the highest priority. Trello and Slack are the inverse, with less competition for their categories, their essences is reflected as collaborative software. Of course, Slack and Trello also have mobile apps, but their native apps feel more like web apps than truly native first apps, because collaboration is their highest priority. Almost all of the collaboration and simplicity apps have both mobile and web apps (the only exception is Figma), while none of the power apps7 have either mobile or web apps, because while simplicity and collaboration are in alignment, power conflicts with both.
Figma is actually quite powerful, but it ends up in the collaboration category because that’s it’s defining trait. You could say that Figma’s marketplace bet is that the interface design industry will sacrifice some power in order to collaborate more effectively. Notably, an app like Figma still leaves room for other more powerful desktop apps in the same category, because there will always be some people that want more of the power that Figma sacrifices in order to be more effective at collaboration.
There’s also a special category for apps that don’t fit anywhere else. This mostly illustrates flaws in this exercise. The software landscape is messy. Every app is made up of many small decisions, and they reflect their creators, just as much as they reflect the marketplace. Any attempt to pigeonhole them is bound to run into some problems. But the idea is, if you zoom out far enough, some patterns emerge that can help us better understand the platform migration that’s underway today.
Conclusion
The goal of this piece is to predict where software is going. It’s common today to predict that mobile, and to a lesser extent, the web, are replacing the desktop. Steve Jobs famously said the desktop is going to be like trucks8, but I think a more direct comparison is that the desktop is going to be like the command line. The command line was once the only interface computers had, then the GUI came along, and now that’s the main way the vast majority of users interact with their computers. But that wasn’t the end for the command line. It’s continued to be an indispensable tool for developers, to the degree that software development is almost impossible without it9.
The future of the desktop might be like the command line. That may sound like faint praise, but that depends on the prism you’re looking through. If the desktop continues to be the best place to do the most exciting things you can do with a computer, things like 3D, audio, motion graphics, programming, and video—all of which haven’t budged since the introduction of mobile—then it will be the most important platform to do the things I care about the most. Sure, I’ll still have an iPhone and an iPad, and I’m sure there will be some great creative tools on those platforms, just like there are some great GUI and web tools for programming that aren’t on the command line today. But if the desktop continues to be the heart and soul of where creative work is done, then that’s the platform that will have won to me.
I’m not aware of any marketshare numbers for calendar apps, but while Microsoft Office is clearly more popular in the enterprise, I’d assume Google Calendar is more popular for individuals. ↩︎
Presumably more apps like Final Cut Pro and Logic Pro X would be in the Mac App Store if Apple eased up on the sandboxing restrictions for Mac App Store apps. ↩︎
There are some new categories of app that the mobile form factor, and economic model, have enabled to emerge. Some examples are the wonderful Procreate, and the explosion of mobile gaming. ↩︎
Summarizing the advantages of each platform with a single word is inherently flawed, because it doesn’t account for a bunch of secondary characteristics that each platform has. For example, the web is also the easiest way to make an app available on any device, and mobile grants access to sensors and data that aren’t available anywhere else. But the goal here is just to distill the essence of a platform into a single word, in order to create a framework that we can use to look for broad patterns. ↩︎
Collaboration is a much broader category than it at first appears, encompassing not just obvious examples like Google Docs, but also, content management systems, and any kind of employee portal. The majority of software used to run businesses is collaboration software. ↩︎
Power is at odds with collaboration because, the more powerful an app is, the harder it is to use, and the harder it is to use, the fewer people who can use it, which means fewer people to colloborate with. ↩︎