J5’s Blog

The project I have been working on for a long time now has seen it’s first (beta) release. Meet Fedora Community, a consolidation of the various Fedora Infrastructure bits into one UI with a focus on usability. The unique thing about this site is that it doesn’t replace the other Fedora Infrastructure bits. It uses them as backends and mashes together the data into one view. For instance you no longer have to go to the bodhi update tool after checking on a build in koji. Instead you simply look at the build tool and if the package is able to be updated you will be presented with the option to do so. It will also point you to the correct log if an error happens in the build.

Right now it is geared towards Fedora packagers but in the future we hope to be adding a lot more functionality. Since the concept revolves around small applications running in a dashboard the possibilities are endless. Think live server status for sysadmins or up to date Fedora news for users. As always, because Fedora stands for Freedom and Community we will be emphasizing upstream collaboration which we owe a great debt for making all of Fedora possible, and Fedora Community’s code will always be licensed under AGPLv3 and compatible licenses.

To learn more you can grab the podcasts (in ogg vorbis format of course) or go to our project page.

In my day to day usage of apps I often run into little annoyances. I know I should be filing bugs but I instead did the next best thing and created a rant usability page that lists the things I wish I could do in an application but couldn’t. The idea is to have a quick place to jot down notes and then review them later for possible bug filing. I think everyone should do something similar as it provides a stream of conscious map of how people use the desktop and the little things that they may not feel is worth filing but are most likely the key to making the Linux desktop experience more enjoyable. It also allows a user to get out their frustrations in their own forum and then come back and file a more useful bug without the static of emotions.

When people think about economics they usually just think in terms of money but economics is about understanding the flow of limited resources within systems in an effort to make those systems more efficient (or if you are cynical making those systems be more efficient for a specific group). Money is just a system we have used to quantify the worth of those resources to counteract the inefficiencies of bartering. Since money has the ability to be traded for almost any resource (including money itself) it holds a lot of power and has become the focus of most of economics.

However, in the Open Source community a majority of our transactions do not include money. At least not directly. In fact, a majority of our capital is payed in the measure of time and effort; both by the consumers and producers. Both are highly limited resources which in the Open Source world aren’t really given the thought they deserve.

First consumers often give the impression that they think producers have all the time and energy in the world but only a small portion of the community can be classified as producers, and even a smaller subset are full time producers. The only way to grow time and energy in an efficient way is to get more people to become producers. The power of Open Source is not that it is freely available but that anyone can become a producer. Providing that producers work together in some sense of a direction, Open Source growth should be exponential and eventually overtake proprietary development in terms of an efficient economic model and generation of capital. That is why the GPL and other reciprocal licenses are in the long term a better model as they prevent the “picking up and going home once the market expands” syndrome - though there are other forces that effectively prevent that for projects under other licenses. That is all another post though.

The other place where both time and effort are not given enough thought is in the use of the final product. In fact many projects fail to productize their efforts, choosing to leave that up to vendors. I cringe when I hear things like, Linux can do anything you want, you just have to configure XYZ. I don’t know anyone who truly wants something that can do everything. They want something that can do what they want without too much time and effort put into it. Every time we require our users to expend time and effort that is resources they are spending. If the cost is too high they will simply look elsewhere. Believe it or not, the worth of time and effort are readily quantifiable by looking how much people spend a year on unneeded conveniences. It is pretty high.

An example of time and energy wasted is logging into open services. Logins are inevitable but why in a world that prides itself on community are we beaten to the single signon party by the likes of MS Passport or Google checkout? Taking an example from Sound Juicer, the cd ripping app, I have a number of cds which I pick up at local venues because I heard something I liked when walking by. Sound Juicer gives you the option to upload track info to the MusicBrainz database. Unfortunately all this option does is bring me to a login/signup screen after I took the time to enter in all of the track data. Having to get yet another account for something I don’t really care about anymore because I already have the track info is just too much effort to spend so I end up just closing the browser window. Sound Juicer and MusicBrainz does get the consumer seal of approval for making it easy to grab track info when ripping my cds but they missed an opportunity to convert me into a producer which would bring even more value to their consumers. In fact the track grabbing functionality is so transparent - no configurations needed, no extra actions are required - that it is a quintessential example of how an app should be productized. Why adding to the DB isn’t more wiki like or federated with other open services, such as wikipedia, slashdot, lwn, distributions, etc. is somewhat of a mystery. It isn’t a mystery altogether though -

Time and effort on the producer side needs to grow and producers need to work closer together, building bridges instead of just looking to grow their own little island. The Open Source ecosystem, while priding itself on community has often neglected to build technology which works like a community. More cohesion between these islands allows them to grow and innovate on their own but still act as an integrated/efficient experience for the user, minimizing the time and effort it takes to use our software. By having an integrated experience all the way to the producer level we have more of a chance to convert consumers to producers thereby adding more time and effort capital to the entire ecosystem. Make it easier to both consume and produce in the Open Source ecosystem and traditional economics will take over to propel it to the mainstream as it has done in small subsets such as in the business server market.

After reading Jeremy’s blog on the book Don’t Make Me Think I started thinking. That’s part of my job - to think about a subset of problems that plague a subset of individuals so they don’t have to. I haven’t read the book yet but I plan to pick it up at some point. My conjecture is mostly in addressing the “boring makes people comfortable” part of Jeremy’s though I am in no way debating any of his conclusions. I’ve often argued that boring can be a good thing because “thing’s don’t become useful until they are no longer exciting”. Not being someone who views the world in black and white I have also argued the opposite (all be it pretty sarcastically). Both view points are valid as you really need to strike a balance between familiar and new in order to have a successful project. So as I was thinking about all of this I wanted to come up with some talking points for thinking about where that balance is.

What if everything was possible what would the world look like?

Here we define any possibility as being a world with no rules, no systems, no constraints. I know, it is pretty much a kōan because it “contains aspects that are inaccessible to rational understanding”. If rules, systems and constraints are not possible in a world where everything is possible how can everything be possible? But if rules, systems and constraints do exist in this hypothetical world, don’t they work to restrict possibilities to a predictable path thereby deliberately making some things impossible?

Thankfully we do live in a world governed by rules we call natural laws, which actually brought about the possibility of life as we know it. Technology is pretty much built on top of these rules and constraints. We harness these systems of rules to obtain predictable results within some threshold of error. That is exactly what projects are, putting together rules in new combinations to obtain a desired result. We can choose to use the same rules people have found in the past to obtain the desired results or we can test new combinations in an attempt to find a more efficient path. Both have their advantages and disadvantages so the choice must be made per project based on cost/benefit and risk analysis.

Scoping Constraints as a Creative Catalyst

I keep coming back to this PBS special on a New Hampshire photo artist who’s life’s work consisted of black and white photos of body parts sticking out of still water. The pictures of a hand and forearm, breaking the surface of a pond with the mirror reflection almost an exact duplicate were both simple and breathtaking. I can’t quite remember the guy’s name but the essence of something he said I can’t forget. What he basically said was by restricting his medium he was able to challenge himself to be creative. Not any black and white photo of water and a hand would be art worthy - he had to really figure out what path would work within the rules he had set for himself. He may have never found it if his rule set was too complex because in the expanded set of possibilities that comes with a more complex rule set comes more combinations that just won’t work. (BTW If anyone knows who I am referring to, let me know. I feel bad referring to him but I can’t remember his name)

Mutation as a Cure to Stagnation

That is not to say your rule set can’t be large, just that having constraints helps move a project along and helps focus on the final goal by having ready to find answers to those little roadblocks that projects run into. Also if the constraints are shared among projects it means those projects can easily share ideas and complement each other. However too ridged constraints can lead to stagnation. Sure users may feel comfortable with them now but will they find the constraints limiting a year from now. Will something that uses new constraints or slightly tweaks the current constraints be perceived as so much better that the cost of a brief period of unease is worth the switch? Will a new batch of users be available with no preconceived notions of how an outcome should be accomplished?

Progress can be defined as “gradual betterment”. In the natural world that often happens via mutations. The ones that don’t work out die out pretty quickly but the ones that can survive and flourish stick around. Mutations are a risky venture but without them there is no progress. For projects, gradual mutation, or in Jeremy’s words, iteration is a must. This doesn’t mean that innovation has to move at a snails pace. In fact projects can often jump start the iteration process by iterating over other projects, even bringing in the ideas of multiple projects under one umbrella. The threat comes when the goal itself is innovation and not solving an actual need; where the rules and constraints of a project are defined and redefined at every step.

Where’s the Balance?

The glib answer is, where it would make a project the most successful. Each project needs to figure out where that point is for them. Stick to the well worn path and risk obsolescence or blaze your own path and risk uselessness. Most projects stick to somewhere in between where the rewards are much more balanced with the risk.

We see bad design around us all the time.  Often adequate design wins over great design .  In a ecosystem based on limited resources (time, money, component parts, etc.) at what point does a better design start giving diminishing returns?  Is this a good thing? - That problem has been solved we should move on to the next - or is it a bad thing?  - The solution to that problem causes adverse side effects but the cost of fixing it is too high.  In a world of limited resources it often takes a large catalyst or new markets to disrupt entrenched adequate design. I suspect there are good and bad sides to every decision here with some situations leaning further one way or the other.

That is a good leeway into my next thought about design in that decision making is a huge part of good design.  Decisions are hard.  Avoiding them has its cost.  My favourite is that collectively avoiding a decision makes it harder for other decisions to be made down the road.  You need to decide if it is worth the cost.

Ok so it isn’t all JavaScripts fault and Mozilla’s ‘let’ keyword might have just solved some of this if everyone would just support it, but take a look at this bit of hack I had to write.

public_methods: ["insert_row", "append_row", "remove_row", "json_load"],
    public_signals: ["ready"],
    bind_api: function(api_list) {
        var self = this;
        for (var i in api_list) {
            var pm = api_list[i];
            var name = pm + ".mokshagrid";

            // proxy pattern (used for javascripts busted scoping rules)
            (function() {
                var proxied = self[pm];
                if (!proxied)
                    throw ('ERROR: binding api "' + pm + '" failed - method does not exist.'); 

                self.element.unbind(name).bind(name,
                    function() {
                        return proxied.apply(self, arguments);
                    });
            })();
        }
    },