Slashdot Mirror


Mambo CMS Dev Team Splits

cozimek writes "The popular Mambo CMS developer team has severed its ties with Miro Corporation, the copyright owner on the GPL'd Mambo CMS. You can read more about the renegade dev team."

7 of 177 comments (clear)

  1. Re:Perfect timing... not by sehryan · · Score: 5, Funny

    I guess you picked the wrong week to stop sniffing glue.

    --
    The world moves for love. It kneels before it in awe.
  2. Foundation vs. Corporation, 10 easy questions by pieterh · · Score: 5, Interesting

    Q1. But forking is bad!

    A. No, not unless it splits the team, and even then competition is as good a driver as collaboration. Many of the most successful products come from forked versions that eventually out-evolved their ancestors. Homo Sapiens is a good example.

    Q2. Is it legal to start a new fork like this?

    A. The GPL guarantees this possibility. It's one of the better reasons for choosing GPL'd software - you are assured that if the product is good but the management is bad, the developers are free to continue their work.

    Q3. What about the copyrights?

    A. The copyright allows the owner to (a) define the license terms, (b) change these over time, e.g. from GPL to APL, etc., and (c) sell alternative licenses, e.g. commercial opt-out licenses for a GPL'd product.

    Q4. So the copyright owner could sell opt-out licenses for a fork?

    A. No! The forked code will now have multiple copyright owners - the new and the old code. The copyright owner can only license their own code.

    Q5. What would have happened if Mambo was licensed under a BSD-style license originally?

    A. Probably exactly the same, except that it would have forked earlier. The GPL discourages forking because it gives the copyright owners more incentive to "hold the work together" at some level.

    Q6. Is this bad for Mambo?

    A. Certainly not. It's good publicity, and a little fighting always strengthens team spirit, so long as the enemy is clear. Let's all kick the corporations!!!

    Q7. How do you know all this stuff?

    A. I don't, I'm just making it up as I go along.

    Q8. You're kidding?

    A. Yes. Gotcha!

    Q9. Is that all?

    A. Yes, I'm just trying to get to 10 questions. Maybe that was a bit ambitious. Should I go and change it to "7 easy questions"?

    Q. No, ten is a nice number.

    A. Exactly.

  3. Of course they can. by pavon · · Score: 5, Informative

    The very definition of open source software is that anyone is allowed to modify and distribute it. The GPL was created for the entire purpose of allowing this, so why would doing so be concidered "questionable legal dealings"? There are no legal ramifications whatsoever, except the possibility that they may have to change the name / logo of the project if Miro has trademarked it.

  4. Re:Greeeat. by SpecBear · · Score: 5, Informative
    Actually, this is a much bigger problem with closed source software. Dev team quit? Well then I guess you're screwed until the copyright holder rehires. If they rehire. In the case of Mambo you have several other options available because the software is GPL:
    • Maintain the code in-house
    • Hire someone to make any changes.
    • Carry on business as normal. The Mambo team quit Miro, but they'll still be working on the code.

    So it looks like nothing much will change for people who use the software. If anything, this incident is an example of why you want your business-critical software to be open source. You're not necessarily screwed when somethign like this happens.

    As a counter example: as the tech market was fixing to implode, the VC funding one of our vendors decided that the company would be mroe likely to sell if they used an ASP service model instead of selling software. So they stopped selling their software. There would be no more upgrades and no more licenses; the only option offered to us was to move to their hosted solution. Basically we were screwed. If the software were GPL, we wouldn't have been.
  5. It DOES show the STRENGTH of Open Source by Anonymous Coward · · Score: 5, Insightful

    If Mambo had been a closed source product, and the company that developed it started misbehaving (raising prices, making changes that ruin it, etc.), then the users of Mambo would be _screwed_.

    With closed source, the only choices for Mambo users would be to accept the bad changes (higher prices, etc.), or give up using Mambo.

    But, since Mambo is Open Source, Mambo users are _protected_.

    With Open Source, when a developer starts misbehaving, anyone else has the option of forking the code, in order to ensure that the preferred direction is maintained.

    So everyone should ignore the trolls and astroturfers who are calling this a weakness of Open Source. On the contrary, it is a strength. It protects users from having to suffer at the hands of a disreputable company, as, for example, Microsoft's customers have suffered.

  6. Re:Pulling the rug out by blkwolf · · Score: 5, Informative

    Once you receive a copy of the software under a specific license or terms, that can't be retro actively changed by the copyright owner (Unless that was agreed upon in a contract).

    Take SSH as an example. The original versions by Tatu Ylönen were released under a free license until version 1.2.12. After that he started adding various rescritions to his licenses until finally turning it into closed source purely commercial software.

    The OpenBSD team was able to take the last free version 1.2.12 and fork it into a new project OpenSSH which has since surpased the original SSH (now OSSH) in functionality, features and popularity.

    OpenSSH still holds some of Tatu's original code which he still owns the copyrights for, but since that code was released to the public under a free license with no restrictions on it's use, he can't now come back and tell the OpenSSH developers they can no longer use that code.

  7. As a seasoned Mambo developer... by skelly33 · · Score: 5, Interesting

    ... this doesn't bother me one bit. While this is an opportunity for the Mambo developers to get their act together and formalize the development process in an effort to bring some much needed stability to the platform definition, personally it doesn't make a spit of difference to me because I gave up on using it for anything more than a session management and user registration framework - everything else is custom code, so it doesn't matter how many additional patches, plugins and whatever else they come up with for a new branch because I won't use any of it. Mambo was exciting to me at first because of all the plugins and thrid party support for the platform, but...

    I since discovered that the lack of a clearly defined specification for the platform has done away with the concept of backward compatability which depracates and/or orphans modules, plugins and "API" coding conventions for module developers nearly every other release. This process has resulted in a complete failure to amass wide-spread availability of compatible module/component/plugin support. After spending a couple weeks fine tuning my first Mambo installation only so see a new release with a CRITICAL security patch which was no longer compatible with any of the components/modules I was using, I gave up trying to keep up.

    So all legalities aside, this is an opportunity for the new and improved Mambo team to put together a new and improved product that is worthy of third party developers' time.