Scripto, itself, is based on etherpad-lite, with a ton of other code added to support various other features necessary to support the shows and was written by some contract employees.
Really the last time I was lead that we had an issue with the server going down was a third-party component that had a bug, and it came down to me deploying it in a hurry because we didn't have a good release process and I was tired from my other job. So I believe there were project management issue which I should have been more assertive over. But if I had money then I would consider suing regarding the use of terms like "amateur coder". I started learning software engineering when I was 8 years old (32 years ago), taught myself object-oriented programming in middle school. I have studied software engineering curriculum for many years online and also developed my own philosophy and practices around software engineering focused on feedback loops of different types and levels. I am a very good software engineer, not an "amateur coder".
Are there editor plugins like this for paired / multi programming? Is it just that the problem of "programming" is a lot more complex / open ended than show script development / execution? It seems like they have a lot of similarities.
Getting multiple people to agree on the same tool may be a big part of the battle, but surely there are some comparable programming tools out there.
VS and VS Code are going to support this. Should be neat when it comes out.
To answer your question, yes, there are multiple good collaborative code editors out there. The software was originally based on Etherpad, and after a year or two I switched it over to Etherpad Lite. I don't know if they now are based on something else at this point, I doubt it -- maybe their new "Showrunner" has a different core. But for something just like that for code, there is this https://www.npmjs.com/package/ep_codepad. Probably the best option though would be something like Cloud 9 https://github.com/c9
In case anyone is interested in my own take in general on this software, I will write a few comments here also. We started working on it in 2011. I consider this to be a cautionary tale for 'freelance' developers working for startups everywhere (more on this towards the end).
I solved most of the key technical challenges that enabled the main Colbert Report writing group to start using the system well before 2015 (I forget when the main group started using it mostly full time, maybe 2014). We had a lot of problems, but certainly nothing catastrophic every few weeks the way Rob suggested. One note about this, the first request I made (and I repeated multiple times) to Rob was to hire a professional quality assurance engineer to help with the release process, and this was never done.
Some of the key technical challenges that I solved:
1) how to make a system for TV writers that works like Etherpad and has a few other features. This is how the problem was originally described, and I took the most direct approach -- I built a prototype based on Etherpad, which was a Rhino (JS in Java) and Scala program. (The other sort of 'runner-up' for developer selection had presented a prototype built from scratch with zero actual collaborative functionality.)
2) reverse-engineering the partially text/partially binary-based document database for ENPS and creating JavaScript code to read it.
3) full-text document search for the script document database (more than 1GB of data) -- there were multiple approaches, one thing that mostly worked was based if I recall on redis and https://www.npmjs.com/package/natural, then later I rebuilt it on Elasticsearch.
4) a Google Spreadsheets-like collaborative realtime rundown editor
5) outputting script and rundown data as PDFs to match their old print-out format
6) how to deploy the software. I built a single all-inclusive Docker container starting back in January 2014 (they later took it apart, which at the time the component infrastructure for Docker didn't make that a good trade off, now is a different situation).
There are a few lessons I took from this project:
-- if you find yourself working full-time as a 'freelance' developer for a project for more than a year or two, you are probably going to get screwed. For the last few years I have been careful to explain up-front that if I work full-time on a project for a significant amount of time then I will need equity.
-- be assertive in terms of project management. Sometimes this is hard to do because freelance developers may not always have stable income and that may make it hard to put your foot down. There were some core problems with the server administration, lack of resources, and release process that I would have been able to correct if I had more leverage (in terms of savings?) or balls. The server admin, back-end coding, tech support, and support for front-end was all on me, even after I had taken on another project in order to make ends meet. I should have insisted on more resources.
- Projects can be technical successes without them being satisfying/fulfilling in one way or another for all parties. Developers are usually skilled at development and not so skilled at navigating political problems. Good managers are worth their weight in gold because they take care of those problems (IMHO, managers who avoid dealing with those problems are probably not worth working with). It took me a long time to realise this. As I've gotten more experienced, I've learned how to deal with political issues and I can do that role if I need to -- but I'd rather not. So basically I tend to demand: give me a great manager or a lot more money ;-)
- Equity is fine, but it's often a big risk. Even more, asking for equity means placing you back into the role of having to deal with political issues -- because there are a lot of ways to screw people over when it comes to equity. Entrepreneurs often do that role because they like competing for money. Good entrepreneurs (the ones that will have successful companies) are good at making sure that they end up with the money -- just like you are good at writing code. You probably don't want to place yourself in competition with them. My philosophy: cash on the barrel head. I don't work for promises (though I have a bad habit of giving outrageous discounts to work on projects that I want to work on ;-) ).
- Project management is hard. A person who doesn't understand this is likely to be a really bad project manager. Most projects have lamentable project management. After decades in the industry I've learned innumerable ways to screw up a project. I have learned precious few ways to succeed dramatically -- and those ways can easily be pushed over by well meaning, but under experienced management. (And come to think about it, they can be pushed over by well meaning, but under experienced me). Any idiot can succeed when the situation is set up perfectly. The real trick is succeeding when everything is against you. Learn to play in hard mode -- it will help you in the long run.
- It's hard, but important to control your ego. In addition to not over-estimating your worth/ability I also mean not under-estimating it. All projects have risk. If, in a headstrong fashion, you demand to control everything that you think introduces risk, you assume that risk. Others then depend on you. If you fail, then you may destroy their dreams/livelihood/fortune. It is possible to put yourself into a situation where you have assumed all the risk for the project, but almost none of the consequences. People who will suffer the consequences, but control none of the risk will naturally be put into conflict with you. It pays to be careful. On the other hand, judiciously putting risk into the hands of those who are most able to mitigate that risk is wise. That person may be you. Before getting too deep into the project, make sure that you see eye to eye about this with your partners. Failing to do so can cause the failure of the project all by itself.
You seem like a passionate, genuine developer so I wish you good luck in your endeavours.
