Playing with new ColdFusion framework that still is in stealth mode. Do programmers need another MVC/ORM set of scaffolding? Let's find out.
Before I take issue with having another framework pop up in the CFML world and why I feel that it is possibly detrimental to our small sect of programmers, I want take issue -- moreover -- more notice to the word "stealth" in the tweet. What bothers me there is a big difference between developing a framework for internal / personal use versus public consumption. If I was developing an internal "framework" for my personal use, having input from possible users of my "framework" really would not matter. I would be using it for my own needs; Programmer Paul doesn't need to put his own two cents on how feature Z should work. On the flip side, developing a framework for public consumption in a vacuum (i.e. "stealth" mode) is less than beneficial to all parties that possibly would use the framework. Therefore if Programmer Paul had interest in what I was doing, his knowledge can only make the "framework" better. This means that public interaction, even if it's just one person, is beneficial. You can't pay somebody enough to give you bold and honest views on stuff. This begs the question: How do you make somebody care? Developing transparently is key to building an user base. Without transparency in a project, you cannot call yourself an open-source project. I've found out in that most developers consider the main tenant of open source is that the code is freely available (i.e. the "license"). Giving users the software for free where the software is developed in a vacuum and there is limited means or encouragement to contribute back to the project is merely giftware*. Open source is much more than the license; it's about philosophy on how software should be developed and a community that rallies behind it. The big different, other than transparency in developing software in the open, is that interested parties will help you develop new features if you let them be "shareholders" of the project. As with anything in life, nobody cannot care about everything. Humans weren't designed to function that way. We make hundreds of decisions everyday on what we spend our time on, what is important to us and what we do so we are happy individuals. This is no different in open source software. Consider this situation:
If Developer Dave uses Project Perfect and finds a Big Bug, what encourages Developer Dave to contribute his fix back to the Perfect Project instead of just working the next Alluring Application that will make millions when it hits the world?
The answer to this is: nothing. Unless you are financially tied to open source to make a living, most developers don't count themselves shareholders in the project because they don't own it. Whereas if the project helps you succeed at your job, there is a reason to become involved in some of these projects. This is where being transparent, making people's opinions count and accepting (acceptable / valid) contributions into a project makes everybody in your user base a potential shareholder and champion of your project. Making this conversion of your user base to shareholders is something that needs to be cultivated from the start of the project. It's nearly impossible to make conversions when your project starts in "stealth" mode because it sets the "tone" of the project from the start. Transparency is the biggest reason in my book why 99% of all CFML "open source" projects are just giftware and will always be one-man operations. Giftware is just viewed by "Developer Dave" as a free tool where open source is more -- it's a community of like minded folks using the tool. All in all, the side effect is a better software. Therefore if you make philosophy and transparency #1 on your list, will you see your project succeed (provided it's a good tool too). Otherwise, you'll just be YAF that gets forgotten in 6 months time. * I want to attribute the term "giftware" to by good friend Matt Woodward. I heard it applied by him first so I can't take credit on the term.
