I’ve recently been asked:
How come you’re putting all your plugins on GitHub? Have you abandoned the DXCoreCommunity site?
This post is an attempt to answer this question.
The Problem
The tech and structure underlying the existing DXCore Community Site is old and out of date. It’s an SVN repository hosted with Google Code. It’s a single repository that holds many plugins. The site is larger than I ever though it would be. We have over 100 plugins and their associated wiki pages and it’s “getting” out of hand.
Within the current structure, branching and merging is so much of a pain that I don’t think it’s been done in a very long time. Its actually an inertial barrier to making any changes at all.
With hind-sight, it should probably never have been created as a single repository of plugins. Rather it should have been an index to many repositories, each holding their own plugin project. However what’s done is done and porting 100+ projects out of a single SVN repository and into 100+ individual repositories (along with their various wiki pages and links between them) is a task that seems a little impractical to take on wholesale.
The other major pain point of the SVN based site, is it’s centralized nature. A single central repository means that it has a single central access management system.
ie Anyone who needs write access, needs to be given explicit write access. In addition there is no way to give access to only those parts of the project that make the most sense. Write access is site wide, or not at all. As the breadth of a project grows, so does this issue.
First Steps
The first step in solving any problem is to recognise it’s existence. In this case, I acknowledge: the community site is too big and unwieldy to manage properly, and it has been for some time.
The second step is to stop making it worse. If I can help it, I will not be adding any additional plugins to that site.
So how to move forward?
The Code
So far as the code is concerned, I’ll be doing what you have seen recently. Creating each new plugin within it’s own repository. Each repo will contain code, readme and releases (including binaries).
I will be using Git, because I believe I find it quicker, easier and more flexible than any other source control I have used before. The use of Git, along with isolating each plugin in its own repo, will make branching and merging much easier. This in turn will allow easier experimentation, and more innovation.
This means that there, will be many more repositories than before. This was always the case anyway, but the community site ironically didn’t do much to acknowledge the community outside it’s own walls. People already create plugins which are not a part of the site. They blog about them independently and even host them in different types of source control.
So in acknowledging that there are plugins beyond the community site, we justify the continuing need (perhaps a bigger need than before) for a site whose purpose is to provide a location for people to learn about the existence of such plugins.
The Community Site
This rise in plugin locations increases the need for somewhere to index them. Whilst I could repurpose the existing Community site, it’s worth noting that the single central access management system is as much of an issue with the wiki side of things as it is with the source code side.
The Community Site, or rather the tech that supports it, is not up to the task of providing a central location to locate useful plugins.
So we need a new community site which needs to be…
- Somewhere where pages can easily be edited.
- Somewhere that’s easy to backup.
- Somewhere that’s easy for others to contribute to.
Can you see where I’m going with this?
Yup… I decided I decided to depart the shores of Google Code and set sail for the land of GitHub.
Hosting the site using Git has a lot of advantages:
- Local Everything
Local edits mean you can use a local editor and all the speed and other features that come with it.
Local branching, merging and committing and merging, means you don’t need to reply on the server (or the speed of that server) to get almost anything done. - Push Technology
Pushing your website to a server in the same way you push your code is awesome. It makes revision control easy and rollbacks (if they are needed) are completely painless. - Fork Me!
The ultimate in open. Others can copy the entire site if they want, and make an even better index. Improvements can be offered back and absorbed without any permissions ever being allocated.
In addition there are particular advantages to hosting with GitHub
- GitHub Pages
A feature where a branch of a repository is treated as the source files of a website. This benefits from a backend system which compiles markdown into html. - Pull requests
A feature where someone forks code and makes changes. Later they can request the original repo pull those changes back into said repo.
This is entirely possible via email without GitHub, but much smoother with it. - Releases
A feature where any tagged commit can be elevated to a release which then can have associated binaries and release notes attached.
The new community site will be a pure index. It will not be responsible for any plugin code. It will not be responsible for any plugin readme file. It will likely have to contain a basic description of each plugin and might list any given plugin on multiple pages according to it’s categorization. However the plugins will not be hosted on this site and the plugin’s authors will retain complete responsibility for them.
Not hosting the plugin code or binaries gives the new community site an advantage over the old one. Every linked plugin is equal in the eyes of the community site.
The site can link directly to:
…without granting any of them special treatment because of their local status, because none of them will be local.
Licensing
The previous community site used the MIT licence. this was felt to be a lowest common denominator. It was understood that plugins hosted on the site were essentially anything as long as the original author was recognised. However not everyone wanted to use this licensing model. Now they don’t have to. Simply create a repository of your own (github or anywhere else), upload your code and add the license of your choice. Then let us know and we’ll add your plugin to our lists in all the appropriate places.
We’re live!
The first version of the site is already up and running at:
http://rorybecker.github.io/CodeRushPlugins/
It lists all of my most recent plugins and links back to the original community site for completeness. Go on. Check it out. If you’d like me to add your plugin, send me a link to your repo or blog-post and I’ll add you to the list. If you’d like to help improve the look and feel or content of the site, Fork it! and send me a pull request.