Will Charlie be Open-Source?
Yesterday I wrote a weblog entry entitled, Charlie Takes Inspiration from Cuyahoga. Today the creator of Cuyahoga, Martijn Boland, sent me an email wherein he explained why he switched from using a handwritten Data Access Layer to using NHibernate. His goal with Cuyahoga is to support multiple platforms (Cuyahoga runs on .NET on Windows and Mono on Linux) and to support multiple databases. Martijn explained that the original plan to write multiple data providers that all implemented the same interface was, quite simply, a mistake. In Martijn’s own words, “For multiple database support, the provider pattern just doesn’t work.” The addition of NHibernate to Cuyahoga allowed him to achieve his goal of supporting multiple databases.
I have decided to use this example of NHibernate and Cuyahoga to answer the question, “Will Charlie be open-source?”
My first instinct was that yes, Charlie would be open-source. I have learned so much from the open-source projects contributed to the community by Martijn and similarly-smart jellybeans that I would love to give something back to the same community. If somebody could use Charlie to make a client happy, then that would be great.
But I have a few very real concerns about what would happen if I take the open-source approach. At the crux of each concern is that I plan to adhere to the advice from an aarvark that simple is better than complicated.
My first concern is that genericity leads immediately to complexity. If Charlie is provided as an open-source solution that multiple developers can use, then it needs to have some genericity built-in. Cuyahoga, for example, supports mutliple developers by supporting multiple databases. To achieve this goal required that the original handwritten Data Access Layer be replaced by NHibernate. The original handwritten DAL was so simple that even I could understand it and work with it—and believe me, my SQL skills are laughable. The transition to NHiberate was right for Cuyahoga and its goals, but is at odds with Charlie’s guiding principle that simple is better than complicated.
My second concern is that making Charlie open-source would limit (prohibit?) the use of commercial components. I have available a licence for telerik’s RadControls product and for ComponentArt’s WebUI product. If Charlie is provided as an open-source solution, it cannot use these best-of-breed components, and must instead use open-source components. Typically, commercial components are not only better than open-source options, but also much simpler to use. In this regard too, making Charlie open-source would mean that Charlie is at odds with its own principle that simple is better than complicated.
My third concern is that most developers like gimmicks, and I do not. (I am a designer first, a programmer second.) DotNetNuke for example uses the SolPart menu system whose fades and flips and farts appease developers, but horrify designers. Having crap like that added to Charlie would be to ignore the guiding principle that simple is better than complicated.
My final concern is that even if Charlie were open-source, no-one would use it. That would mean I had forced Charlie to endure the complexity of genericity, and to ignore best-of-breed commercial components, and for nothing. After all, there are many open-source website frameworks available for ASP.NET. Why add another one to the mix?
My current resolution is that if anyone wants to see the source of Charlie, I will send it to him or her. If that person wants to look at it, learn from it, play with it, or laugh at it, he or she can have it. If Charlie ultimately remains closed-source, it will not be the result of selfishness or competitiveness. Rather, it will be the result of my holding the principle of simplicity even higher than the principle of open-source.
If anyone reading this weblog entry truly understands open-source philosophy (which I do not purport to understand), and knows that I have made a logical error above, then please feel free to correct me.
by Alister Jones | Next up: The Object Primer →
----
I would love to see the source. I would also love to read the specification but the link is dead.
I can't see any contact details for you though. Any chance you could email me?
peter dot morris at 2ed.com
Post a Comment