Seattle, WA
Quoted from epthegeek:When FAST came along, certain members of the PyPROCGame community wanted to add support for those boards to PyPROCGame and they were asked to not do that because the framework was built specifically to support the PROC -- so they forked the framework at that point and started MPF. When it started, it was very similar to PyPROCGame, but after Brian left and others took over it has evolved into a very different thing, and that's fine.
Upfront disclaimer: I work at FAST Pinball.
Just one quick point of clarification. I'm the "Brian" that Eric is referring to and the original creator of MPF. MPF was a clean-sheet design, not a fork of PyPROCGame. (Not that it really matters since they're both MIT licensed.) One of my design goals was to support all hardware platforms and devices, rather than being tied to the P-ROC only, so I designed MPF in a way that abstracted the hardware so you could plug in any hardware layer. (At the time I actually thought OPP would be the second pinball platform target since they started talking about that back in 2012. I started what became MPF in 2013, and FAST support was added in 2014.) I also had very early support for FadeCandy and some Pololu servo and stepper controllers and a bunch of other little things like that.
Prior to the creation of MPF, I had written several modules for PyPROCGame to add support for RGB LEDs, I think a match mode, OSC support, maybe a bonus mode or something? (These were not checked in to the actual PyPROCGame project because my fork needed some other changes to the core that didn't get accepted, but I think you can still see them in my GitHub account in my branch maybe? Obviously the modules I wrote for PyPROCGame are similar to the ones I wrote for MPF sine I wrote them both, though they are not plug-compatible because MPF and PyPROCGame are pretty different under the hood. Sure, there are lots of similarities because they are both pinball frameworks, and I choose to use Python and YAML for the same reasons Adam did originally for PyPROCGame (and I was comfortable with both since I'd been writing for PyPROCGame for a year). But of course there are similarities in all pinball frameworks. I mean there's only so many different ways you can do things. Just look at FreeWPC from the early 2000s or even Williams' APPLE from the 90s. The concepts of grouping hardware primitives into higher level devices, mode stacks, display stacks, heck, even the DMD dot data format... It's very similar, which is great. This is the value of open source. Build, share, iterate, improve, learn, repeat!
That said, I owe a HUGE debt of gratitude to the P-ROC community and PyProcGame, and I learned a lot from that community and have many happy memories and it kickstarted my projects and ultimately led to my current career in the industry.
BTW the other day someone joked that since I am now at FAST Pinball, I must've planned all this all along when I was working with P-ROC and creating MPF and all that back in the day. I actually just joined FAST last month, and while I wish I was cool enough to pull off an 8-year long con master plan, I have to admit that I'm not that cool. I just work there now because I think what they're doing is cool and they're local to me in Seattle and I wanted a pinball job and, well, they were hiring. 
