written by owen on 2014-Jan-10.

I was avoiding the whole repo discussion because public repos have been growing at a ridiculous rate. My contention is the millions of dead public repositories that did not need to be created. When the interest is in providing a "solution" (especially with volunteer work) being able to "complete" the project efficiently and quickly is the most important issue. A repo solves none of these problems - in fact it creates more problems than anything else. Because a public repo (repository) has to be "managed" and code is a complicated, you do not need a repo if the project is very small or empty. One has to have a basic idea of the platform on which the software will be built and a general road map before starting a "public" repository.

One would think that a starting a public repository increases collaboration and the success of a project but more often it is really just a dumping ground for unfinished projects and half ideas that never get any attention.

If you have ever been apart of a major code repo you will know what it takes to maintain a production/release build on a public project. You will always have that one person who will come in and try to add an Octree data structure or Dartlang dependacy for no apparent reason - then disappear and never contrib again. Or worst yet importing a complicated framework with a web of unsustainable dependancies, patterns and scaffolding that would internally fork the repository in a way that sends it spiralling into a bottomless pit of death.

A public repository takes an investment of time and work if it is to be successful. It may seem like a great way to collabourate on a project or social network, but it only works if there is a useful base and consorted effort from dedicated group of programmers. A public repo is a place where programmers invest thier time and expertise to build a software project while making said project visible to the general public so that they can intern learn from that hard work (ideally). A repo must be carefully managed and directed in order to prevent collapse. A public repo should not be created for every pointless project or hack that you think up.

I can even go out on limb and say that successful/popular repositories never start out as repositories. They are often either 1 person closed source applications or forks which have gained public interest because they grow too big to maintain. Before starting a public repository one should have a clear goal and a good inital release of code, this helps potential volunteer see what direction you are heading. And yes it helps if you have an audience of interested collaboraters but that is not necessary.

Do not start with a blank page or a empty framework on which you plan gain attention from programmers who you need to help you build it. Start a private repo on your own, develop your base idea then release it to the public. Spend the initial time and effort to build it yourself - at least the base, it will make you a better programmer. At the end of the day the goal is to create better programmers and LESS DEAD REPOS.

permanent link. Find similar posts in Articles.