create new tag
, view all tags
The December 2003 issue of the Linux Magazine has an interesting article on "The other open source OS" by Steven J Vaughan-Nichols. It gives a good overview on BSD and where it makes sense to use BSD.

The article mentions that "users who've never felt quiet at home with the GPL also tend to feel more comfortable with BSD." And it continues, "With all this going for BSD, why haven't you heard more about it? ... Linux has always had a strong, centralized group of developers with Linus at the helm. In contrast, the BSDs have all gone in separate directions, and both individually and collectively haven't attracted a tenth as much attention from either developers or the public."

I am not quoting this here to start BSD vs Linux debate (this has been done more then enough on the web and in mailing lists). The point here is that the distribution model scales much better then a fork model.

We should work on enhancing the TWiki core and Plugin API so that different TWikiDistributions like for example TWikiForGForge can benefit from a strong TWiki, and we should work on enhancing the process so that contributions can be incorporated more efficiently.

The plan has been laid out in AppealToCodevCommunityByCoreTeam. Please help us in reaching that goal. We are much stronger if we work together on a good distribution model.

The same holds true also for Plugins development. We are much stronger if we continue to use the Plugins web as the central repository for Plugins, Add-ons and Skins. We are weak if there are several repositories and incompatible enhancements.

-- PeterThoeny - 06 Dec 2003

Distribution models only work if the people who run a project listen to the various people who work on or offer to work on code and don't out of hand reject things (either actively, constantly ignoring or forcing endless debate) that are found to be useful to a user community. (Each developer here represents one or more such communities of varying sizes)

Since I stopped trying to get core team approval for my work and just got on with it giving things back to the community the only way possible - by forking like TWiki did originally - oddly enough I've been able to just get on with it

... And actually get back to having fun, rather than hassled at trying to get people to listen, not break my data and breaking some opportunities as a result, and stop implementing features which are half baked and not documented because the alternative uses something they don't like, but would resolve outstanding bugs in TWiki's codebase and make maintenance easier.

Reasons someone might start a fork:

Many developers facing these issues would simply cease providing code back to the community - as I note many have done over the years.

The logical conclusion for someone who wishes to just get on with things and have fun is to run their own fork, or go somewhere where the centre is not controlled, but merely directed allowing everyone equal rights and where releases are made often and early. ( Which is precisely why the Plugins web works so well )

Since the previous posters comment paints one side of a gloomy picture of the concept of forks - which only happen when communities are exclusionist (the BSD core team model) - some alternative viewpoints from people on forks:

    Sure, you can want to live in your own world, and try to keep the riff-raff out. That's the argument I hear from a lot of commercial developers ("we don't want random hackers playing with our code, we don't believe they can do as good a job as our highly paid professionals").

    The argument is crap. It was crap for the kernel, it's crap for gcc. The only reason you think "anybody" can program kernels is the fact that Linux has shown that anybody can do so. If gcc had less of a restrictive model for accepting patches, you'd have a lot more random people who would do them, I bet. But gcc development not only has the "CVS mentality", it has the "FSF disease" with the paperwork crap and copyright assignment crap.

    So you keep outsiders out, and then you say it's because they couldn't do what you can do anyway.
    -- Linus Torvalds

Forks tend to fail in a GPL environment since the most open fork "wins" - in practice this means that the winners are the community, not any single individual who acts as control. Exclusionist forks drive people's code into the most open fork - as has been shown time and time again as this article describes:

    Oh, you forgot that your work was under the GPL, didn't you? By forking off, working on, and distributing your variant of a GPLed work (the Linux kernel), you consented to issuing your improvements under the GPL also, for other people to freely use. So, you only thought you were creating Fooware OS; in fact, you were creating a better Linux.
    -- http://linuxmafia.com/faq/Licensing_and_Law/forking.html

Forks are not undertaken lightly - they are effort and hassle - as both contributors to this page know - both are forks of previous projects. However it's worth noting that in some people's eyes...

    Maybe the right thing to do is to consider every open source project a "fork" of some previous effort. After all, you can't write a (halfway-decent) webserver these days without learning from the Apache project, even if your goals and codebase are completely unrelated to theirs. You can't do much with a browser without looking at Mozilla.
    if any group of individuals feel the need to fork, then it has more to do with a failure of the way the project is managed than anything else.
    basically, if you have to fork, it means that the people you are forking from are incapable of being flexible, and that both you and they have failed to negotiate a perfectly reasonable sharing of space.

    in other words, someone has all the power, and doesn't want to give any of it away. -- http://www.advogato.org/article/681.html

Forks in a GPL environment serve only one thing - to better the community. They only fragment the community of features & code don't flow both ways. Disallowing forks however goes against the community since it means that a small number of individuals feel they can veto all development unless they think it's right. In the end though, that's the wrong approach no one knows in advance whether something is stupid or not, unless they're already done it or have a solid basis for arguing otherwise.

Final quotes of other people who appear to feel similarly (obviously not the same) about collectively owned code or data:

    "Collective ownership increases your feeling of personal power on a project. You are never stuck with someone else's stupidity. You see something in the way, you get it out of the way." -- Kent Beck

    Yeah, I wouldn't have said it that way. It was a turning point in my programming career when I realized that I didn't have to win every argument. I'd be talking about code with someone, and I'd say, "I think the best way to do it is A." And they'd say, "I think the best way to do it is B. I'd say, "Well no, it's really A." And they'd say, "Well, we want to do B." It was a turning point for me when I could say, "Fine. Do B. It's not going to hurt us that much if I'm wrong. It's not going to hurt us that much if I'm right and you do B, because, we can correct mistakes. So lets find out if it's a mistake." -- Ward Cunningham

    Both quotes from: Artima, [[http://www.artima.com/intv/ownership3.html][Collective Ownership of Code and Text ]] - Dealing with Disagreements

An oligarchy essentially says "we know better than you". "We layed(sic) out a plan for future development". Who are you to say what we do in our spare time? How we work in our spare time? Who are we to say what you work on in your spare time? Who are we to say how you work in your spare time? Make it difficult and awkward people move elsewhere. The closest, easiest hop is the Plugins web - where there is no control. For some things though, it isn't.

Forks are a fact of life for open source & GPL. You can either suck the life out of a fork by subsuming it's codebase and moving forward, bettering the whole community or fail to service the community. Personally I can't see how it threatens TWiki - if you do the obvious thing and suck out all the functionality, the fork withers and dies and everyone gains.

-- MS - 06 Dec 2003

  • Aside: MS, I think your time would be better spent coding than arguing.

-- JonathanCline - 10 Dec 2003

"We are weak if there are several repositories and incompatible enhancements."

If this is important, then the way to avoid this is to let people use the repository the way it is designed to be used. Undesired implementation is the failing of project management, not the programmers doing the work.

-- JonathanCline - 12 Dec 2003

Refactored out LicenseDiscussionsAroundGPL.

Jonathan: I was referring to folks who publish Plugins and incompatible enhancements on their site instead of TWiki.org.

-- PeterThoeny - 12 Dec 2003


This might be rambly discussion, if it's viewed as unhelpful please delete or summarise, or perhaps spin off to a different topic.

How to explain this the without it being taken the wrong way... Anyway here's a go.

> I was referring to folks who publish Plugins and incompatible enhancements on their site instead of TWiki.org.

Why would anyone do this? Because they have found the enhancements useful. Indeed TWiki itself was started because (AFAICT) you needed some things that weren't in JosWiki so you wrote them and released them back to the community - with the method being releasing your code. You published incompatible enhancements on your site. (Please correct me if that's inaccurrate, but it is the gist I think )

For you this situation is a double edged sword - you get features & code that you don't write at the expense of "having" to put up with criticism and complaints. At the same time, you will often write a feature that you need and release it - often without discussion in advance, and sometimes against the "will of the people" - especially when driven by your local userbase. Why do they go in ? Because your users found it useful, and you think it might be of use to others. Some random examples are:

And so on. This is not negative - far from it, it is very positive - functionality was needed, written and in use. The point however is that this is approach is not an unusual case - a search for "at work" - returns a relatively high hit rate for patches.

I needed named include sections so I wrote it, partly brainstormed on twiki.org, but also through coding and use. The same goes for data and code separation - we had a need for a distributed TWiki, so I made the changes necessary, and it avoids problems like this and this (picking things fixed smile ). Likewise I needed interpreted search formats, direct save (for "wizard" behaviour), improved abbreviations, relative ages for documents in formatted search, spaces in topic names, any variable in search terms, support of UseModWiki notation, a parameterisable comment plugin (this was the primary motivation for parameterized includes) and so on.

Meta: the above might be rambly - I'm trying to show motivations for coding - please chop down if you think it is

The point is: you and I are not unique - our users need something so we write it and release it. A survey of many features on TWiki.org, shows that many come from this mode rather than discuss first. (It might be interesting to find out just how many!)

People implement things, because they need them (with varying degrees of ability to say no) and then discuss. Very rarely is a feature implemented on spec without a need and released. Given discussion of any given feature, however small (eg parameterized includes, user web) can take many weeks, this isn't compatible with people's needs. If functionality is changed weeks after it's been use with a user population (even with good intentions) on merged you break their content and their user's mental model.

The situation that user is left in is TWiki.org is no longer compatible with the original source. (Imagine had you been on the other side of the fence when the features above were written and needed by your user base) They are then left with a few options:

  • Maintain a private fork. (This can have a high overhead, and is always at risk of a feature being reimplemented in an incompatible manner)
  • Use a different piece of software
  • Cease making changes
  • Run a separate public fork - this means that the functionality stays available to the originating project, and can prove itself in the wild instead. This model is common in the Linux world, where there are more code forks than people seem to realise. Why? (I'll leave that open smile )

There's more options of course.

In short I picked door number 4 since I figured there may be others in the same situation as me. (After all, "you are not the world" is a common enough phrase on a different online forum I've been on for around 11 years.) The reaction I've seen is that there are.

To my mind this says that TWiki's core functionality is good, and despite some code ugliness people are prepared to hack on it .

NB - almost all code is ugly, mine included. I'm working on the structure to try and improve things, and by doing so in a fork doesn't break your code, but gives me the freedom to so and to make it visible to you, and others in the TWiki community as I do so. This means that if you like it when it's "done" you can sit back and go grab . But operating my fork in the way I do it means that others who think it's bad can just change it rather than just discuss it. Again - better from TWiki's perspective since you can again, just go "grab". (or change it yourselves)

I'm only expending effort on explaining this viewpoint because I think if you embrace (embace and extend? wink ) forks - in the same way the linux community does - rather than deter their existance you will benefit rather than lose.

After all, by making the one recent change you did (which I applaud highly) I can now start redistributing the TWikiUnixInstaller and reinstate support for it. It now picks up a number of extra features from the installer from our fork for free - benefitting your user group, and reducing people's desire to join a fork.

All the above intended as food for thought, and obviously just an opinion. Ignore the bad, take the good. I suspect you are in 180 degree disagreement, such is life. (It would be very boring if everyone agreed on everything)

-- MS - 20 Dec 2003

Features are mainly added to TWiki because they are needed and because they fit the TWikiMission. The same holds true for PreinstalledTWikiPlugins (read criteria for adding new Plugins). That is why you do not find, for example, image gallery features in the core code.

Fragmenting the Plugins repository into different sites is bad because users can't simply visit one site to get the whole picture and repository. A future installer can't automatically grab the latest Plugin. That is why I think that the RandomTopicPlugin comment, "Important - Unsupported. TWiki.org version no longer supported. See http://owiki.org/ for a supported version" is not really a good service to the TWiki community. Hence my note in the Dev topic if someone is willing to take over the maintenance of that Plugin. Same for the CommentPlugin, which would be a great addition to the PreinstalledTWikiPlugins, but is not actively maintained and has quality issues.

-- PeterThoeny - 22 Dec 2003

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2003-12-22 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.