In Where Are All The Open Source Billionaires? I used this chart as an illustration:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/05/oh-yeah-fork-you.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/05/oh-yeah-fork-you.html
The Pidgin thing sounds like one of my usability pet peeves; programmers setting up restrictions just because they can.
The old programming principle about being liberal what you accept and strict what you output should be also used for interfaces. Be liberal about what you allow users to do and strict (i.e. consistent) what your program does. Being liberal I mean things like letting users resize windows with widgets that may benefit from being larger and let them use whatever font sizes they deem appropriate. Hard coding fonts and text field sizes is for web designers and (other) clueless control freaks.
Even if you were an interaction designer with decades of experience you will never be able to foresee all ways and contexts that your software will get used. What makes no sense to you may make perfect sense to others and whole issue may be entirely irrelevant to functioning of your program. So, why would you force users to your view.
On example I have red is when someone insisted that Firefox tabs should be used to ONLY group related open pages together in one window and you should ALWAYS open another windows for opening unrelated pages. I sincerely doubt many share his view, but Firefox allows him to do that and others to have what ever combination of pages open in what ever amount of windows they like.
I don’t get it. Just use GTalk.
Speaking of alternative to alternative chat clients, have you tried Digsby? It’s still in beta, but it’s coming along VERY nicely.
http://www.rants.org/2007/06/26/when-is-open-source-not-open-source/
–
For example, take the issue of governance in an open source project. Many projects use the benevolent dictator model, in which one designated person gets to make the final call in controversial decisions. “Designated by whom?” the skeptic might ask. The surprising answer is “It doesn’t matter — because if anyone disagrees strongly enough, they can copy the project and take it in another direction.” In other words, benevolent dictatorship isn’t really dictatorship, because it depends completely on the consent of the governed.
This is a fairly common view of forking, but it’s not quite the whole picture… A lot of things exist in a half-forked state, wherein patches aren’t just made to scratch some itch, but maintained for a sequence of versions of the trunk project.
I agree with what you’re saying, but in reality you have a few more choices than to fork or not to fork.
Its nice to see a project fork just to cater to users… the original devs should get off of their high horses and accept the old truth - “The customer is always right”. 
I guess someone was bitter about all the work they had just done and didn’t want to undo it…
I like the way it was reported as a bug too… reminds me of my own opinion that a serious design flaw, particularly on the UI, should be treated like a bug and not a feature.
User Are Not Designers. There isn’t any more to be said.
A lot of things exist in a half-forked state, wherein patches aren’t just made to scratch some itch, but maintained for a sequence of versions of the trunk project.
I think there are two usages:
-
Forking, as a specific source control / software engineering concept (I would tend to call this branching and merging, ala http://www.codinghorror.com/blog/archives/000968.html)
-
Forking, as a general principle of open source software
“We believe the user should have the final say in what goes into the program”
I see a rocky road ahead for FunPidgin
I can see a problem here, because at least in usability terms, “the customer is always right” is not always true.
Funpidgin is a classic example: “all of them are optional”
This could very well create an unusable interface which eventually will make users avoid Funpidgin. Also, this is one of the very reasons Gaim was “forked” (converted) into Pidgin. Gaim had a very bad user interface with many options.
Don’t underestimate “sensible” or “good enough” defaults, which sometimes should not be changeable. In this case it’s dubious though if not even adding a secret option somewhere deep inside Pidgin or a configuration file could have been mandated.
Hang on a minute.
There are no Amazon referral links in this post.
On forking-
I’ve been dissapointed with the open source community’s support for a Windows C++ IDE. Dev-C++ appears to be no longer supported, and other projects have sprung up from its ruins. Each has its own pecuilar user base but not enough critical mass for me to have enough faith that anything is going to around long enough.
This is where proprietary software seems to have an edge: Visual Studio has a large user base, immense library support, and has been around for eons. Support for it is stable and ongoing and unlikely to get wrapped up in the throws of forking. You can get most of the functionality for free (as in $$) through an Express edition.
It seems many users get fed up with the fork-o-rama and just want something that might limit their freedom, but will ultimately get the job done.
At least I think it is nice that people are able to fork, Instead of the LOTR model:
One OS to rule them all,
One OS to find them,
One OS to bring them all
and in the darkness bind them.
But is a very interesting observation what is dictatorship, freedom or democracy. To some Microsoft is freedom of choice compared to Apple, where others think of it as pure evil dictatorship. A Microsoft developer might think that he is working in a nice democratic environment; where else an open source developer can feel he/she is working in dictatorship.
Right, but (1) is completely undefined in a number of situations; from complete lack of source control to distributed s/c. And, given that, at what point can it be considered a fork? I’m just (superfluously, I hope) pointing this out because this whole “to fork, or not to fork” take on it is juvenile and getting seriously stale.
Consider, for instance, Debian’s auto patch support. Fork or not a fork?
Various alternatives for Lua: (http://lua-users.org/wiki/LuaPowerPatches) fork or not fork?
It should also be noted that, while the debian patches usually are of the ‘play nicer’ flavour, some of the Lua patches can be non-negotiable for the app that links in Lua.
In my experience, the simplistic view of forks is mostly used (as a rolled up newspaper) on the suits. In real life code is a lot more fungible.
“all of them are optional” sounds like way too many options for the user to choose from. See the article “How much control should our users have?” for a nice discussion about this topic (http://headrush.typepad.com/creating_passionate_users/2007/02/how_much_contro.html)
But in case of the auto-resizing textbox I think it would really be the right choice to add a simple checkbox to enable this feature.
Gaim became pidgin due to legal issues with the name ‘gaim’ it had nothing to do with the amount of options or anything else. There was no ‘forking’ or ‘converting’ there. Simply a rebranding, all of the same developers were involved. (I should know, I’m one of them.)
I’d like to further comment that at no point did the pidgin developers “dig our heels in” and I believe a careful reading of the linked ticket (and various email threads about this issue) will bear that out. What did happen is that we believed, and largely still do, that there is an auto-resizing middle-ground which will largely satisy everyone and were attempting to gather feedback in order to improve things for everyone. The problem was that, by and large, most people were uninterested in any attempts to fix things and were claiming that nothing but a complete and total reversion to the previous system was acceptable. It was that assertion which we refused to accept.
I’d like also to point out that in both 2.4.1 and the soon-to-be-released 2.4.2 there have been changes to the auto-resize system to incorporate the reasoned, constructive comments we did receive.
Oh, and one last thing. The resizing patch that funpidgin forked to apply was almost instantly converted into a plugin (that works just fine with pidgin) by the original patch author, once we suggested that he do that.