Adobe Photoshop Source Code (2013)

Original Article ↗ Hacker News Discussion ↗

Adobe’s release of the Photoshop 1.0.1 source code from 1990 prompts reflections on how much of that early architecture and UX still echo in today’s vastly larger, more sluggish versions. Commenters contrast Photoshop’s long evolution and dominance with open-source tools like GIMP and Krita, debating feature gaps, usability, and why many professionals remain locked into Adobe’s ecosystem. The thread also touches on software preservation, licensing constraints on redistributing the code, and broader issues such as trademark genericization of “Photoshop” and the loss or archival of historic source code from other major applications.

Legacy Code and Languages

  • Early Photoshop (v1.x, 1990) was written in Pascal, using Apple’s MacApp framework.
  • Comments speculate that substantial early logic likely persisted for many years, then was transpiled or rewritten into C/C++ for portability.
  • Pascal→C and Pascal→WASM tools are mentioned; TeX is cited as a prominent example of such translation.
  • A former Photoshop engineer notes that pieces of the original MacApp-based layer still survive in the modern codebase.

Trademarks and Genericization (“photoshopped”)

  • Adobe’s insistence on “Adobe® Photoshop® software” instead of “photoshopped” is discussed as a classic attempt to avoid trademark genericization.
  • Similar efforts by LEGO and Velcro are mentioned; some think Photoshop is already effectively genericized, others note law still protects it.
  • A distinction is made between informal speech (ignored by users) and formal/commercial usage where partners follow guidelines.

Photoshop vs Open-Source Alternatives

  • GIMP is debated: some use it for very simple tasks (cropping, scripting), others argue it’s rarely used professionally compared to Photoshop or Krita.
  • Krita is praised for painting and non-destructive editing; Inkscape is seen as useful but buggy and awkward for drawing.
  • GIMP is criticized for missing core non-destructive workflows (adjustment layers, layer styles, smart filters) that Photoshop has had for decades.
  • Naming (“GIMP”) is controversial; some find it terrible, others think it’s fun. Krita’s maintainer (in-thread) explicitly encourages verbing “Krita”.

UX Stability, Muscle Memory, and Change

  • Many note how consistent Photoshop’s UI has remained; some see this as good design, others as inertia and fear of user backlash.
  • Power users rely heavily on muscle memory; even small shortcut changes cause pain.
  • Multiple overlapping dialogs (“Save for Web (Legacy)”, “Export As”) are cited as evidence of UI accretion rather than cleanup.
  • Comparisons are made to other tools (QuarkXPress failures, Blender’s successful revamp, JetBrains IDEs) as cautionary tales about redesigns.

Performance and Hardware Evolution

  • Early 1990s usage on low-RAM Macs involved multi‑minute operations (e.g., Gaussian blur undo).
  • SGI workstations, later Pentium II machines and G3 Macs, are remembered as high-performance Photoshop setups.
  • Some users find modern versions sluggish compared to older CS-era builds, even on powerful hardware; others stick to older versions for snappiness.

Source Release, Licensing, and Preservation

  • The released Photoshop 1.0.1 code is praised; there’s appetite for similar releases (Illustrator, Fireworks, Windows XP, etc.).
  • A GitHub mirror of the code likely violates the Computer History Museum license, which forbids relicensing/posting elsewhere.
  • Software preservation efforts (e.g., Software Heritage, personal archival projects inside Adobe) are discussed, including challenges with lost media and missing early Illustrator code.
  • Ideas are floated for time-delayed source escrow services or integrating source submission into copyright registration.

Architecture, Frameworks, and Code Structure

  • Photoshop 1.0 relies heavily on MacApp; this explains missing function definitions in the released code (they’re in the framework).
  • Some commenters advise learners to focus on fundamental imperative structure first, then let abstractions emerge, rather than starting from patterns/OOP.
  • The code is admired for its structure, but several readers admit they struggle to fully grasp a large, framework-heavy 1990-era Mac app.