About

The official blog of Team Mach-II and is the best place to stay up to date on all things Mach-II.

Open Source: Is Build It Bigger Faster a Sound Long Term Design Plan?

Recently, I was discussing the state of economics with my brother. He is really into history and economics (having a degree in it) and offered an interesting opinion on regarding the run down state of several metropolitan cities in the US. Recent research suggests that the present of graffiti, broken windows and litter increses the pretty crime in the area. If you are intested, below is a link to an article about this theory (a link to the full article at Science magazine is not available):

http://www.newscientist.com/article/dn16096-graffiti-and-litter-lead-to-more-street-crime.html

It's called the "broken window" theory and whether you believe it or not is the crux of this blog post. The most interesting problem is that when the "broken window" events occur in the US that the more well to do (think wealthy) leave the area and leave the problems behind instead of participating to fix them. The US itself has a small or rather large (ironic) problem of having a large amount of undeveloped land that allow for urban sprawl. Countries such as Japan do not have the area in which to continually push urban environments out. This encourages people to participate and fix problems instead of leaving the area so they can be ignored. I've sort of dubbed this the "build it bigger faster" theory since you can just build bigger without addressing the shortcomings of your archtictural plan. Notice that it is not the "build it better" theory.

more ...

So is the "build it bigger faster" theory a sound long term design plan for open source software? Do more and more options to accomplish essentially the same task make a better piece of sofware? The answer to both questions in my opinion is a resounding no. The "faster is better" theory does not work either unless you have great software architecture in place. Implementing new features without pause or forethought is dangerous at best and a possibily a harzard to your health if things go hopelessly wrong. This type of development is an easy to get into because it is any easy way to please users quickly and some people have dubbed this "cowboy coding". However, it leads to poor architectural choice down the road and literally can paint you into a corner. While it is not a hard or fast rule, projects that frequently publish "upgrade guides" when new versions are released indicate the use of the "build it bigger faster" theory. Upgrade guides are usually written to help users "fix" their code because the sofware project made poor architectural choices that require revisions later on in order to make up for shortcomings.

Good architectural choices leads to a little thought about goal for most projects called backwards compatibility. I've talked with many people before about Mach-II and why Team Mach-II always ask if new features are backwards compatible. For example, Mach-II 1.8 runs application written against Mach-II 1.0 (based on our dealings with people that have actually made such a large upgrade leaps). Selling backwards compability is difficult to do becaue it is a long term concern whereas the availability of new feature "X" is a short term thought. Most of us think about the short term goals whereas long term goals usually take a back seat (usually to our own detriment). A good pragmatic programmer uses a blend of short term and long term goals to build better software.

Mach-II's development goals are a blend of short term and long term goals. We have moved to more frequent release schedule (usually two releases a year) to stay in line with new features however stay true to our backwards compatibility commitment. All new feaures we develop always has enough time to "ferment" and develop a nice "bouquet" instead of hurriedly pushed into production as if it's boxed wined.

So what about this "broken window" theory? Well, it has to do with abandoning software features because they "cannot be fixed" so they can just be rebuild again better. This is just like the inner city where people (who can afford it) just move to the suburbs instead of fixing the problem. This happens all the time in the world of software where it's easier to just rebuild it instead of building it better in the first place.

Lastly, building it better requires time for upkeep and better planning. For example, if you build a 6,000 square foot house and plan on maintaining it yourself -- it would require more of your time for upkeep than a 2,000 square foot house. This same analogy applies to open source since as the code base grows in size it takes more time to keep maintained. It's another reason why Team Mach-II is really pragmatic in what goes into the framework and why we offer a lot of extension points instead of including everything AND the kitchen sink.

In closing, we use the "build it better" theory albeit at a slower pace than other projects. Where flashy features may attract an user base, but stable and well architected features keep an user base happy. Wouldn't you rather focus on maintaining your application instead of having to update your application with "upgrade guides" just to get feature "X"? This is why it's important to think about backwards compatibility and long term goals when designing your application.

[hide extended entry]

0 Comments | 0 Trackbacks | Articles | Send
Posted 10/25/09 @ 5:45 AM by Peter J. Farrell

Mach-II Glimpses: What We're Up To Lately!

I thought it would be cool to let you know what the Team has been up to lately. We're glad to welcome Adrian Scott to Team Mach-II. His bio, photo and complete list of life ambitions are forth coming. Welcome Adrian -- we are happy to have you!

Kurt

"Pretty much completely rewrote the event-bean command" because of all the new stuff!"
"I started a nice unit test [with MxUnit] that throughly tests all the new code in event-bean."

Rock on Kurt! Keep cookin' on that code. Kurt is an un-sung programming powerhouse on Team Mach-II. He deserves more credit than he publicly gets.

Adrian

"Planning out a series of beginner M2 tutorials. They'll be a pretty sweet resource."

Way to hit the ground running Adrian!

Peter

"Writing documentation for the view tag library and the loop criterion attribute of cache-clear."
"Building out some tools for the tools tab of the dashboard. RegEx tester and scribble page tools are forthcoming."
"Coordinating on the last 10 tickets of over 180 tickets filed for 1.8 Simplicity."

Feels kinda strange commenting on myself, but consider myself colored busy this Fall.

Matt

Attending SpringOne2GX: "Brain already going a mile a minute and that's only from the opening keynote."

I'm sure Matt will be back with even more Mach-II vision ideas. We're really research new stuff for 1.9 and 2.0!

Brian

"Working on some more Mach-II QuickStart screencasts."

Brian has done three great screencasts be sure to check the latest (as of the date of this blog post): Introduction to Mach-II events Part Two http://bit.ly/mCdVJ

Well, that's the quick update for this week. More to come soon.

Announcements, Dashboard, Mach-II 1.8, Mach-II 1.9, Mach-II 2.0, Resources | Send
Posted 10/20/09 @ 12:15 PM by Peter J. Farrell

Mach-II Screencast - Introduction to Mach-II events Part Two

Happy Friday! I'm writing this post to point out that we have a new screencast available for you. This brief video continues to discuss events in Mach-II, illustrates the syntax for announcing events programmatically, and touches briefly on the event queue.

I also wanted to point out that I will be at CFinNC this weekend, so if you want to talk Mach-II or anything else, please do say hello! Since it'll be tough to find each other if you don't know what I look like, here I am. Enjoy the screencast!

http://vimeo.com/7094157

5 Comments | 0 Trackbacks | Resources, Training | Send
Posted 10/16/09 @ 6:35 AM by Brian FitzGerald

Proposed License Change for Mach-II 1.8

With the upcoming release of Mach-II 1.8 we are strongly considering a license change for Mach-II from the Apache 2.0 License to the GNU General Public License Version 3 (GPLv3) with a Classpath Exception. After much discussion we feel this is the best decision for the future of the project.

Please read the following draft announcement of this proposed license change and let us know your feedback. Unless you're in an unusual situation in terms of how you use Mach-II, this license change will have zero impact in terms of how you are able to use Mach-II with your projects whether they be commercial or open source.

If you have specific questions or concerns about this license change that you don't want to address on the public list or via comments to this blog post, please feel free to email us directly at team at mach-ii dot com.

Please note that at this point this is a PROPOSED license change. We have not made the final decision to make this change and wanted to hear from our users before we did so.

Thanks in advance for your feedback!

==========

Mach-II License Change

With the release of Mach-II version 1.8, the license under which Mach-II is distributed is changing from the Apache 2.0 License to the GNU General Public License Version 3 (GPLv3) with a Classpath Exception. Given the plans we have for upcoming versions of Mach-II, we feel that this license change is best for the future of the project and for our users.

Why is Mach-II changing to a different license?

Changing to the GPLv3 License with Classpath Exception will:

Ensure that changes made to Mach-II are contributed back to the project. We hope this will help foster and grow the community around the Mach-II project, which will benefit all Mach-II users.
Allow us to leverage additional existing open source libraries when needed. The GPL license and its variants are the most predominant licenses used in open source projects. With an Apache 2.0 License, Mach-II is not able to take advantage of any existing GPL code. With the GPL License, Mach-II will be able to leverage open source code released under practically any license.
Reduce the potential for forks and derivative projects. The development of Mach-II has required more than nine man years and nearly $700,000 of effort (based on COCOMO) to date. We want to protect that investment for the benefit of the project and our users.

In addition, we feel that the Apache 2.0 License is more appropriate for complete applications than it is for frameworks and libraries such as Mach-II. In our opinion, the GPLv3 License with Classpath Exception is a more sensible license to use for a framework.

Does this license change affect Mach-II users?

No. You may continue to use Mach-II free of charge and without restriction in all of your projects.

Does the GPLv3 License mean I have to open source my application code that uses Mach-II?

Absolutely not. The GPLv3 License is itself a copyleft license, but due to the Classpath Exception included in the new Mach-II license, you are free to use unmodified versions of Mach-II in any project, whether it be open source or closed source, free or commercial.

I have a Mach-II application that I distribute. Can I still distribute my application bundled with Mach-II?

Yes. If you are using an unmodified version of Mach-II, your application may be distributed as part of the GPLv3 + Classpath Exception License.

If I make changes to the Mach-II core for my own or my company's use and don't distribute the changes, do I have to make these changes available as open source?

If you make changes to the Mach-II core and do not distribute the changes as either a standalone modified version of Mach-II or bundled with an application, you are not required to make these changes available as open source under the terms of the license.

We strongly encourage you, however, to share your new features in Mach-II and ideas for changes with the project so that they can be considered for inclusion in a future version of Mach-II. This benefits the Mach-II project and all its users.

If I make changes to the Mach-II core and distribute these changes either as a modified version of Mach-II or as part of an application, do I have to make these changes available as open source?

Yes. Under the terms of the GPLv3 License, any changes made to the Mach-II core that are distributed either as a modified version of the Mach-II core or as part of an application must be made available as open source. This does not mean, however, that the application being bundled with the modified version of Mach-II must be made open source. Only the changes to the Mach-II core itself would fall under the copyleft provisions of the GPLv3 License.

How does this affect the licensing of previous versions of Mach-II?

Previous versions of Mach-II will remain licensed under the Apache 2.0 License that was applicable at the time of their release.

Where can I get more information?

If you have concerns about how this license change affects your Mach-II projects or have general questions that are not addressed here, please send an email to team@mach-ii.com or post to the Mach-II Google Group and we will be more than happy to assist you. If you want to learn more about the GPLv3 License, please refer to the GPLv3 license page, the GPLv3 FAQ page, and the Classpath Exception page on the GNU Project web site.

0 Comments | Announcements, Mach-II 1.8 | Send
Posted 10/13/09 @ 2:41 PM by Matt Woodward

Team Mach-II Meeting Notes - 9/29/2009

If you're interested in learning more about what's going on inside the Mach-II project, make sure and read our latest team meeting notes. As always we like to be completely open about what we're doing in order to get early feedback from our users. There are a couple of references to "new features" in the notes that we'll be announcing once they're more fully baked. We promise you'll like what you see!

0 Comments | Announcements, Mach-II 1.8, Mach-II 1.9, Mach-II 2.0, Training | Send
Posted 10/7/09 @ 1:48 PM by Matt Woodward