GitHub is great. I can say that quite comfortably, even while explaining why I don't like keeping my source code there. I've received valuable feedback through GitHub. Other people have contributed to my projects, forked my main source code, and taken an interest in work that I put time and effort into creating. I appreciate that. When someone studies your code and cares enough to suggest an improvement, it means something.
But those positive experiences don't remove a concern that matters a lot to me: I don't control GitHub.
I can manage a repository, choose its settings, and decide which contributions to accept. The platform itself still belongs to someone else. Its rules, availability, and decisions about my account sit outside my administration. For something as important to me as my source code, that's a dependency I prefer to limit.
That's why I prefer keeping my source privately and sharing it through my own Lemon Cloud. I want more say over who receives it, which version I release, and how the work is maintained over time.
Some developers will make a different choice, and I understand why. Public collaboration can be exactly what a project needs. For my own work, though, convenience is only part of the decision. I also care about having a working environment I can manage myself and a clear boundary between developing something and publishing it to the entire internet.
GitHub has given me plenty to appreciate
Before getting into my concerns, I want to give the community its credit.
The feedback I've received matters to me. Contributions matter. So do the forks that show someone found enough value in my work to take it further. Those are good experiences, and I wouldn't want an article like this to sound as though I regret people taking an interest.
There is something rewarding about another developer looking at the same problem and seeing a possibility you hadn't considered. You may have spent so long working through your own approach that a different perspective helps you see it more clearly. Even when you don't accept a suggested change, the discussion can be useful.
GitHub makes that kind of interaction convenient. Issues, discussions, and pull requests give people established ways to report problems, ask questions, and propose changes. I understand why developers enjoy having those activities in one place.
I also understand the attraction of discovery. If I keep everything private, someone who might have contributed something valuable may never come across the project. That is a real cost of the approach I prefer, and I accept it.
My positive experience with contributors is part of why this decision deserves more thought than simply calling GitHub good or bad. I can value the collaboration while deciding that my main source code belongs in an environment where I have more administrative control.
I do not control the platform
This is my biggest concern, and it would apply to any external service I depended on in the same way.
GitHub's terms say that I retain ownership of the content I create. Uploading my own code doesn't automatically make GitHub its owner. But ownership of the work and control over the service hosting it are separate matters. GitHub's terms also provide for removing content that violates applicable law or its terms and policies, and reserve broad rights to suspend or terminate access, including immediately and without notice.
That leaves me with a practical question: how much of my project's continuity do I want to depend on an account that another organisation ultimately administers?
I'm not assuming that a takedown is waiting around the corner. I don't need to predict one to recognise the dependency. If access is restricted, I can't simply sign in to the underlying server and resolve the situation myself. I have to work through the platform's process.
GitHub does provide an appeal and reinstatement process, so it would be unfair to describe every restriction as irreversible or claim there is never any recourse. Still, that process is run by GitHub, and I would be waiting for a decision outside my own control.
For me, that is enough reason to avoid treating a hosted account as the only dependable home for my work.
There is also a limit to what platform removal means. GitHub taking down a repository cannot reach into my computer and erase an independent local copy. Keeping complete copies elsewhere changes the consequences considerably. My concern is the interruption to access, distribution, and collaboration around the hosted project, especially if I have allowed those activities to become too dependent on one account.
I want to be able to continue working and sharing an official version even if a particular service becomes unavailable to me. That feels like a sensible expectation for something I've created.
A private GitHub repository answers only part of my concern
The obvious response is that I could simply use a private repository on GitHub. That's true. GitHub supports private repositories with restricted access, so using GitHub does not require publishing my source code to everyone.
For someone whose main concern is public visibility, that may be a perfectly suitable answer.
My preference goes further. I also want to decide how the environment is administered, how I preserve the work, and what my process looks like when I need to move it. Making a repository private changes its audience. It doesn't put the hosted service under my management.
I don't assume that a system becomes more reliable or more secure simply because I run it myself. A private repository on a well-managed external service can be a better choice than a poorly maintained personal server. That is a practical consideration I have to take seriously.
What I value is having more direct responsibility for the choices. I want to be able to organise my own environment around the needs of my projects, rather than build those projects around whichever combination of features a particular service offers.
That preference is personal. Someone else may happily give up some administrative control in exchange for less maintenance. For the source code I choose to keep privately, I'm more comfortable accepting the work that comes with managing it myself.
Publishing source code should be a deliberate decision
A public repository makes source code available to people whose intentions I don't know. Some will want to learn. Some will want to contribute. Others may be interested in finding weaknesses.
The same visibility that makes a helpful review possible can make hostile inspection easier. If the full source is available, a reader can study the implementation directly instead of relying entirely on what they can observe from the running application. My preference is to avoid providing that access indiscriminately when the project doesn't need it.
That is a decision about exposure. It isn't proof that the application becomes secure because I keep its repository private.
I also want time to decide what is ready to be shared. A working repository can contain experiments, abandoned approaches, and changes that haven't become a supported release. I may want to keep that history for my own development without making every stage part of the public presentation of the project.
Imagine that I'm trying a different way to handle file uploads. I might change the approach several times before deciding which version is suitable. I'd rather choose the version and the context I share than assume every intermediate state should be available to anyone who happens to find it.
There is another reason to be deliberate: publication can be difficult to reverse. GitHub's documentation explains that making a public repository private does not make its existing public forks private. Those forks remain public and are detached from the original repository's network.
Once people have downloaded code, changing a setting doesn't retrieve every copy either. That's an ordinary consequence of distributing digital files, and it matters when deciding what to publish.
I would rather make that decision at a point where I understand what I'm releasing. Starting privately leaves me room to consider a public release later. Publishing first and assuming I can recover complete control afterwards is a much less comfortable position.
Private source code still needs proper security
Keeping the source private gives me more control over disclosure. The security of the software still depends on how well I build and maintain it.
A vulnerable application remains vulnerable even when its repository is private. Attackers can investigate a running system without being handed the original source. A faulty permission check doesn't become correct because fewer people can read the function that contains it. Security has to hold up when someone examines how the software behaves. OWASP's security principles emphasise secure design and layered protection rather than depending on obscurity.
There is a benefit on the other side, too. Public source can allow independent reviewers to identify problems and help fix them. But making a project public doesn't guarantee that qualified people will spend time reviewing it. I can't assume that visibility, by itself, provides the security work a project needs.
For my own projects, the position I'm comfortable with is controlled access alongside proper review. Keeping the source private should still leave room for trusted developers or security reviewers to examine it when appropriate.
I still need sound authentication and permissions, careful handling of input, secure configuration, and timely fixes. Credentials don't belong hardcoded in a repository merely because it is private. OWASP's secure product guidance treats these as development and maintenance responsibilities.
As a web developer, I also have to recognise what the browser receives. HTML, CSS, and JavaScript delivered to visitors can be inspected. Keeping the development repository private doesn't make that delivered code secret. Sensitive decisions and secrets need appropriate protection on the server side.
The reason I prefer private source is narrower and more defensible: I want to control access to the parts of my work that don't need unrestricted publication. That is useful to me, provided I continue doing the security work the software requires.
I still share my source code through Lemon Cloud
I do release and share my source code. I simply prefer doing it privately through Lemon Cloud.
That gives me a way to be selective about what I distribute and the context that accompanies it. Sharing can begin with a conversation about the project, the version someone needs, and what they want to understand or contribute.
I like that approach because the purpose of the exchange is clearer. Someone interested in a particular feature may only need an example or a specific release. Someone helping with a problem may need more of the project and an explanation of how it fits together. I want room to make those decisions myself.
A direct exchange also lets me explain limitations before someone treats the code as something it was never intended to be. If a version is experimental, I want that understood. If an example depends on assumptions about its environment, I want those assumptions included with it.
I prefer having this sharing process within the environment I manage, with the source and its accompanying explanation kept together.
There are limits here too. Giving someone a copy means they can retain that copy. Removing future access doesn't remotely delete files they've already received. Private sharing gives me more control over the initial distribution; it doesn't give me permanent control over every copy in existence.
I also need to be clear about permissions. Sharing source privately and releasing a project under an open source licence are different decisions. Open source involves rights to use, modify, and redistribute the work, rather than simply being allowed to look at it.
For me, being willing to help someone with code doesn't mean every project has to become a public repository. Lemon Cloud gives me a sharing arrangement I'm more comfortable with.
Version control does not belong to GitHub
Another reason I don't feel tied to GitHub is that Git and GitHub are different things.
Git provides version control. GitHub provides a hosted service and collaboration features around repositories. Git's history, branches, and tags aren't dependent on keeping the project on GitHub. Git can work locally and with a server I administer.
That distinction matters when I talk about wanting better versioning and control. I mean a versioning process that fits how I want to manage the work. I don't mean that moving the same repository to a private server somehow improves Git's underlying capabilities.
What I want is clarity. I want to know which version is the working version, which one has been released, and which earlier state I can return to if a change causes a problem. I want a useful explanation of why changes were made, instead of a collection of files that happen to have slightly different names.
I can design that process around a private environment. I can decide how working changes are organised and which points in the history correspond to versions I'm willing to share. The value comes from maintaining a consistent process and keeping its administration close to me.
There is a responsibility attached to that preference. A cloud folder containing several ZIP files doesn't automatically provide the same development history as a properly maintained Git repository. If I want dependable version control, I still have to use suitable tools and keep the history properly.
The appeal is that I have choices. I can use Git without accepting GitHub as the necessary centre of everything I develop.
I want a release process that fits my projects
The newest files aren't always the files I want someone else to use.
Sometimes a change is still being evaluated. Sometimes an older version is the appropriate reference for an existing installation. Sometimes I want to share a small example without turning the entire working project into a public download.
Those are ordinary development decisions, but they matter to me. I want the distinction between work in progress and an intended release to be clear to the person receiving it.
The same applies to modified copies. I appreciate forks and contributions, but I want people to be able to distinguish the version I maintain from an independent variation. If a modified copy behaves differently, I need that distinction to be clear before I can give useful help.
I prefer managing the official source and the distribution process through my own environment, where these decisions can be part of the way I share from the beginning.
I want to keep project knowledge portable
The source files are important, but they aren't always everything I need to understand and maintain a project.
An explanation of an unusual design decision can be just as useful as the code implementing it. Build instructions, release notes, and information about known limitations can become essential when I return to something after a long break.
If I let all of that context accumulate inside a particular service, moving the code may be the easiest part of leaving. I may also need to preserve discussions and other records that don't travel with an ordinary Git clone.
GitHub's own backup documentation distinguishes between backing up repository history, backing up a wiki, and preserving selected metadata. It also explains that migration archives do not include every category of project data. That is a useful reminder that copying the repository is not automatically the same as preserving the whole project.
For my own work, I want the essential knowledge to remain understandable outside the service where it was first recorded. I want to be able to open the project elsewhere and work out how to build it, which version matters, and what I need to watch for.
That also shapes how I think about integration. A convenient automation can be useful, but I want to understand what would be involved in replacing it. I don't want to discover, at the moment I need to move, that the project depends on a chain of features I've never documented.
Keeping the main source privately doesn't solve this automatically. I could create an equally awkward dependency on my own setup. The habit I want is portability: maintaining the code and the knowledge around it in forms I can understand, preserve, and move when necessary.
I value contributions without making every project public
One of the more personal reasons for my preference is that I want to decide how much public maintenance a project takes on.
I appreciate feedback, but reviewing it still takes time. A suggestion may be useful and still require investigation. A contribution may solve one problem while raising questions about compatibility or future maintenance. Someone else's enthusiasm doesn't remove my responsibility to understand a change before accepting it.
That's part of development, and I don't resent it. I simply want to choose the scope of it.
Some projects are suitable for a broad community. Others may be small tools, experiments, or solutions built for a specific purpose. I don't want the mere fact that I've written useful code to become an expectation that I will turn it into a general product and support every possible use.
For example, a tool designed for one workflow may attract requests to accommodate several different workflows. Each request may be reasonable. Taken together, they may turn the project into something much larger than I intended to maintain.
I want room to say that a project will stay focused. I also want room to stop developing an experiment without feeling that an incomplete public roadmap is waiting for an explanation.
Private sharing can create expectations too, so I still need to be clear about what I'm offering. I prefer beginning with a smaller, more deliberate audience and expanding when I have a reason to do so.
I don't measure the value of every project by how visible it becomes. If it solves the problem I built it for and helps the people I choose to share it with, that can be enough. Public reach is something I can pursue when it supports the project, rather than a requirement I place on all my work.
Self hosting brings work that I have to own
There is an easy way to make this argument sound more attractive than it is: talk about control and skip the maintenance.
I don't think that would be honest.
Managing my own environment means accepting responsibility for its operation. Updates, access management, storage, and recovery don't take care of themselves. If something goes wrong, I need a way to diagnose it and restore the work. I can't treat the word private as evidence that those responsibilities have been handled.
Backups deserve particular attention. Keeping the only usable copy on a server I control would leave me exposed to the loss of that server. I want independent copies and a recovery process I can rely on. Version history helps with development, but I still have to consider the loss of the system holding that history.
There is a time cost as well. Time spent maintaining the environment is time I could otherwise spend writing software. For a developer who wants to minimise administration, an external service may be the more practical option. I can respect that choice without making it my own default.
Self hosting also doesn't remove every outside dependency. A hosting provider, an internet connection, a domain, or another underlying service may still be involved. I remain subject to applicable laws and to the terms of services I use. Moving away from GitHub gives me a different arrangement of responsibilities; it doesn't make the project independent of the world around it.
What I want is enough direct control to make my own operational decisions, combined with enough preparation that a failure doesn't leave me starting again.
If I choose that responsibility, I need to follow through. The benefit of managing my source privately depends on the care I put into the environment. I am comfortable with that tradeoff because having more say over the work matters to me.
I want GitHub to remain a choice
I don't need everyone to agree with my preference. I can see why a developer would choose GitHub for a public project, especially when discovery and outside contributions are central to what they want to achieve.
What I want to avoid is treating one platform as the unavoidable home for every piece of software I create. I want to decide where the main source lives, how I preserve it, and when I make it available to other people.
For my own work, Lemon Cloud fits that preference better. I can continue sharing source code while keeping the initial audience and release decisions closer to me. I can maintain a versioning process that suits my projects and accept responsibility for the environment supporting it.
If a particular project would benefit from being public on GitHub, I can consider that on its merits. The decision should follow the needs of the project and the amount of ongoing responsibility I'm prepared to take on.
I appreciate what GitHub makes possible. I just don't want my ability to maintain and share my own work to depend too heavily on it. Keeping my source privately, and sharing it deliberately through Lemon Cloud, is the arrangement I'm more comfortable living with.
Comments 0