Recently we struggled with a difficult issue in WordPress Multisite. We take care of a network of sports weblogs. Each is for a different sport and not all the domain names sound the same.
We have a master install at say worldrecords.org (sample name, not our client's site). Logins only are SSL and all take place at worldrecords.org. An account at any site gets you access to all the sites. Hence login and password takes place at the master domain. Most visitors are not even aware of the domain switch during login.
When people would lose their password, the password reset email would not come from skatinggolds.org or lugegolds.org but from worldrecords.org. Many people would not recognise the domain and would delete the email without clicking and finishing the password reset. Worse yet the email might be considered spam by spam filters.
There is no code in WordPress Multisite to make sure these password reset emails come from the correct domain for account (original signup domain or site from which the password request came). It would be a day of coding to write something like this up. Longer to troubleshoot it. It would be weeks or months of work to try to push important code like this through WordPress Core Trac. If possible at all. WordPress Trac is very political and there are dozens of gatekeepers who like nothing better to mark tickets edge cases and close them peremptorily (1).
Here is where GitHub steps in.
The very brilliant Eric Teubert (2) logs and posts his small but important WordPress enhancements (62 of them!) in GitHub with just enough annotation that other developers can find his work. It's very easy for us from our own GitHub account to fork his code and add improvements and enhancements of our own and for Eric to test and merge them to his master gist.
In this particular case, Eric has posted an excellent fix for our issue: Multisite: Password Reset on Local Blog.
Our client's password reset emails now go out from the domain from which the password request was made. Users get those emails and click the links and have their new passwords.
Hundreds of hours of customer support are saved at our client's sports networks. Hundreds of unhappy clients are made happy now. A win for everyone, thanks to:
- the brilliance of GitHub as an open source collaboration environment.
- the generosity of Eric Teubert to post his solutions.
Without GitHub it would just be too much work to share code properly and Eric would be unable to effectively show his generosity. Inertia would take over and hours would run out.
Developers develop on GitHub not in WordPress SVN as the tools are better
Arguably this kind of collaboration should take place directly on WordPress.org. There's no viable system for this kind of collaboration within a large community where many people do not know one another (SVN works fine in a smaller community with hundreds of developers mainly know one another: that's how WordPress started).
Why, oh why will WordPress.org not take advantage of the rich ecosphere of GitHub for its plugin repository. WordPress SVN is nigh impossible for useful collaboration. One has to contact the developer and acquire full contributor status before even starting to work together. This works as a huge brake on open source collaboration. Here's how open source collaboration works: You find some code, you don't know the person, you collaborate with hundreds of people per year.
Trying to get collaborator rights on even a third of the hundreds odd plugins we use actively would require hiring a full time person. All that energy basically evaporating like water in a desert. Good code gets wasted.
Solution: a native GitHub-WordPress SVN bridge
Due to the dislike of WordPress plugin repository keymaster Samuel Wood (Otto) to Git and particularly GitHub (2), the entire WordPress development community has to struggle with moving their code between GitHub and WordPress SVN via commercial service or plugins they've written themselves. We even have such a plugin free to the world but it was refused admission to the WordPress plugin repository.
A GitHub-WordPress SVN bridge would be much easier to write from inside WordPress.org. I hope one day Samuel Wood opens his heart and mind to Git and makes WordPress developers lives easier. A single day of coding could increase the velocity of collaboration on WordPress plugins by about three times. How about it Samuel?
(1). There are also hundreds of dedicated coders working really hard to improve WordPress: one does not exclude the other. In some cases, they are even the same people. For instance, a gatekeeper who likes nothing better to slam shut other people's important tickets yet writes a lot of good fixes for him/herself and his/her projects. A concrete example of such a person would be @nacin Andrew Nacin. Triage remains a thankless job.
(2). Generosity is a way of life for Eric. Here's his mission statement:
I help make podcasting accessible to everyone.
I develop the Podlove Podcast Publisher, the WordPress plugin for podcasters.
Unlike most plugin developers including Automattic (and Foliovision), Eric is true to the founding spirit of WordPress. His code is open and free and available from his own website. He only charges for support. He eschews recurring payments. To go back to those golden days of idealism without VC vultures circling the WordPress skies....
(2). In fairness to Otto, his dislike is grounded on GitHub's lack of open source credo (i.e. it's a third party service). The track record of third party services is not good. My counter argument here is that if GitHub abuses its monopoly position, WordPress could either switch over to Git and replicate much of the GitHub functionality or simply write a new bridge to the replacement tool of choice. I.e. GitHub's monopoly is illusionary.
Moreover GitHub charges nothing for public repositories so GitHub is effectively an open source service (subsidised by private repositories, mainly paid for by companies).