Thursday, September 16, 2010

YAF - Yet Another Framework: Giftware Versus Open Source

With the seasons changing and Fall fast approaching, it must be time for yet another framework (YAF) to show signs in the CFML world.  I'll give credit for this post to a tweet from Matthew Reinbold:

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.


  1. Peter, maybe you know something about this "stealth" framework beyond the context of the cited tweet, but the way I interpret the tweet it sounds like Matthew is playing with a not-yet-fully public framework that someone shared with him, and that he (Matthew) is about to "find out" if this framework has a valid/alternative approach scaffolding.

    And if that's the case, that would imply that the framework author IS trying to get some input/feedback on their project, if only from a limited audience at this point.

  2. @bcswartz, Actually I don't know anything other than the tweet. If the framework is already that far along as you suggest to be at a late alpha/beta stage, the time for feedback is already too late in my book. The jello is already in the mold and is pretty well congealed. The point of my post is that feedback to should start before any code is even written. It is clear that the author is soliciting for some feedback -- but doing so in private is not transparent and therefore you're already getting off on the wrong foot.

    *RANT* The CFML community as a whole is too wrapped up in secrecy. I'm always sickened to hear things like "Email me for a 'private' beta". I don't know where the concept of developing in the dark until it's ready to publicly release has come from. It could be because releasing your own code into the wild is a scary thing because it can and will be criticized. It's better to do it before code is written than afterwards in my book.

    The Mach-II BER list ( has become indispensable to anybody that can commit to Mach-II and we have some great discussions with the community on things. Even with my best laid plans for configuration / implementation, I've been "schooled" on the list many times. It's the different opinions and points of view that cause all of us to an unique perspective on things. This leads to better software.

  3. Historically the free software projects that are most successful long-term are those that are announced early and get input as early as possible. The biggest example being Linux:

    I can't imagine Linux would have turned out the same way it did had Linus Torvalds worked in stealth mode for a year or more and then sprung Linux on the world.

    To echo what Peter said, the feedback we get from Mach-II users before we write any code is of incalculable value, because we don't waste time writing things people don't want, or want to work in different ways than we might have guessed.

    And I guess I just don't understand working in secrecy either. If you have an idea, why not do a blog post about it and get feedback as early as possible? If you get no feedback then you can assume people aren't interested. ;-)

    Of course there's nothing wrong with writing applications as a learning exercise, though where frameworks are concerned I'd suggest studying the ones that are already available if you just want to learn, but if you're trying to solve a problem on a broader scale and intend to make the project available to others, I can't imagine why you'd code in the dark. The earlier you get feedback the better for everyone.

  4. @arwilliamson, design by committee does not work well or very fast. I hate to say it, but the best projects are always that are run by benevolent but loving dictatorships. You see in Rails with DHH all the time. Apache is run similarly but they call it a meritocracy. Still *somebody* has to make tough decisions and to have a "vision" for the project.

    I know many will disagree with me regarding this statement and I really don't care if they do:

    The "secrecy" is kept alive by things such as the NDA programs at Adobe and things like "private betas of frameworks". It appears that "knowing something you don't know" in the CFML world somehow makes you "special" and "more important" in our small world of programmers.

    Don't get me wrong here -- the NDA model does *work* for Adobe when it comes to ColdFusion as a product and I'm not criticizing their use of it. I shouldn't be translated to "open source" projects which I see all the time these days in the CFML world. People need to realize they need to be involved with the project they love. Nobody pays us at Mach-II to build new features -- unlike ACF where you wait for the new version to come out and you pay for the software. The drive on how features are selected are based on a totally different model. Adobe has been very clear that their model is customer driven and that customers != community in this sense (Terry Ryan at BFusion talked about this directly). It's a perfectly logical way to go about it for proprietary model, but I think most CFMLers have a hard time breaking from that mindset when it comes to open source.

    Education is where it's at. The problem no matter what you tell people they have have to think it for themselves. We can't program people the values of open source -- it's a learned philosophy!

  5. @Matt - you asked 'If you have an idea, why not do a blog post about it and get feedback as early as possible?'

    I can give you one good reason. People can and will take good ideas and try to make them their own, and turn a profit in the meantime.

    Now, in the framework world, its not likely to happen, but with other projects, it is a real threat.

  6. @boyzoid -- if that's a concern on a project, then I assume that means it won't be open source anyway. If someone wants to take an idea from an open source project and try to make a profit on it, they can do that at any point, and it'd actually be smarter for them to wait until the open source project does a lot of the legwork before coming up with their for-pay solution.

    I guess I just don't have that fear. I don't see it happen in the wild, and in most cases there's room for multiple variants of the same idea anyway.

    So from my perspective at any rate, if the project is going to be open source, I don't see any reason not to get feedback early. If you build a community early chances are anyone who rips off the idea will be seen just that way anyway, so it won't matter in the end.

    A great read on all of this is "The Cathedral and the Bazaar" by Eric S. Raymond if you haven't read it, specifically "Homesteading the Noosphere":