Writing about Capturia while crediting OpenScreen
Separate upstream attribution, a specific maintenance change and verified results through Capturia notices and a bounded GIF timing example.
Describe a derivative project by naming its foundation, then explaining a specific contribution with evidence. A portfolio reader should be able to tell who created the underlying work, what changed in the version being discussed and how the claimed result was checked. Those are separate questions, and a polished screenshot does not answer all three.
For a developer writing about an open-source adaptation, Capturia provides a concrete example. Its README explicitly identifies it as an OpenScreen fork, baselined on OpenScreen v1.10.0 at commit 70e30c1f, and says most of its codebase is still OpenScreen’s work. I keep that relationship in the main project description. The useful career story comes from the decisions and changes that can be examined, rather than from making the foundation disappear.
Put the upstream relationship beside the project name
At the Capturia revision examined here, the attribution is prominent, before the feature list. It also says Capturia is not affiliated with, endorsed by or supported by OpenScreen, and directs Capturia issues to its own tracker. These details tell a reader both where the software comes from and where responsibility for this derivative sits.
A suitable opening is: “Capturia is an OpenScreen-based screen recorder and editor that I maintain.” A feature description can follow, with its own evidence. Calling it an original recording engine would imply a different origin. Listing only Electron, React and Rust would describe technologies while leaving the important project relationship unexplained.
Keep the attribution close enough to survive common ways people encounter a portfolio. A project card, a README and a short presentation may be read independently. Each needs enough context to prevent a misleading impression. The longer page can provide the upstream link, baseline and detailed contributions; a short card can still say “OpenScreen-based.”
This is consistent with ACM’s Code of Ethics: principle 1.5 calls for credit to the creators of ideas and artifacts, while principle 1.3 calls for honest statements about capabilities and limitations. Neither principle requires pretending that maintenance has no value. They require describing that value accurately.
The arrow describes a documented project relationship. It does not assign every current file to one person or certify that all upstream changes were integrated correctly.
Separate four kinds of claim
Before writing a case study, make a small claim table. The distinction prevents evidence for one statement from quietly becoming evidence for a larger one.
| Claim | Evidence that can support it | What remains separate |
|---|---|---|
| Capturia derives from OpenScreen | Pinned README and license notices | Individual authorship of a particular change |
| The project documents GIF export | Pinned feature documentation | A successful export on a named machine |
| A revision changes GIF delay calculation | The actual source diff | Correctness of the entire native export pipeline |
| A particular workflow succeeded | A reproducible run with artifact and environment | Other platforms, inputs or releases |
A repository under my account is useful for locating work. It is not enough to establish that I invented all the code it contains. Likewise, a commit identifies a recorded change, but its presence alone does not establish who designed every part, whether someone collaborated, or what assistance was used. Describe the role and collaboration accurately when those details are available.
The table also helps avoid an overly vague summary. “Worked on performance” is difficult to assess. “Changed how whole-centisecond delays are distributed across GIF frames” gives a reviewer a specific mechanism to inspect. Whether that change improved a real export remains a question for the relevant test.
Follow one change from source to a bounded result
The Capturia revision 8204e3e3 includes a change in the GIF export source. Compared with its parent, the earlier code used the same whole-centisecond delay for every frame, calculated with integer division. The revised code derives each delay from the difference between successive rounded cumulative times.
Use 30 frames per second as a bounded example. A centisecond is one hundredth of a second. Truncating 100 / 30 gives three centiseconds per frame. Thirty such frames have declared delays totaling 90 centiseconds, although their intended source interval is one second. For 1,800 frames, the same calculation totals 54 seconds instead of 60.
The revised cumulative calculation rounds the ideal elapsed time at each frame boundary. At 30 frames per second, the first three cumulative boundaries are 3, 7 and 10 centiseconds. Taking differences gives frame delays of 3, 4 and 3. Repeating the distribution reaches 100 centiseconds after 30 frames and 6,000 after 1,800 frames.
Those arithmetic results were checked independently for this article. The inspected source also adds tests covering several frame rates and both one-second and sixty-second totals. Reading those tests establishes what the repository asks them to check; it does not establish that the native test suite was executed here.
The distinction between declared delay and observed playback matters. A viewer can interpret or clamp small delays, and the source has its own minimum-delay handling. The 30-frame arithmetic does not certify every frame rate, viewer or export path. No Capturia application, native test suite or GIF viewer was run for this case study.
A precise technical sentence is therefore: “At revision 8204e3e3, Capturia’s GIF exporter switches from a fixed truncated delay to cumulative rounding; at 30 frames per second, the inspected calculation totals one second of declared delays for thirty frames.” It identifies the project, revision, mechanism and bounded result without claiming ownership of the whole recorder or inventing a measured playback improvement.
Keep license notices and portfolio credit connected
The pinned LICENSE file retains the OpenScreen notices alongside Capturia’s notice. Its text explicitly says the added notice does not replace or supersede the upstream one. The MIT permission condition requires the copyright and permission notice to accompany copies or substantial portions of the software.
A portfolio credit does not replace those distribution notices. Conversely, including a license file does not make a project description that implies sole original authorship accurate. They address related but different obligations: preserving the terms attached to the software and communicating who contributed what.
The repository’s third-party notices also describe components with their own terms, including native libraries, model weights and fonts. A top-level MIT label should not become “every bundled component has the same license.” Treat the notice inventory as documentation to reconcile with a specific package, not proof that its contents were inspected in this article.
GitHub explains that its license detection compares repository license files with known licenses. That helps discovery. It does not turn a badge into a complete account of all artifacts inside an installer.
Write the paragraph a reviewer can follow
Try the exercise with one real change from an attributed project. Write four sentences: the upstream relationship; the specific change and revision; the evidence for its behavior; and the remaining boundary. Add a direct source link beside the statement it supports. If a test is only proposed, use future tense. If a test ran, identify its input, expected result and actual scope.
For the GIF example, the evidence paragraph can say that the source and added tests were inspected and that the 30-frame arithmetic was reproduced separately. A later native export run could add the exact build, operating system, generated file and viewer behavior. It would extend the evidence rather than rewrite the origin of the underlying project.
Finally, remove vague claims that the evidence cannot carry. Keep the contribution that remains. Clear attribution lets a portfolio show maintenance, debugging, integration and technical judgment at their actual scale, while giving the people behind the foundation visible credit.