Every year when many of the SQLSaturday event leaders meet at the Summit the topic of improvements to the tools comes up. Certainly the site has seen changes  and improvements over the years,  plus at least two new coats of paint (on the public site), but it’s never enough (with software, it never is). Invariably the question that gets asked is ‘why can’t we help?’. It’s a fair question, and perhaps one that deserves a new answer.

Back in 2009 or 2010 we took a first crack at getting volunteers access to the source code and it just failed. Setting up a VPN, credentials, no test suite, no governance, just didn’t work. Keep in mind PASS was not a software shop then and getting good at that stuff takes time and expertise. Maybe it’s been tried since, but my sense is that its been just the HQ Devs making changes.

So if that is all the way on one side of the scale (super closed system), the far other side is  to open source it. Open source is also not simple. If you’re on the PASS Board you have to care about the potential loss of intellectual property. Scoff do you? No, there is no magic in the code, but it’s sweat equity and it’s a substantial part of what drives new members (and new email addresses for existing members) into the mailing list. Do you really want people forking it and spawning variations under different names?

Is there a middle ground? Sure. Let’s put together a straw man of what it might look like:

• PASS puts the source code into a private Github repo (because all devs love git!) along with a masked data set they can load/restore
• Write an agreement to get access to the source code and agree to not republish the code, plus convey to PASS the IP rights to new stuff
• Write the governance process. This is the hardest piece. Who will approve pull requests? Who decides which features get added? Who will do the testing? How often will releases be done (since PASS has to coordinate that)? Code standards. Rules about fonts and logos – all the stuff you deal with any dev shop.
• Down the road a little build a true dev environment where the latest code can be loaded and tested.

I’m not kidding about governance being hardest. There are changes I want that you don’t care about, fine. But what if I want it to work differently than you do? How do we decide that? How do we decide when to mashup with an external app vs building a feature? I can see having a committee to manage the process, but I’d hope for a lot of opportunity for event leaders to weigh in, perhaps even voting on change before someone invests effort to build/fix something.

We could do all of that and it might or might not work. Could be a huge win, could be we just argue about everything! Even assuming a win, it’s a lot of effort to get it all set up. So…what could we do to test the waters in more agile fashion?

What if we just did the first two steps above, putting the source in Git (might already be there, don’t know) and creating the access agreement doc. That’s what, a couple three days? Then, announce it. You want to contribute, sign up, look at the code, then email someone at HQ about what and how you propose to change something. If they say yes, you build it. If no, you work through the conversation about why. Nothing about the process needs to be secret, so you could just as easily write a blog post that explains the proposed change and get feedback before submitting it for approval.

If it really works, PASS will get a lot of email and a lot of stuff done that will require testing and release, causing perhaps enough pain to merit building out the test environment and a full governance process. If only a few people make changes we’ll have a lightweight process that enables that. If no one does anything, PASS will have spent a few hours that surely won’t end up being a total waste.

Is the risk worth the reward? The Board will have to weigh in on their side. What about us, the ones who want tweaks and twists, can we be work through non-trivial conversations about what to do or not do, or must it be anarchy where everyone has to have it their way and nothing gets done? Patience and transparency will be required. That seems possible, but not necessarily easy. There is rarely one right answer.

I also want to point out that this wouldn’t change the need to have devs on staff at HQ. We’ll need them for bigger features, other products, plus testing and release. They will get to essentially lead an open source project. Hard to imagine that they wouldn’t find that prospect exciting!

Fear kills ideas like this one. What if, what if, what if. We deal with that in two ways. One is to honestly consider concerns raised and find ways to mitigate them. The other is to clearly frame this as a trial, a proof of concept. Make sure we have a continued dialog about is working and what is not, and then use an open process to evolve changes to the process.

So, how do we get this done? Or, should we?

I’m looking for input on the approach. If you have a better one, blog it and send me the link. Have a suggestion for a tweak or see a concern not addressed? Post a comment. I’m putting a reminder on my calendar for December 8. I’ll come back to this post then, look at the comments again and any other ideas out there, then I’ll repackage it into a public letter to the Board to be published here on Dec 15, unless there clearly needs to be more debate. If someone else has a better approach, I’ll sell that one.

Grant Fritchey takes over the big chair Jan 1. If we hit the dates above he can have this in time to discuss at the January 2018 Board meeting and if he thinks its worth doing and can address any concerns raised there, we could see this up and running by the end of Q1. Wouldn’t that be an interesting way to start the new year?