Frontier Open Sourcing

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?

• The "Object" Database: (Since it was named, the word "Object" has acquired a more technical definition, hence the scare quotes.) The Object database is a neat piece of code but is somewhat less useful then it used to be. Metakit in particular seems to have left the ODB in the dust. I like the interface the ODB offers, but I could create a very, very thin layer on top of Metakit to provide that functionality if I cared (especially in pure Python).

  I say the value depends on the quality of the code; get ready to hear this a lot. If it's high quality, it might be extensible to handle other datatypes, correct some of the worrisome bugs that sometimes pop up, and possibly support more metadata, which might allow for some more interesting program styles. If it's low quality, I'd say, the best thing to do is probably replace it with Metakit or a similar product underneath. You can easily match the interface that the rest of Frontier expects, you'll tap into a robust and current product, and hopefully the performance wouldn't be too bad... might even increase, I don't know. (The down side is the threading issue; metakit doesn't thread well. However, if you serialize access it's OK, and I wouldn't be surprised that's exactly what Frontier does internally anyhow.)

  My call: The ODB's most interesting feature today is it's interface: You just can't beat root.value = 3 for convenience. The implementation is probably defunct. However, the good news is replacing the implementation should be easy, the internal interface should be clean. If it isn't, big strike against Frontier. 

• The library code: Reasonably solid. Letting third parties in to extend it is probably a good idea. It has a lot of little bugs and quirks which Userland simply hasn't had the man-power to fix; for instance, Frontier's XML support continues to be dangerously quirky and needs a standards-compliance work over. Most of the bugs are little, but need a lot of testing to validate correctness, and that some fix didn't break some other aspect. (Y'all can start by looking in my Jabber library; there's some tests there that are clearly labelled as breaking in the current Frontier, and last time I tried them around last February they were still broken.) The value here is again determined by the quality of the code, and how easy it will be to fix the bugs without breaking other things.

  On that topic, I don't know what testing methodologies are used in Frontier, but I strongly suspect the addition of a unit-test-based test suite is called for. This would largely alleviate the fear Dave justifiably has of breaking the library code. It also provides a path for Userland to validate that the open-sourced Frontier continues to meet their needs; if the unit tests continue to pass, the project most likely hasn't broken their code.

  My call: Cleaned up and properly tested, the library code has value. What I can't tell you is whether it any longer has a niche. There's hardly a function in Frontier I can think of that doesn't have a match in stock Python. (Excepting the outline functions, which I now have a match for in Iron Lute, so for me personally at least it's still a wash ;-) ). Or stock Perl, or easily acquired Java libraries. 

• Development environment: But one advantage I'd say Frontier still clearly holds over Python is the development environment. The debugger is superior to any Free product I'm aware of for Python, and the windowing system is nice. I intend to treat the outliner seperately, but the environment makes good use of it. 
• Cross-platform-ness: It's nice that it works in Windows and Mac, but I wonder what it would take to get it into Linux. My guess, honestly, is that it would be a hell of a lot of work, even leveraging Wine. My call: Marginal, but working on Windows is surprisingly rare, so may be useful.
• Outliner: Ah, something near and dear to my heart, since the closed-source nature of Frontier is a major component of what drove me to create Iron Lute in the first place.

  As I've pointed out elsewhere, there are no usable outliner widgets in the open source world. As a result, a lot of my Iron Lute time has been spent hacking and kludging a workable outline widget out of Tk. One of the things that will be most interesting to me personally is how flexible and salvagable the outline widget in Frontier will be.

  On the other hand... the other design objections I've had to Frontier's outlines will remain intact, and if there's one thing I've learned as I wrote Iron Lute, it's that I have zero interest in trying to replicate my current outline.py in C. So its value to me personally is not as great as it would have been a year or two ago.

  How far other people will be interested in taking it is another story. Depending on the timing of the Frontier source release and subsequent community formation, and of when I get a steady enough job that I feel like I can once against dedicate my time to a hobby rather then work, the story may change. One interesting possibility is if the Frontier crowd makes it easier to reach in; perhaps Iron Lute could become an alternate interface to the Frontier Core, perhaps even eventually replacing the current one for most people. Or perhaps they'll make enough progress that I'll feel compelled to work with the Frontier project to improve the current outliner up to the specs I think a modern outliner should have. Who knows?

  My call: Once again, it depends on the quality and extensibility of the current code, whether it's at its end-of-life or not, and how much interest in shown in the ideas I've put forth on my Iron Lute blog. We'll have to see.

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.