2010 07 21

From TheCommandLineWiki

Jump to: navigation, search

Contents

Feature Cast for 2010-07-21

(00:17) Intro

  • Review of "The Stars are Right"
    • http://www.boardgamegeek.com/boardgame/37696/the-stars-are-right
    • This is a mythos themed game, inspired by the works of Lovecraft
    • Funny artwork from John Kovalek
    • The game mechanics are tricky at first
    • There is a five by five grid of star tiles
    • Each tile has one of a couple different designs on each side
      • Like one to five stars, the moon in different phases, meteors, etc.
    • You also have a hand of cards
    • By discarding a card, you can move or flip the tiles
    • You need to get certain alignments to place cards down
    • Those cards, ones that are summoned
      • Let you augment how you can change the sky
    • Being able to put cards down also earns points
      • Depending on what the cards are
    • The game is entirely family friendly
    • It lists the age as 12 and up
      • I think that is entirely due to the initial rule complexity
    • Once you get the hang of the rules
      • I suspect the game goes myuch quicker
      • And it becomes more fun as you can start digging into the strategy
    • Since each player's turn changes the stars
      • It is similar to some building games I've played
      • Where you cannot always be sure a tactic will work by the time it is your turn again

(04:02) Listener Feedback

  • From Andrew
  • From Carey

(09:11) Hacker Word of the Week

(10:39) True Burden of Forking

  • This is another thought that occurred to me reading "Here Comes Everybody" by Clay Shirky
    • http://www.amazon.com/gp/product/1594201536?ie=UTF8&tag=thecommandl0a-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1594201536
    • One of the models Shirky discusses is open source
    • He contrasts its resistance to failure with firms
      • Where predictions of failure forms resistance to even starting a project
    • See Shirky pp. 245-247
    • Shirky talks about how open collaboration
      • Can more effectively and efficiently search through
      • A space of probabilities, despite the high number of misses
    • Each failure costs as close to nothing as makes no odds
    • This leads to the conclusion that given enough people
      • And the right tools to allow them to communicate and coordinate
      • Failing fast and often proves to be an incredibly powerful approach
    • I started thinking more specifically how open source lowers the cost of failure
    • There is obviously the fact that money is rarely the primary motivator
    • Open source projects are not really capital intensive
      • So there isn't a pressure to cover initial investment
    • I think it goes beyond that though
      • Otherwise why would open source be so critical to ultimate success?
    • Low financial cost isn't essential to open source
      • Any number of online endeavors can use new cheap and free as in cost tools
    • Being able to freely re-use code is a distinct advantage
    • For lower level components, to can save a project quite a bit of effort
    • In the failure case, new effort is then limited to the focus of an experiment
      • Rather than also bearing the burden of building out common plumbing
    • I started to wonder if this iterative, almost brute force approach
      • Goes even further than that, not just to re-using some code
      • But to how re-using an entire project could interact with this idea
        • Of lowering cost of failure
    • Re-use taken to a certain logical conclusion is completely forking an existing project
    • Forking is the act of taking a copy of an open source project
      • Then starting to change it in an independent direction
      • Kind of like two species of birds descending from a common ancestor
      • But changing after a few generations so that while they still bear a similarity
      • They also are pretty obviously distinct varieties from each other
    • Forking often happens for reasons similar to selection pressure
    • Some set of developers may feel that a need is not being met
      • And that re-using all of a project that is already very close
      • Is an efficient way to make just those changes that achieve that under served requirement
    • Forking is not usually undertaken lightly and often draws rather a lot of criticism
    • I thought I'd try to work through the advantages and drawbacks of forking
      • Especially with Shirky's thoughts on failure and experimentation in mind
  • First, there is a potential upside to forking
    • Despite the perceived stigma or problems of hiving of a new project from an existing one
    • It encourages experimentation that the source project
      • May not have been willing to pursue
    • As I've explained, the cost of trying is kept cheap
    • This is the right reason to fork
      • Trying something incremental new, just a bit beyond the original code
      • Or possibly even radically different but using the old code as a spring board
    • Other externalities are wholly the wrong reason for forking
    • Here I mean things that aren't part of trying something different in the code
    • I think a lot of the criticism of forks comes from splits not inspired by an experimental spirit
    • Very often forks occur because collaborators fail to get along
    • Coding style or other aesthetics can very quickly drive a wedge between teammates
    • Copying code and striking off in a new direction is an alternative
      • To working through such non-technical disagreements to reach an accord
    • Admittedly, sometimes all other means of addressing deep rifts are tried first
    • I merely thinking it is instructive to try to categorize forks
      • By the merits of their causes
      • Rather than categorically state a fork is always a bad thing
    • In the case of a fork that isn't genuinely an experiment
      • It reverses the lowering cost of failure
      • So I am more inclined to agree with the common wisdom in this case
    • Forking without a clear technical difference re-introduces transaction costs
    • There is a decision cost where there isn't a clear difference in the goals of two or more forks
    • A potential user or worse contributor has to select between projects
      • That otherwise are almost entirely identical
    • It isn't obvious how backing one fork over another truly advances the code into new territory
    • If such a fork fails, users may be stranded by a non-zero cost to migrate to the other fork
    • For a developer, that cost is magnified
      • Either by the cost of bring a contribution along when switching forks
        • Where that is possible and acceptable
      • Or re-building code where porting efforts isn't possible or may be frowned upon
    • I do feel I am over-emphasizing this to make a point
    • I think that forking for any reason is unusual, that it bears a unconditional stigma
    • I just wonder if there is a class of forks that is less deserving of this negativity
    • In particular if the idea of experimentation is the focus
      • And more critically the goal of a fork is very clearly stated
      • In contrast to the original effort's focus
  • BREAK
  • Modern version control systems, using acyclic directed graphs, confuse things a little
    • I had an online conversation with a couple of acquaintances a while back
    • We were discussing github's very prominent use of forking
    • The fellow with whom I was corresponding thought this was a bad idea
    • He worried about the fracturing of code bases that are to readily forked
    • I'll consider the consequences of those
      • Bearing in mind Shirky's points on cheap experimentation
      • In a moment
    • Having spent quite a bit more time with modern version control
      • In the form of both git for my personal projects
      • And Mercurial for team development at my day job
      • I think I have a better answer for this concern
    • The line between forking code and merely branching it is getting blurred
    • Branching traditionally has been structurally similar to forking
      • But has almost always remained within the bounds of a project and its maintainers
    • Cutting a branch is usually done with the intention of making smaller changes
      • On the same starting version of some source code
    • For instance, a branch is often made based on a labeled release of some code
      • So that any bug fixes can be incrementally added onto that release
      • But tracked very clearly so they can be forward ported to a future release
      • Or even ported backwards to an even older release
        • If the same or similar bug is discovered there
    • Branches rarely focus on some more drastic change
      • Though that is not unheard of, either
    • Usually when that happens, some new goal is a change in future direction for a project
    • Using a branch in that instance boxes up the risk for a big code re-write or change
    • Given how git and Mercurial work, there isn't much difference
      • Between a branch mechanically produced within a project
      • And a fork, or external branch, that someone makes in a clone of a project's code
    • The flip side of the ease of branching and forking with these tools
      • Is the lowered cost of merging, re-integrating changes for whatever purpose
    • They use a much more capable storage structure
    • It is based on a graph which better models parallel changes
      • Than the tree structure used by older tools
    • They also store and track changes, not the state of files
      • So that what are essentially patches that make up the nodes of the graph
      • Can be much more capably stitched together to combine different branches and forks
    • I think graph based source control tools lower the cost of experiments and failures
      • Bringing it down to the personal scale
    • That is why I think github makes forking so prominent
      • So that there users can do so to experiment cheaply
      • And share back any useful outcomes to the source project
      • Or abandon any efforts that fail to bear interesting fruit
  • What about outcomes for forks?
    • Failure is the normal state of open source
    • That is not a deep criticism of the model or its goals
    • Rather it is an observation on how cheap and easy it is to start an open source project
    • Any set of scripts or chunk of code that someone hacks together
      • To initially serve their own immediate need
      • Can very easily be shared out as open source
    • There is good motivation for doing so
      • That other developers with similar needs and interests
      • Can amplify the original effort to spin up some new project
    • To achieve success of some measure
      • The burden is either to find contributors to help the project sustain
      • Which can be more easily accomplished by opening the source and sharing
      • Or to keep up enough motivation to keep developing alone
    • Both depend quite a bit on locating or attracting dedicated users
      • But I don't think that is always necessary
        • Especially for a project where the creator or creators are motivated users, too
    • In the absence of use by anyone, pure users or self interested creators
      • Code runs the risk of stalling out
    • Once it has served its original need
      • Lacking active users robs it of further opportunities
      • To grow and keep evolving in interesting and useful directions
    • For some projects, this evolutionary dead end is acceptable
      • The software has served its purposes and it doesn't matter what becomes of it
    • In other cases, even the original creator realizes the software
      • Isn't what was intended or truly needed
      • But the experience of building and failing was necessary
      • To appreciate this lesson, perhaps even to use it in a future endeavor
    • Very few projects reach a critical mass of users or contributors
      • That see them thrust into wider awareness
      • Most often equated with some level of success
    • The point though is that the cost of trying is so cheap
      • There is far less of a barrier to simply rolling up sleeves and coding
    • For whatever legitimate reasons, if failure is the majority outcome
      • How can you control for forking as a cause of any kind of failure?
    • You can't because I don't think the presence of a fork
      • Is enough in and of itself to deter interest
      • Assuming that each fork is driven by a validly differing purpose
    • I suspect when the difference between forks is less clear
      • Let's say petty forks undertaken for less technical reasons
      • Then that might do more to sap potential from both forks
      • As it is less clear to potential users and hackers why to choose one or the other
    • If a program's promise is very clear, enough to attract use and support
      • I don't think a fork would necessarily diminish that
    • A great enough potential and attraction, enough to succeed
      • Is likely to carry over into each fork
      • Or to survive in one and not the other
      • If the difference in approach and goals cuts against whatever attracts that success
    • I am less convinced that even the discussion of success and failure is all that relevant
      • For reasons of the cheap cost of trying and trying again
      • And because I don't think success is as important, as I'll discuss later
  • BREAK
  • The potential user base is infinite for open source and free software
    • I don't think reasons for failure relating to
      • Failure to attract enough users make much sense
    • The cost to use for a user of open source is effectively zero
      • That absent cost is a defining characteristic
    • Maybe there is some tax in the form of mental fatigue of hopping between alternate projects
      • That focus on the same utility or need
    • Really there is no impediment to growing a user base
      • Other than the ability to attract one solely on the merits of the project
    • One of the main qualities of the internet is its growth
    • Since their earliest days free software and open source
      • Have been closely tied to the internet as a means of distribution
    • Given that FOSS has been in the minority
      • Since the highly visible commercialization of software
      • The growth potential is enormous
    • It is all upside, the Internet is full of potential converts to FOSS projects
    • There are tons of users who may have never heard of them or FOSS as a category
    • They could be convinced to use them just based on being made aware
    • Many popular projects are increasingly being built on portable toolkits
      • Which increase the area to which they can spread considerably
    • But even leaving out reaching beyond the traditional Linux and BSD users base
      • The growth of users on the internet, of people trying out Linux
      • Means that there isn't a zero sum aspect to adoption
    • I am thinking of what Cory has said about e-books versus paper books
    • The market for paper books is saturated so traditional publishers
      • Can only manipulate price and margin to change their degree of success
    • For e-books, we are far from reaching all the potential readers
      • So a more effective strategy is simple growth of the number of buyers
      • And a lower price, like the often free cost of FOSS, supports that end better
    • It would be nice to convince users of proprietary software
      • To be more receptive to the benefits, large and small
      • Of open software, as I've said
      • But it may not always be necessary
    • The growth of the internet means every day there are new people
      • Looking for software to browse, email, instant message, post social messages
      • Basically to share and communicate
    • With new classes of applications, like social network and messaging clients
      • The field is often even more open than with entrenched types like office, email
    • As long as open tools are attracting some of those users
      • Then there isn't any upper limit to scaling adoption
    • Can a project really fail because that infinite potential is split?
    • Or is it down to more of a failing to simply attract users in the first place?
    • I don't think it is relative to other projects given there are more than enough users to share
  • There are many examples of success of comparable efforts, thought not technically forks
    • Fedora vs. Ubuntu are both growing and thriving
      • They are largely constituted of the same packages
      • There are some technical differences
        • In particular for people who are aware of package formats
      • More so in the way the systems of configured and managed
      • At times one may have slightly more advanced versions of particular packages
        • But given how easy it is to update either to newer packages
        • In the longer run that isn't a substantial difference
      • Despite some peoples' fears, I don't really see evidence
        • Of one distribution robbing the other for users
      • In fact, the existence of other distros with further differences
        • Tells me my thoughts on ever increasing potential users are credible
      • Further, both Fedora and Ubuntu allow people to make their own remixes
      • Many of these are pretty popular in their own right
        • But again, not at the cost of impoverishing their parent distros of users
      • There is a deeper split that predates these two, informs their precedents
      • Both are evidence that the difference between RedHat and Debian
        • Wasn't enough to kill off one at the expense of the other
        • Or to weaken both to the point where neither succeeded
      • RedHat has been able to chart considerable commercial success
        • But remains committed to the core value of sharing Fedora now represents
      • Debian has never been about commercialization
        • Yet thrives to the point where Debian can be built on top of it
        • Without draining it either of the interest it needs to keep chugging along
    • Gnome vs. KDE represent a similar division in a high profile area
      • I think the two most popular Linux desktops also demonstrate
        • A pretty valid reason for splitting efforts like this
        • At least back in the beginning
      • KDE uses Qt, a widget toolkit that was not original compatible
        • With either free software or open source
      • Folks, primarily at the Free Software Foundation, were concerned about this
      • If a non-free or non-open desktop became the popular choice
        • Wouldn't it make it difficult for those interested in software freedom and open sharing
        • To be able to run a desktop environment consistent with those principles?
      • I am, of necessity, greatly simplifying this
        • But as I understand it, it was the primary motivation for Gnome
        • Which originally was an independent, new effort to build a desktop
        • That was comparable in features and capabilities to KDE
        • But released entirely as free software
      • There certainly have been times when it felt like
        • One desktop must win at the expense of the other
      • Maybe that was tied into concerns over adoption of Linux
        • Specifically for desktop computers, what most users of PC are interested in
      • We seem to have grown past that point so that both projects are thriving
      • There have even been efforts in the last couple of years
        • To standardize some interfaces so that they can better interoperate
      • That trend looks likely to continue and to improve for the foreseeable future
  • BREAK
  • If a project is still active, it is a success
    • Sure, user count can encourage or discourage development
    • But is that the sole arbiter?
    • Or even the best?
    • For me, as long as a particular bit of FOSS remains available
      • And is still compilable against a current system
      • That is good enough to be considered successful
    • Certainly, the criteria for success are much lower
      • Taking the market largely out of the picture
    • There are often no real capital costs, so no pressure to generate a return
    • The number of users needed to keep a project healthy
      • Can often number in dozens, compared to the hundreds or thousands commercial efforts need
    • I think we need to be very careful when open source is competing with proprietary offerings
    • The browser share, in particular, can make it seem like any of the open browsers
      • Could sink to a point where they ultimately will fail
    • To be fair, Safari and Chrome have commercial backers
      • And Mozilla has grown a considerable organization that is no doubt cash hungry
    • I think the point of tracking browser share is to see the right kinds of pressure
      • On Microsoft Internet Explorer which is just a horrid entrant
      • Not necessarily because it is proprietary or from the Redmond giant
        • Though that undoubtedly is part of it
      • But really because the browser has such a lousy track record
        • Dealing with security issues and keeping up with and supporting web standards

(32:37) Outro

Retrieved from "http://thecommandline.net/wiki/2010_07_21"
Personal tools