I want to be able to discuss Iron Lute's planned license in a posting
in response to somebody's blog here, but first I need to discuss
it. So here are the licensing plans I have for Iron Lute. I'm very
interested in feedback on this.
I'd would like Iron Lute to be open source, likely GPL with
explicit exclusion of plug-ins (i.e., you are explicitly allowed to
create new Node Types, etc., and release them under any license you
like). (This is not quite the LGPL because you still can not
take Iron Lute and build another application around it; limiting as I
will means you can "connect" Iron Lute to your application but that
you can not just pick up Iron Lute and make it be your
application.) But that depends on the usage and support pattern it
If nobody uses it and nobody helps me with it, then eventually,
I'll stop supporting it. (No surprise there.) I'll keep it online and
quite possibly continue using it in my own personal projects, but
unless somebody else shows an interest, no public sign of development
(Truthfully, call me arrogant but I do not consider this likely. I
think there's a definate niche in the Open Source world for what I am
creating here, partially because of the lack of an outlining widget
that I mentioned in my original post.)
If I get significant contributions from other developers and other
people (including documentation, help, community helping each other
out a lot, etc.), I'll make it the aforementioned limited GPL. The
threshold for this is "if I had to remove all contributions other then
mine to date, how painful would that be?" If it can be done swiftly
and painlessly, then I may go to the third option.
The third option is "a lot of people use it and like it, but nobody
is helping with the development". In that case I'll do an analysis,
and either stop development, or try to take it commercial, depending
I'm thinking of a cut-off date of a year after the initial "stable"
release, which would be some months after the first public release, of
course, so we're talking about at least a year and a half window,
I'd like to say up front that I want this to be open
source. I want to experience new features of Iron Lute that I didn't
have to write myself. However, I do not want to tie my hands by
committing to a license "come hell or high water"; the condition above
is not intended as a "loophole I can jump through" so much as a way of
pointing out that two pages of docs and a node type do not
constitute "significant contributions" in the sense I am
mentioning. Believe me, I will err on the side of "open source" if
anybody gives me the chance.
So, what license this is released under is at least partially up to
I will make this commitment though: I will not pull the rug out
from underneath you. Should I end up going commercial, the last "free"
version will be clearly marked, never crippled, and will never
expire. You just won't get updates and improvements.
In my previous post, I concentrated on extending our data model to
handle multiple data sources cleanly and transparently. However, we
now have a conceptual contradiction in our data model. To this point,
the data model we've built still assumes it is a tree, which means we
can use the tree-optimized algorithms for things like counting
children. But if a document transcludes something that transcludes the
original, we can have a cycle, which means there is a path starting
with a node in the original, going through the transcluded document,
and ending up back at the original node. Most tree-based algorithms
respond to this situation by infinitely looping, which manifests itself
as a hard lock-up, which is generally considered a negative by
In my previous post, I discussed what I believe is the outline data
structure in current use by outliners, and why they are inadequate for
my purposes. I discussed why transclusion doesn't work very well under
that model (an algorithm can sort of hack transclusion on top of the
tree, but it's not "real" enough), and the difficulties of replacing
some of the tree concepts when you have a full graph. Today's post
covers the "transclusion" issue.
As I hinted at in my previous
post, this is not as easy to answer as you'd think. To give you a
hint on how hard it is, I'm currently up to my fourth major version of
my fundamental data structure. The best way to answer "What is an
outline?" is probably to take you through the same development process
I used to get to where I am now.
I've been writing ahead on my promised
developer travelogue posts, because I am trying to make them high
quality posts useful for programmers both new and old, not just
off-the-cuff reportings of what I happened to be doing last night.
I was concerned about the time lost writing these posts, because as
I said, time spent writing is time not spent coding. (Though I'm
getting much of the writing done when coding is not possible.) An
entirely unexpected benefit has accrued, though: I was factoring out a
concept from the next two posts and it has prompted a nearly complete
re-conceptualization of how the dominant programming paradigms of our
First, read my post about my
immodestly-named Bowers' Law if this sounds like an interesting
thing to read about. (If it doesn't, you can stop reading this post
Now, while it doesn't fit into that essay exactly, I've been
completely re-formulating the dominant methodologies of the day into a
new synthesis. Paradigm debates are generally framed as "Object
Orientation" vs. "Function" vs. "Imperative/Procedural"
vs. others. Graphically you can envision them as entirely seperate
I've been reforming my understanding to be based on the idea that
Encapsulation (with my particular definition) is the foundation upon
which all other good programming techniques are built. Those
programming paradigms that reject it, stereotypical procedural
programming ("spaghetti code"), are the useless programs of the past
that hit hard limits on their extensibility.
What you put on top of that is modular and can be mixed and matched
between programs, between modules, even between objects in the same
system. Whether you put Polymorphism, Inheritence, Multiple
Inheritence, Prototype-based Programming, or a variety of other
paradigms in various combinations on top is unimportent except in a
particular problem's context. There is no "One True OO", there's just
a collection of techniques that have their time and place. Many
now-marginal techniques can be fit into this understanding without
breaking anything or denying their usefulness.
I know this seems so simple, but the evidence that few people are
seeing it this way is abundent. Certainly this flash of comprehension
has significantly affected how I look at programming, so perhaps it
can help others as well.
I hope this can move forward a more productive debate with less
concerns about how "OO" something is, and with more concern for a
given paradigm's usefulness on various engineering scales. "Paradigm
purity" is not an intrinsically valuable thing; it is often valuable
but it must justify its existence with real benefits for the cost. I
think the real world already abundently demonstrates that a mixture of
them is always going to be with us.
Side note: The essay was not written in Iron Lute, but the
conversion from text to OPML for import into Radio Userland was.
This is the first public posting regarding my next major project, Iron Lute (links to
a screenshot). Iron Lute is an outliner, written in Python and using Tk as its toolkit; as a
result it should run on Mac, Linux, Windows, and anything else that supports Python and Tk.
(Off hand I don't know how many platforms that is, but it is plausible
this would work on palmtops and some other obscure ones with few
changes.) The license is currently undetermined, but will initially
be open barring surprises; more details in a forthcoming post.
|<- Future Posts|