Reddit AMA on Photopea, a free alternative to Photoshop used by 1.5M people

    vim tools/Text.js
    self.addEventListener('click', function (e) {
      if (e.detail === 3) {
        self.selectAll();
      }
    });
    :wq
    git add tools/Text.js
    git commit -m "Add triple click select all"
    git push origin master
    Done.

Compare that to building binaries for all supported platforms, testing, publishing, dripping down into Debian & Ubuntu, someone on Ubuntu-Based-Distro-#1377 reporting a dependency problem, someone old Debian complaining that their compiler is choking on a gl library under armv7l, etc.

Fancy juggling AWS config and costs? Writing user manuals, help desk scripts?

On a scratch-itch OSS project you can ignore those. But when you plan to sell it, things scale quickly. Coding is just one arrow in quivver.

In my area, we've literally built something more or less like that a few times in the same time with one or two developers each time. In fact, I found out after the demo that much of the core logic came from a repo a guy on my team wrote in his spare time to plug a hole on a minor side project he was doing.

There may be some communication between product and design to figure out how it should look and feel.

Then it'll go into a sprint most probably, but not the current sprint, because that would change the scope and affect estimates and possible delivery timelines. You'd only change the sprint scope if the team is running out of work to do or there's a major customer request or other panic.

There will be some measure of QA, ideally. Some people fly by the seat of their pants, and rely on fixing things in production if it breaks in production. This is using your customers as QA. Can work if you roll out gradually and are very responsive to any reports of regressions.

All in all, this is unlikely to happen in less than a couple of weeks. The processes are designed for predictable, consistent delivery and to minimize surprise. Shortening the chain will mean less integrated decision making and will increase the amount of surprise and inconsistency in the product and its delivery.

In a larger team the flow of info is DevOps/Developer spot error in CI/CD, find out which commit/Developer broke the build. Email/slack/ walk over to let them know and sit down for a friendly troubleshooting session.

Resolve the problem. Follow necessary processes to commit change. CI/CD hosted agent is busy building other projects because not enough budget for multiple hosted agents and all CI/CD is handled in the cloud. Time to go home!

Obviously that was a bit facetious but you get the picture.

Additionally, beyond trivial projects, some changes may require changes to architecture, even small ones. A new feature may require a new index, a schema get updated, a new worker be setup to run in prod, etc.

And usually there are multiple PRs waiting to be added, which have to be deconflicted, and the lead dev still wants to code so everything takes longer than you'd think.

Those 100 engineers have to first agree on a CI/CD pipeline.

though if your OS has decent windown management and tear dow menus (both not an option on osx-cloned gnome3) than you'd be a fool to use it

Krita has to to be compared to Photoshop because both are working on rasterized images. While Krita emphasizes drawing tools in its UI while Photoshop exposes manipulation tools more prominently, both programs aim to cover both sets of features. And Krita's core is actually much, much more advanced than what you would expect from a drawing program. I would actually love to see a UI for Krita that focuses more on manipulation, just to placate the "it's just for drawing" crowd.

There are a lot of parts of Photoshop which could be radically improved if Adobe weren’t constrained by needing to preserve existing customer workflows from circa 1995 and build off decades of legacy code / organizational inertia. Most of the low-level decisions in Photoshop are based on academic research from the 1970s, reimplemented in the early 1990s to match mid-range computer workstations and typical images of that time.

Many new image editors have basically zero thought put into design or core image processing infrastructure, and are just exact copies of Adobe’s ideas, without considering that computers and imaging have changed dramatically in the past 2 decades.

(To be fair, coming up with new ideas and then polishing them to the point they are ready for customers is really hard: it takes vision, cross-disciplinary expertise, new research work, multiple attempts at implementation when some ideas don’t work out, integration effort fitting ideas together, etc. Clones are a lot easier.)

The main problem of the Affinity stuff is a lack of integration with professional niches and functionality that pros need for daily bread & butter work. E.g. not having an easy way to mock products (smart objects) renders it already unusable for most professional graphic designers. Instead of using the commonly used HSV color picker like in Adobe apps or Sketch, they go with HSL which isn't as intuitive. Many "small details" like that..

The devs seem to focus on overall functionality, specs and performance, not workflow specific functionality that makes tasks easier. The UI looks great, but is awkward to use.

They seem to be more concerned about being perceived as alternative to Adobe products than actually being an alternative.

This is a tiny fraction of what Photoshop does. Even back in the mid-2000s, when I was a graphics designer, I rarely used Photoshop for simple work like that. It would have been the equivalent of using a nail gun for a single nail to hang a photo frame. You could do it, but the $10 hammer in the shed will work just fine.

Also commercial support.

http://www.faculty.ucr.edu/~eschwitz/SchwitzPapers/USAconsci...