-
Notifications
You must be signed in to change notification settings - Fork 24
Mach II: History, Philosophy, and Community
By Matt Woodward (matt@…)
- Hey, Hey, My, My: Open Source Can Never Die
- Mach-II History
- Mach-II Philosophy
- Mach-II: We're Community Driven!
- Onward and upward to Mach-II 2.0!
Since there's been a bit of a stir about the state of CFML frameworks recently, and having been in the middle of this sort of thing four years ago (was it that long?) with Mach-II, it seemed an appropriate time to share some thoughts that have been fermenting in my head as well as in discussions on the Mach-II team for quite a while. Specifically I'd like to share with everyone some of the philosophy underlying the Mach-II project, our development process, why we do things the way we do, and ultimately why we do what we do.
First, however, a note about open source.
First and foremost, once something is made open source it can never die. It's out there and if it's truly open source, you can do whatever you want with the code, in perpetuity. But when the discussion of frameworks comes up, almost without fail several people involved with the discussion make a statement along the lines of, "But what if I build my applications on Framework X and Framework X goes away? WHAT THEN?"
Frankly I just don't understand this sentiment. I always wonder if the person making the statement thinks that every application running on a particular framework that exists in the world is tied into a powergrid controlled by a large switch, and if the framework authors decide to not continue development on the framework, they can flip this big switch and cause all Framework X applications to break.
Of course it sounds silly when I put it that way, but it highlights the important fact that you aren't betting the farm, or your career, or anything else when you choose a framework. You're picking a tool for a particular job, and as I said above, that tool never goes away. It may change over time but the open source framework you're using, in that version and on that project, will run that project until you choose to do something different with it.
Even if you standardize on a specific framework (which I highly encourage people to do), if you architect your applications well, changing frameworks is not the massive upheaval people probably think it is. Chris Scott, Adam Lehman, and I built the application "LitePost" a few years ago to make the point that the same business logic (and in some cases views) can be used regardless of the MVC framework you choose. And again, you only have to worry about this if you choose to change frameworks.
To make my previous point in a slightly different way, even if a framework goes away your existing applications may never need to be touched. Frameworks have many benefits, but hassle-free maintenance is arguably the biggest one. If an application runs fine on an old version of a framework and you don't have any reason to upgrade, then don't! At least you have the benefit of knowing that when something does need to be changed it was built in a standard way that anyone knowing the framework can decipher immediately. This is a lot more than can be said for applications that were written using no framework at all out of fear of what might happen to the framework in the future.
In short, whatever framework you choose, if it works for you for the application you're writing in the here and now, then no fear of what might happen in the future should deter you from choosing to use a tool that, much like framework discussions in the CFML community, can never die.
With that out of the way, let's get a bit of a Mach-II history lesson and peer into the future to see where Mach-II is going.
Mach-II was first introduced in 2003 by Ben Edwards and Hal Helms. It was originally planned to be a new branch of Fusebox that would take advantage of CFCs, and was even originally named Fusebox MX. Ben and Hal quickly realized, however, that Mach-II was something altogether different from Fusebox and it needed a new name to reflect that fact. (If you're interested in seeing what Ben Edwards had to say about Mach-II in its early days, here's a nice interview that Fusion Authority did with Ben in 2003. For even more Mach-II history, check the history page on our wiki or our "10 Questions About Mach-II" blog post.)
A lot has changed in the six years since Mach-II was released. Most visibly the personnel has changed. Ben and Hal built an absolutely fantastic, clean, rock-solid foundation that Peter, Kurt, and I have been able to run with since Ben and Hal graciously handed the project over to us in July of 2007. Since Peter and I were heavily involved with Mach-II for two years prior to that (ever since Peter's Is Mach-II Dead... post in June 2005), we felt humbled yet confident being put in charge of the new phase in the long life of Mach-II.
So Mach-II has been around for six years, and we're still in the 1.x version number range. What's up with that? We discuss version numbers with every release, but as a general statement we decided early on to avoid "version number inflation," meaning every time we put a couple of new things into Mach-II we don't increment the primary version number. This also reflects our history quite well. We are still building on the great foundation of the 1.0 (and pre-1.0) release, and the true sign that it is such a great foundation is reflected in the fact that we can continue to cleanly add new features big and small to Mach-II without having to undertake any ground-up re-writes.
In recent versions of Mach-II we've introduced some big marquee features--things like modules, caching, logging, the dashboard, and others--but the fundamentals of Mach-II have remained relatively unchanged over its now-long history. This is good for us as the stewards of Mach-II, because in our opinion radical and rapid change to frameworks that people depend upon in their daily development work isn't wise. More importantly it's good for our users, who can rely on the sound foundation of Mach-II as they explore the new features we add with each new release.
As we approach a 2.0 release of Mach-II, we can look back and see that yes, a lot has changed in six years. We can also look forward to a 2.0 release and say with confidence that the best is yet to come.
Mach-II's source code has been available since it was first released, but in my opinion the project has only really become a true open source project in the last three years. By that I mean that having source code available for an application does not magically make it an open source project in a philosophical sense.
The philosophy of everyone involved with the development of Mach-II is that open source projects need to be open in every way. That's the only way open source works well, that's the only way everyone can participate effectively, and that's the only way the project can flourish. Participation by the users and community around the project at every phase is vital to the success of an open source project, so if a project is defined by closed-door development, long periods of silence, and "big bang" style announcements, to us that flies in the face of the spirit of open source.
This is why we (seemingly foolishly to some) announce ideas for features when they're little more than notions in our heads. This is why once our ideas germinate we document them and make them publicly available through our Specification and Feedback Process (M2SFP), which to us is the most vital phase of development. This is why we have nightly builds and encourage people to put the code through its paces early and often. This is why we have a publicly editable wiki, a public bug tracker, a public mailing list ... I hate to use this word since it's become so overused as the prototypical corporate buzzword, but it really is all about synergy between Team Mach-II and our wonderful, whip-smart, sometimes gracious sometimes cantankerous users. ;-)
We develop Mach-II for you, but without your constant feedback, Mach-II would not be a success. We want to build what you need, and the only way we can do that is by letting you become a vital part of the process. We depend on this, and for everyone who has contributed to Mach-II in even a seemingly very small way over the past six years, know that it is greatly appreciated, it did have an impact, and it has absolutely made a difference in what we do and how we do it.
In short, open source is much more about community than about the source code. "Community driven" isn't a catch-phrase on our t-shirts. Well, actually it is, but it's not just a catch-phrase on our t-shirts: it's how we do what we do, and why we do what we do.
Community doesn't happen overnight, and this is why we're so excited about the future of Mach-II. There's been a big upswing in participation from our community in recent months, and we want to encourage more and more of that. Give just a little and you'll have a huge impact, as many already have and many more do every day.
So how can you help us help our community? Get involved! You can ...
- Request a new feature. We can't possibly think of everything people would like to see in Mach-II. We may say no at first. Convince us. ;-)
- Tell us about a bug, no matter how obscure.
- Don't fear the wiki! Fix a typo, improve some wording, or contribute entire FAQs or articles.
- Share code samples or sample applications.
- Present on Mach-II at conferences or to your local user groups.
- Help a co-worker or fellow developer learn Mach-II.
At the risk of overstating things, without an active community, open source projects die, which again is why we try our best to think "community" with everything we do. If you see ways in which we could improve on this, or anything else we do, we absolutely want to know!
I'll close with yet another thanks to our wonderful community of users--strike that--contributors. Simply by using Mach-II you're contributing to the continued success of the project, and for that we can't thank you enough.