Frontier Open Sourcing

posted May 18, 2004
in Iron Lute

Frontier will apparently be open source in the near future. I've actually spent a significant time with the product, and I have an interesting perspective on this issue as I have a project started in no small part because of the closed nature of the Frontier code. (A project, I might add, that I really, really, really wish I could get back to, but a guy's gotta eat.)

So I ask myself, as someone who might be interested in developing the product, what does an Open Source Frontier bring to the table?

First, the licensing issue has not been worked out. One thing that can wipe out all value up front is a restrictive license, such as one that ends up effectively only allowing Frontier to be used to run Manila.root or Radio.root. You've got to be able to rip out a chunk of Frontier and use it to run your own, independent application; I'd be perfectly fine with the LGPL or the GPL which both require source code to be provided to users on request, fully Free. I'd suggest the LGPL; dual-licensing GPL/commercial is another possibility but may or may not inhibit contributions.

What does the Frontier kernel bring to the table, and what value does it have?

I think that largely covers the Frontier Core as it is being released. My final conclusion: I am positive about its release, but only cautiously optimistic about its value in the current environment. If it had been open sourced several years ago, it would have much more value to attract developers. It's bringing value to the table, but also a lot of bugs and work that needs to be done. Quality of the code is paramount; if it's undocumented and opaque, I don't see it ever collecting enough developers to matter.

As for what it means to me personally w.r.t. Iron Lute: Iron Lute is in stasis anyhow, so I can afford to wait and see. However, I don't expect that it will be worthwhile for me to try to merge my code back into an existing project, code that would require a deeper integration with Python on the Frontier side before it mattered anyhow. I expect that at best, a look at the Frontier code might teach me something, but I don't expect to be terribly surprised by what I see in there. One of the reasons for starting Iron Lute may be defunct by now but I'm far enough in that it's worth just continuing on. Assuming I can ever get back to it, Iron Lute will continue to offer a lot that even a retro-fitted Frontier won't be able to match for a while.

Addendum to initial post: Looking around, there are two things I forgot to talk about in the original post.

First, Frontier does have good support for non-programmers, especially in the Macintosh world. This is a very legitimate offering and would be an excellent niche for the Frontier kernel to deliberately pursue. Scripting in the Microsoft Windows environment is also largely a wide-open field; I forgot about this one because I've been living in the Linux world for so long now, where scripting is largely a given; in fact one must choose from an embarassing profusion of languages.

Second, the technology in Frontier, as useful as it is, is at the end of its life, I believe. You can see a hint of that in my ODB description above, where the technology is obsoleted and I think the best course of action would be to replace it with something else. In fact, I think that one of the best things an Open Source Frontier could do is take the plunge, sidle up to Python, and work on becoming a Python application that also happens to run Usertalk.

Why? First, Python is a sophisticated and developing language that allows for a lot of things that UserTalk doesn't, but really should. There are a lot of features in Python that would allow for even simpler APIs for beginning scripters. Second, it opens up a whole new technology world for Frontier with minimal investment; database APIs, real GUIs, and yes, even the possibility of integrated Iron Lute ;-)... but seriously, Frontier would probably be best served by this style of integration because it would benefit from the work of a much larger community. Nobody in the Frontier world is going to tie into GTK or QT, nobody's going to integrate with Linux stuff otherwise.

Frontier's best hope for continuing relevance is to focus on what it does better then anybody else, being a powerful scripting environment for beginners, and migrating off of its internal proprietary technology as quickly as possible. Honestly, I deeply respect Frontier, because it was literally a decade ahead of its time when it first came out. However, it is now about five years behind the time, and rather then trying to "catch up" with a small community, it would be better served by trying to connect to a modern one.


Site Links


All Posts