“You can have freedom without choice.”

That someone could even come up with this one is just amazing to me. Note that this is not an exact quote, but it is the summary of Friday’s topic. For example, this summary comes from the idea that Canonical is bad for considering making mainstream non-free software available for Ubuntu based on user preferences. It does not matter who came up with it, of course, but the important thing is that it be called what it is: patently absurd. The ability to choose is a major part of what freedom—or liberty—is. If you cannot make a choice on a matter, then by definition you do not have freedom in the context of that matter. It is quite simple and self-explanatory. Canonical is seeking to increase freedom here, not take it away. Some people actually want to use non-free software; others may not want to use it, but aren’t aware of alternatives. The latter group of people should have our focus with regard to education (but then we should let them make the choice for themselves!).

Note that I am not one of these people: I would rather use free software because of the liberty it gives me that I have come to expect over the years. But I am not going to tell someone else that they are harming me because they would rather use non-free software that is familiar to them. All I can do is show them that there are free alternatives that exist. I cannot—and I will not—make them use it or make them feel bad for not using it. I may not like proprietary software for a variety of reasons, but I will defend people’s right to use it just as I will defend even a stupid person’s right to spew nonsense by way of speech or written word. In other words, “I disapprove of what you say, but I will defend to the death your right to say it,” or perhaps more appropriately, “I [may] disapprove of what [software you run], but I will defend to the death your right to [run] it.” Even I use a package or two that is proprietary in nature (though it is looking like I will not have to do so for much longer, given the efforts to replace these packages with equivalent free software).

It is worth it to note that by adding non-free software to Ubuntu, the free software that is already there does not change. The mere existence of non-free software within its repositories does not make Ubuntu somehow bad or evil. It would add choices that do not currently exist, and that one such as myself or yourself can certainly opt out of—I most likely would, for the most part, as I do not need to depend on non-free application software, and I only use non-free drivers if I have hardware where anything else is nonviable (and only until there are functional free software drivers). Did you know that Ubuntu has an option in the installer to only install free software? Can you say that for your favorite desktop operating system distribution, whatever that might be?

The response to this idea, then, is that without choice, there is very little—if any, really—freedom. The thing that gives us freedom with free software is that we are able to to download the source code, to review/audit it, to change it to fit our needs or fix a problem, and to share those changes. If we cannot do those things, then it is not free software; see the essential freedoms. But non-free software inside a distribution is not something that should not cause you great consternation even if you are among the most dedicated of freedom advocates, for if you are a true advocate of freedom then by definition you must respect a computer user’s freedom of choice. Remember that we choose to run free software because of the benefits it brings to us; we choose to improve upon free software for much the same reason. Eventually, I think that free software will once again become the norm for computer software, on merit alone, for no other reason than the development, release, and usage of free software is a highly practical solution for many things ranging from library code to application software to complete operating systems. It is worth noting that free content—which is similar in concept to free software, which itself is merely a specific application of freedom itself—also appears to making major headway towards becoming mainstream; it is doing so more quickly than free software is, but there is every reason to believe that free software will follow, for it is already.

An Example

Imagine that you are in a store, because you need some milk for dinner some night. You always get 1 gallon of 2%. But, the store has stopped carrying it, because more people buy whole milk and they were throwing away the 2% milk—demand was low, supply got to be too high, so they just stopped carrying it altogether. You leave the store and head to the next in the same town and you find the same thing there. You have a choice of stores to go to, and you have made the choice to go buy yourself some milk. But there is only one type of milk. You no longer have the choice to buy 2% where you are, and so effectively, your freedom to buy it has been taken away. (Of course, you can make 2% milk from whole milk (and make whole from 2% even, or even butter), but I suspect just as many people want to do that as want to write their own free software that they demand simply must exist, but doesn’t yet).

Now, the point here is that there is more than one freedom in play: the freedom of the store to stock (or not stock) various products, which affects your freedom as a consumer to buy the product you want. In the case of software, and choice, if the software you are running gives you all the choices you want, then it fits your needs. If it does not, then you are not going to be able to use it the way you want. Now you have two choices: you can do the work that it would take to make your desired choice possible, or you can use another system (free or proprietary) that will give you the choice that you want. Many people will choose the latter, especially if they are non-programmers. Though I’ve seen programmers also choose to use proprietary systems for something that they could themselves implement. That is their choice, of course. After all, if you really wanted 2% milk, you would have the same choice: make it yourself, or drive to the next town over which might have it available for you (assuming that there is some in stock and that the stores neighboring towns have not also decided to stop stocking 2% milk).

Ubuntu One: The Reason Behind This

This discussion came up because someone on identi.ca made the claim that Canonical is forcing proprietary software into Ubuntu by way of the Ubuntu One client software. I cannot even begin to state just how woefully incorrect this point of view is. First off: the only thing added to Ubuntu is the ability to connect to Ubuntu One, and the software that was added to Ubuntu do to that is licensed under Version 3 of the GNU General Public License. The claim made in response to that was that Ubuntu One is only partly free software, because the server is somewhere else and has not been released. As we shall soon see, that claim is nonsensical—it depends on an extremely naïve view of how software actually works in order to make sense, really.

So, first things first: Ubuntu One, which was added to Ubuntu 9.04, is not proprietary software. The proof rests in the fact that it GNU GPL v3.0, and we know a priori that software licensed under the GPL is free software, so we do not need to go further on that point.

Now, because the software in question added to Ubuntu is free software, we can read it. The essential freedoms granted to us by truly free software ensure this, and the GPLv3 is indeed a truly free software license because it grants those freedoms. Because we are able to study the software and see how it communicates with the server. Once we know how to communicate with the server, we can write that up and design a server that communicates exactly the same way. From there, it is just a matter of patching the sync dæmon that is in Ubuntu to talk to an arbitrary, Ubuntu One compatible server. To determine how to do that, one need only read the Python source code contained in the python-ubuntuone-storageprotocol and python-ubuntuone-client packages. If you do not know Python well, you might expect to spend several days doing that, but if it bothers you so tremendously that you are going to practically start a flame war over it, you may find it worth it to do so.

Of course, the other side to that is this: if you really want Ubuntu One to talk to an arbitrary server that runs free software, and you want that free software to be written, you can fund the effort to write the free software. Approach a proficient developer somewhere out there on the Internet and ask them how much they’d charge to write a server for Ubuntu One. You might not be able to afford the fund the project entirely, but if you get a number from someone, you can start a coordinated effort to raise the funds. If you are lucky enough to be able to fund the whole project, then do so: it is but one way that you can help provide something back to the community. This does not apply to just an implementation of the Ubuntu One protocol, it could apply to anything that you see that is missing and needs to be created. Or you could spend time learning what you need to learn to pick up the project yourself, if you care for the project that deeply. The most important attribute that a person can have in order to get started with development is motivation—James Westby reminded me of this a couple of years ago, something which I had forgotten.

Perceptions: Another (Possible) Reason

It was suggested to me that another possible reason that people would object to having non-free software inside an operating system distribution such as Ubuntu is that they are afraid that the proprietary options have higher quality, or offer superior features, or provide functionality that is not offered by any existing free software. Thus, they have this perception that by adding such non-free software into a distribution like Ubuntu, people will automatically use and prefer it over free software. This simply is not the case. Sure, some people will use iTunes if it is available on Ubuntu. Maybe many people would. I might even do so, if it were legally available for me to use that way and if it supports the purchase of DRM-free music. However, if there were a free software client for the iTunes store, I’d much prefer to use that. To my knowledge, however, there is no such thing that exists.

If there is not a free software alternative for a non-free component inside a distribution of software, if you are offended by that, then by all means, create a free software alternative for it! As mentioned above, you can start on such a project’s development, or you can look for people that would be interested in volunteering for it and coordinating them, or you can put up funds to pay developers to implement it. If you have money, this can be the easy part: find someone who is willing to accept payment for the service of implementing the free software alternative for whatever it is that someone else has funded, wrote, and released as proprietary software. It is not like free software is developed without cost (and if you think that it is, then you seriously do not understand what free software is or anything about the world of free software and have no standing to be getting mad when a company spends money writing software and does not release it as free software. You can try to write companies that write such software and ask them if they will give you any form of written specifications for the software, or an interface definition, or something along those lines. The worst thing that could happen is that you will be told “no”. And do so nicely, or they’ll be more inclined to tell you “bugger off” instead of simply “no”.

“Allowing users to choose proprietary software is anti-freedom.”

Nothing could be farther from the truth; it is the same, in fact, as the above statement that one can have freedom without choice. For example, if Ubuntu adopts iTunes and makes it so that you can “sudo aptitude install itunes” in the future, that is not a bad thing! How can it be—It contributes to the ability to choose, and thereby contributes to the freedom of the end-user. If you are a die-hard free software supporter and do not want to run non-free software on your system, then there is a very simple solution for you: simply don’t install it.  That is a valid solution to the problem. There are tools already available that can be run as a cron job and report on any non-free software that you might have accidentally (or even intentionally) installed. If you are worried about additional non-free software getting into Ubuntu, then help enhance those tools. Or write a GUI front-end for something like the virtual RMS program and work to get that included into Ubuntu as well, perhaps something that can run every time you login to the computer, or that runs as a persistent process that watches the package database on your distribution of choice for updates and then checks to see if newly installed software is non-free and alerts the user. Of course, it’d be most effective as an opt-in system, and not an opt-out one where it would just be annoying.

There is no way, then, that freedom is actually reduced in this way when another choice becomes available. If iTunes were to be included in the repositories (and I suspect it would be, like the restricted, universe and multiverse repositories, a separate opt-in repository; perhaps simply “proprietary” would be fitting), this does not reduce your ability to choose to run a free software media player and manager like Banshee, or Rhythmbox, or even AmaroK if you are so inclined to run that KDE stuff.

Once upon a time, FUD (fear, uncertainty, and doubt) was the tool of Microsoft. We (the free software world) completely hated it when Microsoft would put out FUD, because we would then have to fight that FUD by way of explanation and demonstration. Well, some time ago, a subgroup of the free software world decided to start using FUD themselves—it was done with Mono, and it is being done now with just a survey asking people what sort of software they would like to see in Ubuntu. Now, those of us who are left who are advocates of liberty—both personal and societal—are stuck potentially fighting two battles. One with Microsoft’s FUD—such as the constant notion that you have to pay for software—and one with the “free software evangelists” FUD, who have even gone so far as to say that people should not use certain types of free software (the one who calls himself “The Open Sourcer” even still today tells people to remove certain truly free software from their systems). The truth is somewhere in the middle, between these two ends of the spectrum.

Conclusion

Back to the point at hand: to say that giving a person a choice is a constraint on that person’s freedom, that is doublespeak.; it is saying that “slavery is freedom,” albeit to a lesser degree than that very melodramatic extreme—it simply does not make sense. The concept just does not make sense unless the words that are used to express the concept are dramatically redefined to mean things vastly different from what standard English dictionaries define them to be. The only reason that one has to try to convince someone that additional choice is a constraint on freedom is to try to convince people of things that are not true; to install fear, uncertainty, and doubt into people. This is the sort of behavior that—no matter what community it originates from—is completely immoral, unethical, and absolutely unacceptable. It’s dishonest, and for those of you who know me personally, you know what I think of dishonesty.

Base Position

Mailing lists should Just Work.  Mailing list management servers are software just like any other software, and they can be made to do what is convenient for us humans, and they should be made to do what is convenient for us humans.  Mailing list software should cater to the needs and desires of all its users, regardless of technical aptitude or choice of MUA (mail user agent, email client) software.  Mailing list software should be updated to operate with the expectations and flexibility expected of software used in the 21st century, and provide more options for interaction both technical users and non-technical users alike can love and use.

It is my personal belief that both mailing list software and MUA software should follow the established philosophy of "do one thing and do it well".  That means that MUA software should be expected to only be capable of being a basic mail user agent, and that mailing list server software should be expected to be capable of everything required to manage a mailing list for end-users, technical users, and list administrators.  A finer-grained permission model in mailing list server software could be adopted to make some of the proposed features even more convenient and get rid of the "administrator" vs. "user" line (i.e., "Jack can unsubscribe users", or "Carla can list messages in the mailing list’s pending approval queue", or whatever).

Furthermore, it is my belief that enabling convenience for end-users does not necessarily mean taking advanced functionality away from technical users: with careful thought and design, both needs can be met with a single standard.  It is also my belief that the most important part of any proposed design is the consideration of users ranging from complete newbies to people that have no time in the world but to learn about every feature that is available and find applications for them.

It is not my belief that mailing list management software should be extended to do things beyond the realm of mailing list management, though I believe that mailing lists are also currently very narrowly defined to be a mirror of public forums such as Usenet, and mailing lists certainly do not need to be restricted to such a model when a little bit of extension can bring a great deal of benefit for all users involved.

In short, mailing list management software should maximize flexibility while minimizing the amount of knowledge required to initially begin using the mailing list system (at the end-user level, at the technical user level, at the administrative level) and regularly interact with the system.  Convenience, ease-of-learning, continued ease-of-use, flexibility in usage patterns/workflows and use cases are all equally important.

Functionality Target Proposal

Let us assume the following statements are true:

1. Mail User Agent software can only be relied upon to have barebones message handling functionality that does not encompass mailing-list aware logic.
2. Users can only be relied upon to have barebones message handling functionality with only message-level context, such that they know that they are responding to a message.

Now, let’s define a few other assumptions that we will take to be true with regard to MUA software:

1. MUA software properly sends either a References header or an In-Reply-To header, which facilitates threading (should not be an issue, since RFC{822,2822,5322} specifies the header and it should be supported universally).
2. MUA software gives the end user no ability to send custom headers as a base feature.
3. MUA software gives the end user no ability to modify headers during message composition other than To, Cc, Bcc, and Subject as a base feature.
4. Even if MUA software can do items 2 and 3 above, it is safe to assume that:
   1. It is terribly inconvenient to do so, or
   2. The user does not know how to do so.

Now, let’s define a few other assumptions that we will take to be true with regard to this ideal mailing list management software:

1. The mailing list management software remembers mailing list threads by remembering message IDs.
2. The mailing list management software may or may not fall back to identification of threads by subject line, timestamp, or some other means, depending on what is most feasible and whether or not there are any accurate huristics that can be applied to make a determination with reasonable confidence.
3. The mailing list management software is remembers messages and posters, and stores information about each message in a manner that makes filtering (e.g., filters for the display of archives, or filters for sending back out to the mailing list) on the server side possible.
4. The mailing list management software can apply a limited number of per-user preferences on the server, including multiple addresses associated with a single subscriber, mode of subscription (digest, normal), interval of digests with at least an option for daily or per-x-number of messages with x being a server-specific configuration item, and perhaps server-side support for bandwidth saving features such as server-side "killfiles".
5. The mailing list management software never requires custom message headers or interfaces other than email for management of the server or per-user preferences, though it can implement such features in addition to a base interface which depends only on an RFC{822,2822,5322} capable mailer.
6. The mailing list management server uses all allowable standard headers for list management such that MUA software implementing those standards can use the information, but does not assume that MUA software is actually compliant to those specifications, instead treating them as optional in nature.

Let’s further define a few modes of operation.  We will discuss potential implementations for these modes later; for now, we are just defining the modes of operation.  If you have a new mode to suggest, please post it in the comments section below, in the same format.  A solution for how to make the mode work is not required, but if desired can be supplied as well if it is in the framework of this post.  We’re talking about the ideal mailing list management software here, not any currently existing one. 

Here is the first (and probably most common) mode of operation, which we will call Mode 1 ("Typical operation"):

1. Bob wants to send an original post to a mailing list (e.g., start a new thread).  He enters To and Subject headers, and composes his message just as if he’s sending to an individual.  Note that current mailing lists already do that, and thus mailing lists are in this respect transparent.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice sees Bob’s message, and wishes to add to the thread of discussion, so she hits "Reply", and enters her message as a reply to Bob’s.  She then hits send.
4. Alice’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.

Here is Mode 2 ("Private replies"):

1. Bob wants to send an original post to a mailing list (e.g., start a new thread).  However, the thread is intended to be a private poll, and so replies should go to Bob directly and not be distributed to the mailing list.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice replies to Bob’s mailing list post, which goes to Bob without being distributed to the mailing list.

Here is Mode 3 ("Private subthreads"):

1. Bob wants to send an original post to a mailing list (e.g., start a new thread) normally.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice responds to Bob’s message with a few queries and sends the message to the mailing list.
4. Frank responds to Alice’s queries with a few more to seek clarification.
5. Bob responds to Alice normally.
6. Bob responds to Frank normally.
7. Jo sees Bob’s response to Frank and has a question that should be addressed to Bob directly, without going to the mailing list.  Jo sends an email that should get directly to Bob and not be distributed to the mailing list.
   1. Note: mail filtering (if Bob uses it) should not filter the mail as if it came from the mailing list, but the message should thread properly if mail filtering is not considered or if the message is moved to a folder with the rest of the mailing list messages.
   2. Bob receives the response and replies to the message, which goes to Jo and does not get distributed to the whole of the mailing list.

Here is Mode 4 ("Dead thread"):

1. Bob wants to send an original post to a mailing list that is normally a discussion list, but this is an announcement and there should be no replies.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice responds to Bob’s message with some questions pertaining to the announcement.
4. The mailing list software informs Alice that responses were disabled on the post.

Here is Mode 4a ("Dead subthread"):

1. Bob wants to send an original post to a mailing list normally.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice responds to Bob’s message with some questions.
4. Bob responds to Alice’s message, answering the questions, and noting that the discussion should go elsewhere for any reason, and that the subthread is closed.
5. Richard responds to Bob’s message, trolling.
6. The mailing list software informs Richard that responses were disabled on the subthread.

Here is Mode 4b ("Killed thread"):

1. Bob wants to send an original post to a mailing list normally.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Alice responds to Bob’s message.
4. Frank responds to Bob’s message.
5. Jo responds to Bob’s message.
6. Frank responds to Alice’s message.
7. Frank responds to Jo’s message.
8. …
9. Eventually, the thread gets out of hand, and everyone but the trolls want the thread dead.  Bob sends a message stating that the thread is dead, and dead it remains.
10. Future messages in reply to the thread are responded to by the mailing list software with a message stating that the thread was killed and replies are disabled on the post.

Here is Mode 5 ("Muted thread"):

1. Bob wants to send an original post to a mailing list normally.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Conversation ensues and certain users are utterly disinterested and do not want to receive messages on the thread any longer.
4. Jo sends a message to the mailing list indicating disinterest and the mailing list server obliges by not sending Jo any more messages from the thread.

Here is Mode 5a ("Muted subthread"):

1. Bob wants to send an original post to a mailing list normally.
2. Bob’s message hits the mailing list server and is distributed to the subscribers of the mailing list as expected.
3. Conversation occurs.
4. Jo sends a message to the mailing list indicating disinterest in a subthread, and the mailing list server obliges by not sending Jo any more messages from that subthread.

Here is Mode 5b ("Temporary Mute"):

1. A mailing list has "blown up" and some of its users would rather not see any mail from the list for a period of time (say, a day or a week).
2. Users respond to any message in the mailing list and state that they want the list totally muted from their perspective for a specific (but arbitrary) duration.

Here is Mode 6 ("Named Subgroups"):

1. Bob is on a mailing list for a project and has a security issue to discuss.  He sends a message with [security] in the subject.
2. The message is delivered to only people that are in the [security] subgroup; whether the subgroup is open for joining by members of the mailing list or is closed off is up to mailing list server configuration.
3. Replies are contained within the named subgroup.

Here is Mode 7 ("Hidden Addresses"):

1. A group of users would like to have a mailing list, but they do not want their addresses shared with other users when they post, for whatever reason.
   1. Note that this can be used to prevent spammers from subscribing to the list, lurking, and harvesting addresses–very useful today.
2. The mailing list software takes posts and:
   1. Modifies the "From" header of the message to retain the name component, and changes the address component to that of the mailing list.
   2. Replaces the Message-ID header of the message with one generated by the mailing list software for the mailing list itself.
   3. Removes any Received headers.
   4. Removes (but remembers!) any Cc headers that were applied to the incoming message, and honors them until such time as it is told that the Cc should be dropped explicitly, for example by a recipient of the Cc (who sees the Cc line with only their address in it) or a trust list administrator or trusted list helper that can act on the behalf of the Cc recipient ("plz stop sending mailz 2 me k thx").

Possible Implementation (High Level) Notes

Now, between these seven distinct modes and their submodes, all the infrastructure that is necessary to expand the mailing list’s utility are possible to fit nearly any type of usage pattern/use case–transparently, and without any special requirements on MUA software beyond very simple, basic message receiving/display and sending.  At this point, I’m interested in collecting other use cases that I may not have thought about, but that people already use or would imagine would be useful.  The goal, ultimately, is to attempt to come up with a design and specification for a truly transparent mailing list management system that is more flexible than today’s software, that can have per-user preferences that are centralized and MUA-independent, and have features that can be used in the context of messages sent to the mailing list.

One idea is to use in-band signaling on the mailing list to indicate various things.  Unlike list software like majordomo where commands are sent to special mailing addresses, it’s possible that some things can be done by adopting existing conventions and others can be done by adding special information to the message body itself.  For example, Mode 6 is imagined as being part of the already-widely adopted convention that people can filter out based on [tags] in the subject, so an [OT] is used for off-topic, [RFC] for request-for-comments, and so forth.  The advantage of adopting conventions and in-band signaling is that it is inherently portable to nearly all MUA software, regardless of age or capability, as long as either References are In-Reply-To are supported.

Additional Modes

If you know of a workflow or a mode of operation/use case that would not fit in with this proposal, state it (I’m not looking for technical arguments of feasibility right now, just desired modes of operation; a future post and/or wiki page will serve the purpose of overall technical feasibility evalutation).  Consider this to be the "research stage" of a system to-be-specified, with potential for becoming an RFC a published Internet standard with the goal of improving life for all of us: non-technical users, technical users, users married to our workflow (or not).  The only correct system is one that works for everyone in as flexible manner as is possible.

Centralization

Many of these use cases (modes) require that mailing lists are a "gateway" for all of the interaction between users unless things are explicitly taken off-list, which of course users are free to do, if desired.  Some would seem to believe that if everything is centralized that certain use cases become inherently impossible.  While that might have been true given the computing resources that were available in the 1990s, it is not true today, and we shouldn’t pretend that it is; even a uniprocessor server running with a 266 MHz CPU and 64 MB of RAM should be able to run a mail list server implementing these features, serving a moderate number of users and still be fast and responsive.

Sure, lists that are the size of the LKML would probably want to run the mail list server on one machine and the database server on another, or have a distributed environment where the workload can be handed between mail list servers running for the same list (or family of lists), but if the software is correctly designed and implemented with such a configuration in mind, it would be easy for even very large, very active mailing lists to use a featureful system such as this.  For that matter, correctly designed, "centralized" does not have to mean "not highly available", because here I am talking about the service being centralized for a single list, although it would be possible in theory to have the mailing list run on only donated CPU time from volunteers (that said, DNS already makes this possible when combined with a well-planned and well-executed deployment process, though not terribly easily on the IPv4 Internet).

Others state that a centralized setup would take away their freedom to interact with the mailing list in some way: I am saying that this doesn’t have to be the case.  It may be with the way current mailing lists are implemented, but it doesn’t have to be that way at all!  And it can be done in a way that is intuitive–or at the very least, makes sense to users and is easy to learn, if not 100% intuitive.

Again, however, the motivation at this point is a high-level conversation that seeks to be gradually refined into lower and lower levels of abstraction until the final product is source code that can be seen and examined.

Motivation

Why am I motivated now?  Because it is plain as day that a universally applicable solution can be made to exist, and it’s even clearer that there’s no reason for it not to.  I don’t expect that this would be an overnight process, but I think that given ample discussion and interest, we can figure out a way to make everyone happy, even those that are way out with the extreme corner cases.  After all, there is no reason that systems cannot serve both complete end users and extremely adept technical users seeking to use every available feature.

In short, I think it’s time for a change in the way we think about what mailing lists are and how they work, and I think that it’s time that we consider how to make them useful and transparent to us, all of us, regardless of technical knowledge or background, regardless of the end user’s stringent desire to follow RFCs, and without having to be concerned about everything the system can do (while knowing that if you want to learn about all of the features and use them all, you certainly could).  I think it’s time to drop the assumptions that we’ve made for the last several decades with regards to mailing lists and redefine them.

So, who is interested?

That’s right.  Now, there are many things that the man has done that have been effective, and the man has worked hard to ensure that we have freedom in the vast world of software.  But recently, he has stated that Miguel de Icaza “is basically a traitor to the free software community,” and no matter how much good a person has done, I cannot stand by such a fallacious statement.

What is freedom, people?  The two cornerstones of freedom are education and choice.  A person who is uneducated cannot choose, and so one depends on the other.  Some people will choose to use either free software or proprietary software exclusively, and others will mix the two together, with varying priorities that they place on their choices.  As long as people are aware of what’s out there and can determine what is best for the way they use their own systems, freedom is available.  Yes, that means some people may choose to run Windows.  Many will not, and if one makes a conscious choice, that is for them to do for themselves.  My concern is that people need to know about the choices in order to make a choice to begin with.

Now, de Icaza has done a great deal of work for the open source community.  He’s one of the key people who has been behind Midnight Commander and GNOME.  And of course, Mono.  He has given us a great deal of good quality, free software that many people can choose to use, and he has given the ability to use a VM-based runtime environment that previously was not cross-platform, as well, on nearly any platform that can be chosen.  The GNU people are even working on a similar one.  But this is not the reason that de Icaza is supposedly a traitor to the community.  The reason?  de Icaza is helping Microsoft out with their new “Open Source Labs”.

Guess what, Mr. Stallman?  The fact that Microsoft is starting to enter the world of free software cannot be considered to be a bad thing.  You did a great deal of work to ensure that free software that is adequately licensed can stay that way, and the turn the copyright system around on those who have sought out to corrupt it.  You have put free software on the radar around the world.  You have done a great many things that others would not have the heart, nor the motivation, to carry out.  It would appear, however, your time is up:  the world can and will move on without you, and I declare that it is time for you to go away.  When you start attacking people in the very world that you helped to create, you become obsolete and no longer serve your purpose.  I dub St. Ignucius of the Church of Emacs to be a heathen who has forgotten his message, forgotten his values, and is now a harmful creature; hardly a saint, more like a devil.  Overtaken with fits of arrogance.  Lately, you have caused a great deal of infighting within the community.  As I am sure you are well aware, infighting serves very little useful purpose but to tear apart communities.  And now you make a bold, arrogant, and false statement that serves only that purpose, but to an extent the likes of which we have never seen from you.

I say that we shun him—and his kind. Things are starting—albeit slowly—to come around to the way we want them, and he would prefer to attack it.  Why?  What logical reason is there to do so?  Because he’s not the controller of it?  Because it grew to be something that even companies that he helped cultivate an irrational, religious-like hatred of, are beginning to see is useful (not only to them, but to all of us)?  What is his new goal, that all software should be GPL’d and if it isn’t it is evil?  We should not tolerate these sorts of counterproductive behaviors.  Stallman has reduced himself to a Schestowitz, a creature who deserves no respect.  A troll.  I suppose in his old age, he has decided that attention is more important than our freedoms.

Richard Matthew Stallman, you are no longer relevant to our community, our world, the world of people who truly believe in and advocate for freedom, that of choice and that of the rights to study, improve, and distribute software.  Thank you for your services, for they were needed to get us where we are today.  However, you have chosen to do us no further good, only ill.  And for that, I say damn you.  Leave the Free Software Foundation and permit it to continue to work for freedom, or take it down and let the GNU project carry on to produce software without all of the utter crap that you have begun to spew of late.  I have no problem with the GNU project.  I love the GNU project.  And I am grateful for the work that you, independently and through the Free Software Foundation, have done so that we can enjoy the freedom to choose a free software system to do our work and our play.  But you are no longer helping; you have become a bully, an old troll.  You do not help free software any more.  Your recent action is a great offense to free software, and very much condemning a road which will lead to more free software.  Go away, troll.

Long live freedom—true freedom—and free software.  And thank you, Miguel de Icaza, for all of the great software that you have given us, as well, for your continued work to make software more useful and portable.  May you never wind up irrelevant and petty as Stallman has wound up being.

Many projects that are all about being open and transparent provide mechanisms for their users to get in touch with the developers.  Launchpad has become an excellent place to do these things; Launchpad’s Answers and Bugs components are truly excellent ways to get in touch with people that manage software there.  The system is so good that I’d advocate that every project try to move to it.  Launchpad does have its issues, though they are often quickly fixed (and can be fixed even quicker now that it is free software).  But between Bazaar (a truly amazing and flexible distributed version control system) for code hosting and the other components of Launchpad such as the Answers, Bugs, and Translations components, Launchpad provides virtually everything that a project needs to communicate effectively with its users aside from the project’s Web site.  And users seem to naturally be able to reach out using it.

In the nearly one year that I’ve been working with AllTray, I’ve talked—well, written to—several people who have asked questions and acted in their own ways to work to improve the software.  Development on AllTray has been made much easier just because people are willing to speak up.  Everything from the random “thank you” to “hey, are you going to do this?” or “I’d like to see feature x in the new version” or whatever.  It’s truly great.  I can’t say that every project has users quite like AllTray’s, because AllTray is something of a niche application, but AllTray’s users are a great model for other projects.  There has been virtually no negativity from users and everything has been constructive.

To anyone who manages a project that doesn’t use Launchpad, I’d strongly encourage them to do so.  Its users are great, and as far as management of the overall project goes, it’s very easy for project people to communicate back and manage communications in a single spot.  It’s also great that users can ask a question and that the project can do things like go, “oh, hey, this is really a bug,” or vice versa with bugs→questions.  And if you don’t use Launchpad because you don’t want to use Bazaar (I hear that users of git are pretty dedicated to it; I can understand that, but it’s just not for me—it’s too complex, and I like that Bazaar just stays out of my way), consider using LP for everything but code hosting.  Or consider using Launchpad’s code hosting to mirror your project from git, it does this quite nicely.  Or, find some way to do what Launchpad does wherever you do project management.  It works really well, and it’s a big help.

And to AllTray’s users. A big Thank You.  You guys and gals are great.  Keep communicating!

1. Windows 7 commits sins.
2. Windows 7 users are sinners.

The site provides a decent amount of information.  But I would imagine that a good portion of its potential readers that are linked to the site will stop reading at the domain name, windows7sins.org, just for the two very clear things it says.  Okay, so we have a very strong tie to science, but does that mean that we should alienate people from the start?  I do not think so.  If you are curious, the alleged “sins” are: poisoning education, invading privacy, monopoly behavior, lock-in, abusing standards, enforcing DRM, and threatening user security.

So, we can hold those points as true: Microsoft has done all of these things, and many more, which make supporting it as an organization something that some of us would shudder to think of, and that many more of us simply would not do if given the choice.  And that is the real key to freedom, is it not?  That we should give out the information in a way so as to reach the widest possible audience, that is.  Not that we use emotional manipulation to compel the audience to switch because then all we are doing is forcing them to feel they need to change.  Instead, users should change (or try) when they are ready—not before they are ready, and not because you offended them and made them feel dirty.  That is exactly the same tactic Microsoft uses on its customers in order to convince them of various things like “you get what you pay for,” or “if you did not pay for the software, it is pirated, it’s not legitimate,” or that free software is a form of “malware,” and so forth.  Why should we stoop down to their level?

Wait, am I saying that it is okay if users choose to use Windows?  Yes, I am.  But if Windows is the only thing that you are aware of, and it is all that you know (and believe me, there are still many such people out there) then it is naturally going to be what you are using.  So they’re a “sinner” by default, and that is offensive.  The only thing that they are guilty of is ignorance, and ignorance has a very simple fix: deliver information, let them learn of these things, and then there is no more ignorance.  For many, it is not even intentional ignorance.  They simply do not know.

I think that this campaign would have been a good thing if it did not seek to offend to make its point.  That’s resorting to a very below-the-belt tactic, and it makes the Free Software Foundation (in this case) come out looking no better than Microsoft itself which is unfortunate.  They have done the wrong thing, for the right reason, and it is constructed to make very little go their way.

So, do not refer users to the Windows 7 Sins Web site when attempting to convince them that they should not choose to upgrade to Windows 7 (or are already running it in one of its pre-release forms).  Instead, offer them information.  Explain things to them, and if they aren’t ready to try something else, whatever.  If they want to try something else, and they wind up going back to running Windows for one reason or another, then by all means, let them.  Of course, find out why they did, first, and maybe you can fix something that will eliminate a problem for others, too.

That is freedom.  It’s not free and it’s not easy.  But just remember that users have the freedom to choose, and that is a bigger freedom than what some of them will ever see or understand in free software.  And if they choose to use something we don’t like, that’s fine; it is, after all, their choice.  Who cares if it is not the choice that you would make?

One of the very few times I have uttered this phrase, but it works now:  Thanks, Microsoft.

Why?

I’ve used AllTray for a long time. It is one of those pieces of software that performs a useful function, but you have to know its quirks to make it do what you want quite often, and you have to work around some of the things that it does for it to retain that usefulness. Users shouldn’t have to do that—they should just be able to start using a program or utility and have it work properly. Also, utilities should be (reasonably) independent of the environment that they run within, which AllTray isn’t. And, good utilities should integrate with the system pretty well, which AllTray does not, since it carries a hard dependency on GDK/GTK. (Kdocker is an alternative piece of software, and while I don’t know how well it works compared to AllTray, I know that it is bound to Qt, which is just as bad.)

The license will most likely be GPLv3, since nothing will actually link to it and it’s not a library. If there is a library component, it will be LGPLv3.

The actual “braindump”

The actual *docking* part isn’t terribly hard, it would seem. With GTK+ it can be done in only a few lines of code (especially in C#). However, C# wouldn’t be the language to use for the this tool, because of the dependency on Mono. My thinking is that the proper language to use would be C itself. It makes me think of how easy everything would be if only the desktop environment and all its software were already written in managed code… the effective cost of using C# would be significantly less than it is already.

Using C as the language isn’t that big a deal to me. What is a big deal to me is that the application be well-integrated and well-behaved. For example, AllTray depends on GTK for some of its tasks, and uses a custom (ugly, IMHO) widget for displaying its title when you over over it in the system tray. There’s another program out there, KDocker, that would appear to be slightly more featureful than AllTray, but it carries with it a dependency on Qt, which I don’t like. Ideally, the core for such a docking utility should be able to have various back-ends that serve the purpose of integration with the system, with a single back-end that would apply without dependencies on anything else for the rare scenario where neither GTK+ nor Qt are available.

What would this thing be required to do?

• Dock any arbitrary application to the system tray, not just a single window from the application. (Using the System Tray Protocol Specification)
• Run in a single instance, managing multiple applications within that instance if necessary.
• Provide session management for those who use it, and act as a session manager for applications that are run underneath it that support session management.
• Be able to use something like inotify to be able to show an indication of when the application’s title for its windows change.
• Use a single icon for the application, with a window list if the application carries more than a single window.
• Use individual backends which provide a native look and feel depending on the desktop environment currently in use.
• Use the application’s icon to represent the application in the system tray.
• Support blinking the icon when the application decides to do something like present a modal dialog box or something (if this is even possible, that much I am not quite sure of).
• Detect the desktop environment currently in use and (if possible) load a backend to integrate with it.
• Carry a dependency on GLib so as to make implementing it quicker and less error-prone.
• NOT carry any hard dependencies on any widget libraries like GTK+ or Qt.
• Return an error to the user if there is no running system tray, and there isn’t one after some sort of timeout (say, when starting the desktop environment, there may not be a system tray right away). (I don’t think that sort of situation would be commonplace, but it’s not really the job of this program to create a system tray if one doesn’t exist, since this is the job of the desktop environment.)

The backends would not have any specific configuration items (the entire configuration would be housed somewhere like ${HOME}/.config/docker, for example). There probably ought to be a backend entrypoint that would show a dialog for configuration, but I haven’t really figured out if that’d be the case yet. The docker should probably do all of its configuration by way of the command line for each invocation, which is suitable for use as a desktop shortcut or panel launcher.

This approach requires that each individual desktop environment have its own backend, which might become a bit of a pain for supporting a great number of desktop environments, but the upshot of that is that the application then feels native no matter what environment the user is using. Obviously support for GNOME and KDE would happen, and most everything else would depend on someone with programming experience for various environments to implement a backend for it.

The backend doesn’t handle, say, docking, since there’s a standard for that already. It would handle things like displaying the tip when hovered over or displaying a menu when right-clicked. So, the job that each backend would do would be pretty lightweight. And as much as possible should be handled in the core, with the backend consisting of just enough “hooks” into the target system to be able to provide a useful interface.

The way that this would have to work, using C as the programming language, would be that the core would have to use dlopen() and friends to load the backend and then use the entrypoints that the backend provides. Since dlopen, dlclose, dlsym, and dlerror are defined by POSIX.1-2001, support for those should be in every reasonably modern Unix-like system that supports at least a subset of POSIX. This of course eliminates Windows, but I am not terribly worried about that since there are probably other Windows-only utilities that serve this purpose.

The primary goal, then, is to replace other DE-dependent and toolkit-dependent dockers with a utility that carries the goal to be universally useful and highly robust. The aim of this goal is to replace AllTray entirely in (at the very least) Ubuntu, and hopefully be seen as useful in other distributions as well.

I’ll need some help…

This is the part where it’ll get interesting. I’ll need some help in actually doing this, in many areas.

For the moment, where I’ll need help (be that from Google, or from people in-the-know that happen upon this post) is to find all of the documentation that I’ll need to understand how to implement the software. I can use software that already exists to try to learn how the underlying system works, to a degree anyway. But some of the software doesn’t handle various situations correctly (or I don’t have a way to see if it does) and so studying them would be less than useful for everything I am trying to do. Namely, the things I need to find out yet are:

• How to run a program in such a way as to be able to reliably know what windows belong to the program and be able to dock them. I suspect that it’d involve using LD_PRELOAD and some monitoring trickery, but I would hope that there is some sort of API to do this already. Also, need to know how to manage the application itself; say it continues running but without any windows, the tray icon should obviously disappear while it’s running like that, until it has windows to manage again.
• How to perform session management and be a session manager for subordinate programs. (I might be able to study the source for KDocker to learn the answer to that, though I am not 100% certain yet of that.) I also have a paper to read yet on the subject that may have all the information that I am looking for, though I am not certain there yet, either.
• How to reliably detect the running desktop environment without resorting to ugly kludges and ad-hoc trickery.
• How to work independent of the currently-running window manager and operate reliably for any standards-compliant WM that is running, without having to special-case for various types of software or various types of window managers.

I suspect that there is useful documentation out there for most (if not all) of those things for X11 and other relevant points. I just haven’t found what I am looking for yet for all of it. Standards documents and system documentation are useful things to find, and maybe an example or two of source code on how to do it as well, are what I am looking for, so that I can try to understand these things better.

At some point down the road, I’ll need help with getting the backends written when they have an API to conform to. I can, in all probability, write a GTK+ backend that will work for XFCE and GNOME since I use GNOME. However, I don’t use KDE or anything that runs on top of Qt, so I will definitely need help from someone that is familiar with writing software for Qt to get a Qt backend written. If XFCE has any sort of non-standard special UI guidelines that are incompatible with GNOME, then I’ll need some help there, too. Any other non-GNOME or non-KDE environments (such as GNUstep, if it supports it anyway) that support the System Tray Protocol Specification will need backends written for them by people that are able to do so.

Yup, I did. It was Little Brother. Haven’t read it yet? Go, read it, I’m not kidding.

And here’s another ironic twist: Consumers may actually prefer to pay for Ubuntu — rather than get it for free. No joke: Many consumers don’t like free software. They fear it. My brother in law didn’t understand how Ubuntu and OpenOffice could be free. “Is it legal to actually download and share that software?” he wondered.

I understand how some people can feel like it may not be legal to acquire software that is free, I suppose. Microsoft and the BSA have pretty well attempted to drill the thought into people’s minds that software acquired without a financial cost can be somehow illegitimate, implying that it’s simply not possible for the Internet’s citizens to create software that is of any measurable quality. Of course, anyone that is “in the know” is quite aware of just how wrong this idea is; the quality of Microsoft’s own software is somewhat debatable.

The simple truth is that people just like you can learn to write software, and write high-quality software if motivated to do so. A large portion of free/open-source software is worked on by people such as yourself. Things ranging from the actual programming, to bug management, to documentation—all of those things can be done by regular, everyday people. There’s nothing—other than Microsoft’s business strategy—that says that the work that you or I do on a free or open-source software project is automatically of any sort of lower quality when compared to Microsoft’s software. In fact, the major argument for such software is its transparency. I know that when it comes to any software, I often want to change it to fit me better than the original programmer or company provided for. For software such as Windows, or Internet Explorer, or Microsoft Office, or any other proprietary software offering, this is impossible without violating some sort of license agreement. Now, that having been said, there is the belief that copyright law permits some “tinkering” of something which one has the right to use. I suppose this make sense—nobody would dare invoke copyright law to declare that the notes you’ve written in the margin of your textbook are illegal. Effectively, writing notes in the margin of a textbook or highlighting passages is “patching” the textbook to contain more information and do more things for you the next time you read it. So, why should it be illegal for a Windows user to write (or run) software to bypass the silly restrictions on theming in modern versions of Windows? It’s essentially the same thing.

The fact that Microsoft, the BSA, and other companies and organizations are so successful in drilling this “thou shalt pay for thy software” commandment into people’s brains is somewhat terrifying to me. It means that people in general are still easily had; they think that a corporation that makes billions in revenue every year is somehow more legitimate than the loosely-knit ecosystem of free/open-source software programmers. Of course, we can confirm that idea by simply looking at the U.S. Government, as well; people are inclined to trust it to provide the freedoms that we’re supposed to have, while all the while taking those freedoms away in the name of “national security”.

The point? Think before accepting what corporations and alliances such as the BSA quote as gospel truth. Yes, it is illegal to copy and redistribute Microsoft software without a grant of permission from Microsoft to do so. That restriction does not hold true for all software, though; you can freely copy and redistribute the Linux kernel, the Firefox Web browser, the OpenOffice.org suite of office software,˙and so many more, worthwhile pieces of software—including the entire Ubuntu operating system distribution discs. (In fact, they even say “Pass it on!” on the official media!) There is a lot of value to a system that can be modified on the fly to fit the needs of its user… and this is something that corporations and “copyright advocates” will seemingly never understand.

First off, if you are a developer (open source, closed source, doesn’t matter), you need to know the area of licensing. You should actually have read, studied, and understood at least the most popular licenses out there, so that you know what you can (and cannot) do when you link with code that uses those licenses.

Secondly, JavaScript code runs on the client, not the server, and cannot link to the server’s code. This also means that a JavaScript framework can be licensed under the GPL, and you have no requirement to release the source code to the back-end processing code. When you design a Web application, there are two components to it: The front-end and the back-end. These can be further subdivided a bit, if you were to employ the use of the MVC architecture for your application. However, no matter how sloppy you write it, there are two distinct components: The front-end and the back-end. That’s it.

Now, these are logically speaking two separate programs. They may work cooperatively, but think about it like this: The Web browser is a framework for zero-install client application software, which uses a network connection to talk to server application software. The front-end code, logically speaking, can be used on different back-end servers, too. It doesn’t have to be only for the backend it was designed for, nor does anything stop the backend from talking to a third party client application that isn’t in a Web browser.

Think about it this way for a minute: Amazon’s S3 service publishes only an API. You must write a front-end to sit on top of it. Your front-end being GPL’d will not force Amazon to open up S3, no matter what. It’s clearly separated.

So, think about those licenses and their interactions and do not spread FUD when you do not understand the interactions that are there. If you cannot distinguish between the front-end and back-end of a Web application by looking a working copy of it, you should probably consider learning more before you continue to write software. Writing software is a construction activity and does require real knowledge and experience, as well as the ability to think critically about problems—and a few minutes of critical thinking would save a lot of people from reading ranty, panicy posts on things like licensing issues. (This is also why management, unless they are technical-minded, really should not be making technical decisions, but that’s another post for another time.)