I once learned that someone had presented a project I built as their own idea. I opened the repository. The commits still had the same names and dates.
The work had not changed. The story around the work had changed. That story moved faster than the evidence.
I had assumed that traceable code would also make its history clear. It does not. A repository can preserve a record. It cannot make people read it.
When a system became someone else's idea
Last year, I built a system for a college event. The idea was simple: software could make a difficult process easier. The work was not simple. I designed, built, released, and operated the system during the event. It became working infrastructure.
Later, I learned that another person described the idea to faculty as a personal project. I had shared it with him when we trusted each other. He did not develop the idea separately. He did not say that the system already existed or that I built it.
This was not a case of two people reaching the same answer. The idea moved through a relationship. The end of that relationship did not remove its history.
Trust gave him access to the idea. It did not change its origin.
Trust is weak access control
Computer science defines what a system permits. We use access control, ownership rules, and licenses. Ethics asks what a person should do after they have access.
No one broke into an account or copied code in this case. A person received information in trust and later removed its context. Authorization can say that someone could hear an idea. It cannot make a false claim honest.
The ACM Code of Ethics asks computing professionals to be honest, trustworthy, and fair. It also asks them to credit the creators of ideas and artifacts.
Ethical failures are often quiet. They happen when someone removes attribution, hides useful context, or lets a wrong belief continue because it helps them.
Why builders lose credit
The repository shows the real work: decisions, fixes, changes after user feedback, and imperfect code. That history is hard to explain in a short meeting.
In a meeting, months of work become a demo. The room sees the person who explains the system. It may assume that person made it because the explanation is the only evidence in view.
Clear communication is real work. A builder should explain their work. The problem is not talking. The problem is that a clear story can hide the people who did the work.
I confused auditability with recognition. Git made my work auditable. It did not make it visible.
Receipts are passive
An audit trail helps only when someone audits it. Meetings and project pitches usually need a fast answer. A confident speaker is easier to trust than a repository that nobody opens.
git blame can show who last changed a line. It cannot show who designed the system, operated it, or took responsibility when it failed.
Git can preserve history. It cannot make people look.
I once thought that asking for credit was self-promotion. I still dislike empty self-promotion. But silence can give someone else space to define the story.
The error grows
Credit is not only praise. It affects who people trust with the next hard project. Groups rarely rebuild a person's history from scratch. They ask who has done similar work before.
If the first answer is wrong, the error can grow. The wrong person may receive the next opportunity. The group may also miss the people who can take a system from an idea to production.
Write the story early
A private repository is useful evidence, but it is evidence in a closed place. Public documentation gives a project a dated record before a disagreement starts.
You do not need to make every repository public. A short project page, release note, demo, or architecture post can record:
- The problem.
- The date of the work.
- Your role.
- Other contributors.
- The release date.
- What happened after people used it.
Use exact verbs such as proposed, designed, implemented, released, and maintained. The word built can hide important differences.
Documentation does not stop dishonesty. It makes the true history easier to find. It is part of finishing a project.
What I got wrong
I made three mistakes:
- I expected the record to speak for itself.
- I left the public history of my work to other people.
- I documented the work too late.
I will now write about a system when it goes live. I will describe the work, constraints, and contributors while they are clear.
This post is a late record. It may not change every existing account. It records the project outside a private repository and outside my memory.
People may use an idea. They should not erase where it came from. The next system I release will have a timestamp for its code and its story.
