PDA

View Full Version : Combine projects to make one even better project



MadsRH
June 28th, 2008, 01:39 PM
I would like to start a little debate about the vast amount of ridiculously similar project and if a merge of these projects would be a good idea.

Many projects are very similar! Like Rhythmbox vs. Banshee or Evolution vs. Thunderbird - why not combine the effort and make one amazing product! (I know the projects in the example above have many differences)

I think that projects that have the same purpose can share/combine the same "core" or base, like Ubuntu does it with all it's derivatives. For example for bug-fixing process would benefit form this.

Just think of the success of Compiz-fusion. Compiz Fusion is the result of a merge between the old Compiz community plugin set "Compiz Extras" and the parts of the Beryl project that are independent of the window manager core. The outcome is highly customizable and included in many distributions by default.

Please take a minute to submit your view :)

//MadsRH

Barrucadu
June 28th, 2008, 02:01 PM
Why would developers want to merge (ie: throw away) their project and work with another team who started for different reasons?

eragon100
June 28th, 2008, 02:04 PM
Most of those music/video players use the same framework for playback, namely Gstreamer with it's plugin-based architecture, so fixing bugs in playback is already easy. It's mostly the GUI that is different, and I like to have some choice in that manner :)

fatality_uk
June 28th, 2008, 02:31 PM
Linux is about choice. There are merits in combining some projects, compiz-fusion is perhaps one example of a good merge. However, one of the driving factors in many peoples decision to migrate to Linux is choice. Look at AbiWord for example. It fits very well into some distros because of it's low overhead. Combining this with OOo would be pointless.

Zeotronic
June 28th, 2008, 02:56 PM
If you go about combining every similar project, you eventually end up with a bunch of bloated projects... for an example of a bloated project, see Inkscape (IMO). Any of these projects that are Open Source, can combine features as they see fit, without becoming totaly convoluted as they would in a merger. Besides that, as Barrucadu was saying, some of these (if not many of these) projects started for different reasons... have ideals that are vastly incompatible, and have goals which are widely different than each other. Then finally there is the user interface present in these programs. For example, I just cant understand the GIMP user interface for the life of me... its an incredibly functional program with a lot of features, but I prefer Kolour Paint simply because I understand it. If these programs were to merge (or rather, if Kolour Paint was canceled, because I really doubt it has anything to add to GIMP), then I, and probably users like me would suddenly be without a maintained image manipulation program... sure we could still use the old one, but eventually it would fall by the wayside... as all unmaintained programs do.

Mateo
June 28th, 2008, 02:57 PM
Because different people have different visions of what constitutes an "amazing product". Otherwise they would merge. Period, end of thread.

aysiu
June 28th, 2008, 04:10 PM
Why don't all the chefs at independently owned restaurants get together to work on one big restaurant together in order to compete against McDonald's?

1. Competition is fun and drives innovation
2. McDonald's isn't the most popular because it creates the highest quality product
3. Not everyone likes her food prepared the same way.
4. More chefs in the kitchen doesn't lead to better-tasting food - just more arguments

Having more people on a project (software or otherwise) has benefits and tradeoffs. If more people work on a project, more discussions need to be had before development can happen, more arguments and disagreements happen before a consensus can be reached, and more infrastructure has to be put into place to manage all the people involved in the project. Sometimes, believe it or not (again, software development or otherwise), one to three people can be more efficient than one hundred.

Redrazor39
June 28th, 2008, 04:55 PM
I agree with Mateo and aysiu

madjr
June 28th, 2008, 06:02 PM
OP

you forgot to add option 4

-Depends on the type and maturity of a project, they could merge.


projects like movie makers for linux should merge, because none of them works 100% and can't compete with windows movie maker or apple's movie thing.


in conclusion:

immature projects should merge, but very mature ones don't need to.

fatality_uk
June 28th, 2008, 06:14 PM
OP

you forgot to add option 4

-Depends on the type and maturity of a project, they could merge.


projects like movie makers for linux should merge, because none of them works 100% and can't compete with windows movie maker or apple's movie thing.


in conclusion:

immature projects should merge, but very mature ones don't need to.

But what if the immature project is trying to do something radical? What if the approach they take will make a huge difference, but just haven't got up to speed yet?

In addition, you would be amazed at how many projects are started and then fall by the wayside in commercial software houses. Take Adobe, Microsoft, ID, Epic, and hundreds more. I am guessing that their dev labs maybe start 10-20 projects a year that never make it past in-house alpha.

Merging projects could stop innovation!

gn2
June 28th, 2008, 06:17 PM
There are merits in combining some projects, compiz-fusion is perhaps one example of a good merge.

I thought it was just a rejoining of two factions.
As I understand it, originally Beryl was a split from Compiz?

reyfer
June 28th, 2008, 07:19 PM
I thought it was just a rejoining of two factions.
As I understand it, originally Beryl was a split from Compiz?

Yes, it forked, and now it came back. So that is not a good example.

Anyway, Mateo and aysiu expressed my opinion

Isn't it curious that the people voting "yes" are apparently doing so just for the sake of it, since I don't see a reasoning as the ones Mateo and aysiu posted?

fatality_uk
June 28th, 2008, 07:44 PM
Why is it not a good example? By definition, a fork leads to two separate projects. The OP is talking about combining/merging separate projects. A forked project = more than one project, unless my maths is completely wrong.

RiceMonster
June 28th, 2008, 08:00 PM
I can't imagine how boring that would be if all the projects for one area merged. Like I've said before; people who complain about the amount of distros, and "similar" software don't understand what Linux is about in the first place.

Erik Trybom
June 28th, 2008, 08:21 PM
There are simple reasons why free software projects seldom merge.

Starting or forking a project is easy. You only need one person to do that. Growing as a project is also quite effortless from a management perspective - as people come along who want to help, you bring them into the team. While doing this, the source code keeps growing at a steady pace.

Combining two projects is a whole other thing. Now you have your code base, you have your developers, and you have your users. In order to merge you would have to

1) Get your development team to accept it
2) Discard most of your code (if not all of it)
3) Find out where you can help in the new project
4) Get used to a new way of running things.

Of these, number 2 is probably the most important. Merging two projects effectively means discontinuing one of them. Compiz Fusion is no exception - a lot of code had to be rewritten for compability. So the word merging is a bit inaccurate to describe the joining of two projects - it's more like a takeover where one project get the other project's developers.

From a strategical perspective such a move does make sense, but in a world where every programmer is driven by his own motives and can do what he wants, it's not always a good idea.

Zeotronic
June 28th, 2008, 09:27 PM
OP

you forgot to add option 4

-Depends on the type and maturity of a project, they could merge.


projects like movie makers for linux should merge, because none of them works 100% and can't compete with windows movie maker or apple's movie thing.


in conclusion:

immature projects should merge, but very mature ones don't need to.
But if you do that, you suddenly no longer have any immature projects with which to mature... just a bunch of big immature projects. This invokes a 'what-if' scenario...
What if KDE, Gnome, and Xfce were merged?
What if Open Arena and Nexuiz were merged?
What if all the Open Source IDEs were merged?
I'd dare say what if Linux and Windows had merged, but it seems beyond my accepted view of possible scenarios.
All of those projects were (and some of them still are) immature at one point in time... and those that are not now will probably be eventually (except for Windows ;D). The result of merging any of them would probably be a poor one, and a variable number of people would disapprove in each case... myself in the case of all 4 of them.

madjr
June 29th, 2008, 06:11 AM
But what if the immature project is trying to do something radical? What if the approach they take will make a huge difference, but just haven't got up to speed yet?



that's the point, get them up to speed.

create a base

once the base reaches maturity, they can go their separate ways and fork off all they want.

Mark himself stated this on his blog. Projects need to cooperate more. get up to speed and stop using the "i scratch my itch" approach.

but i don't care if they merge or not, as long as they get up to speed to bring a "competitive" product everything is fine.

else, we'll always have the "linux programs are never ready or missing X feature" thread pop-up again and again.

cardinals_fan
June 29th, 2008, 08:03 AM
that's the point, get them up to speed.

create a base

once the base reaches maturity, they can go their separate ways and fork off all they want.

Mark himself stated this on his blog. Projects need to cooperate more. get up to speed and stop using the "i scratch my itch" approach.

but i don't care if they merge or not, as long as they get up to speed to bring a "competitive" product everything is fine.

else, we'll always have the "linux programs are never ready or missing X feature" thread pop-up again and again.
But different people like different bases. If you use distros as an example, there is no one good base distro.

toupeiro
June 29th, 2008, 08:31 AM
Why don't all the chefs at independently owned restaurants get together to work on one big restaurant together in order to compete against McDonald's?

1. Competition is fun and drives innovation
2. McDonald's isn't the most popular because it creates the highest quality product
3. Not everyone likes her food prepared the same way.
4. More chefs in the kitchen doesn't lead to better-tasting food - just more arguments


Fantastic comparison. +1

madjr
June 29th, 2008, 08:35 AM
But different people like different bases. If you use distros as an example, there is no one good base distro.

i don't think the distro example is the best one.

distros are downstream.

clearly the OP is referring to upstream.

distros just distribute what ever is available from upstream at the time.

i think the example of a linux movie maker is valid. Over 10 different movie maker projects, but not one really works or can compete with any basic version of windows movie maker (old or new).

we just have one immature project vs another immature project.

and another good example of wasted resources and fragmentation is the dumb rpm vs deb war.

cool, adobe got packages of flash in .rpm , but not in .deb.... or x package is available in .deb but not .rpm or ....


like Mark said, we just "scratch our own itch"

what ever happened to "i scratch your back, you scratch mine" ?

Erik Trybom
June 29th, 2008, 12:23 PM
I agree on the moviemaker issue, but I think the solution is not to merge a lot of different projects but to get developers to join existing projects instead of starting new ones.


One problem is that the infrastructure of free software developing benefits forks and new projects. The GPL makes it explicitly clear that such actions are allowed and encouraged. What it lacks is rules about openness in other ways than distributing the source code. It doesn't force project leaders to accept contributions to the code from newcoming developers. This is, of course, a good thing. Such a clause would be untenable, but it illustrates an imbalance in the system. You have the right to fork a project, but you don't have the right to contribute to an existing one.

So what's to do about it? I propose every project sets up a clear policy on how to contribute, how to become a member of the team, and how to help in other ways. Ubuntu does this excellently: http://www.ubuntu.com/community/participate. As a counter-example, the Linux kernel has a reputation for being difficult to get involved in.

I believe that ease of contributing is the key to becoming a really successful project. You want to get the best programmers on board, so let them know it! Maybe that way we can have fewer and better projects instead of many small ones that don't go anywhere.

aysiu
June 29th, 2008, 04:39 PM
Projects would be disasters if they were forced to accept all contributed code. I don't see what the point of that would be.

the yawner
June 29th, 2008, 05:49 PM
Beryl was a fork of the main trunk, and thus it wasn't that hard to merge to it again. Especially since it didn't really matured up to a level where merging would take too much work. Besides, while Beryl focused on the features and Compiz was aiming for stability, it's not unthinkable for them to aim for both and thus join forces again to achieve the same goals.

On a side note, I notice that the existence of similar projects are related to the programming language preference of the author. Some leverage the power of their preferred language.

madjr
June 29th, 2008, 08:48 PM
I agree on the moviemaker issue, but I think the solution is not to merge a lot of different projects but to get developers to join existing projects instead of starting new ones.


One problem is that the infrastructure of free software developing benefits forks and new projects. The GPL makes it explicitly clear that such actions are allowed and encouraged. What it lacks is rules about openness in other ways than distributing the source code. It doesn't force project leaders to accept contributions to the code from newcoming developers. This is, of course, a good thing. Such a clause would be untenable, but it illustrates an imbalance in the system. You have the right to fork a project, but you don't have the right to contribute to an existing one.

So what's to do about it? I propose every project sets up a clear policy on how to contribute, how to become a member of the team, and how to help in other ways. Ubuntu does this excellently: http://www.ubuntu.com/community/participate. As a counter-example, the Linux kernel has a reputation for being difficult to get involved in.

I believe that ease of contributing is the key to becoming a really successful project. You want to get the best programmers on board, so let them know it! Maybe that way we can have fewer and better projects instead of many small ones that don't go anywhere.

+1

very true.

the GPL should be renamed to FPL (fork public license)

but i guess that's the nature of the gnu, to fork and reinvent the wheel.

where did the cooperation and standards go?

23meg
June 29th, 2008, 10:56 PM
You have the right to fork a project, but you don't have the right to contribute to an existing one.

You do have the right. And the maintainer has the right to say "No" (http://ometer.com/features.html) to you. The GPL succeeds in that it sets up an environment where the properly protected rights of different parties can reinforce each other and work together and bump into each other, and yet not do damage to the broader system. That's the very central attribute by which the success of large scale legislative systems is judged in modern political science.

What you don't have is the entitlement to have your code accepted into the mainline code flow of a project. But the freedom to share code and fork if needed alleviates that apparent imbalance (and it's only an imbalance from a purely egalitarian standpoint): you can publish the source with your own modifications that may not have been accepted into mainline, so if you're doing good work that has some reason to exist and fulfills the real, existing needs of a group of people, in a manner of speaking, who cares if it went into mainline?


the GPL should be renamed to FPL (fork public license)

No, you should do some reading (http://www.firstmonday.org/issues/issue3_10/raymond/).


but i guess that's the nature of the gnu, to fork and reinvent the wheel.

No, the nature of it is to reuse and build upon others' work. That doesn't necessarily mean having to comply with others' decisions or having to inherit the results of their design, ideology or set of skills at major cost to your productivity.

cardinals_fan
June 29th, 2008, 11:22 PM
and another good example of wasted resources and fragmentation is the dumb rpm vs deb war.

cool, adobe got packages of flash in .rpm , but not in .deb.... or x package is available in .deb but not .rpm or ....
This is what I was getting at. I don't want to use either rpm or deb package management, and I don't see how unifying on either is a good idea.

Erik Trybom
June 30th, 2008, 03:00 AM
Projects would be disasters if they were forced to accept all contributed code. I don't see what the point of that would be.
Of course it would be a disaster! It would be ridiculous, nobody would want to use that kind of license, and that's why I didn't propose any change to the GPL. Maybe I should have been clearer on that point.

What I'm saying is that the inherent nature of free software makes it easier to fork projects or start new ones rather than joining existing projects. This doesn't mean there's anything wrong with the model or the license. It is, however, something to have in mind when you manage a project or think about starting a new one.

I believe that in many cases, new projects are started whose purpose could have been achieved easier by contributing code to an already existing project. That's a problem I want to solve with the proposals in my former post. The easier it is to become involved, the more participants you get. Ubuntu is one great example; Wikipedia is an even better one. The only thing you need to contribute to Wikipedia is a web browser and some knowledge, and as a result they sport 2.4 million articles in English alone.

Mr. Picklesworth
June 30th, 2008, 03:40 AM
The reason why projects don't 'just merge into one' is because they tend to use very different languages and architectures. Rhythmbox and Banshee, for example, may look similar from the front but are absolutely not similar under the hood.
It would be nice, but it doesn't happen that way. However, with universal libraries like GStreamer for video playback, they are still sharing quite a bit between each other.

doorknob60
June 30th, 2008, 07:01 AM
OP

you forgot to add option 4

-Depends on the type and maturity of a project, they could merge.


projects like movie makers for linux should merge, because none of them works 100% and can't compete with windows movie maker or apple's movie thing.


in conclusion:

immature projects should merge, but very mature ones don't need to.

+1, one of the reasons I have an XP partition is for Windows Movie Maker :(

aysiu
June 30th, 2008, 07:04 AM
I believe that in many cases, new projects are started whose purpose could have been achieved easier by contributing code to an already existing project. And if the new projects were forked off GPL'ed projects, all the changes they made in the new project would also be GPL'ed, so the people working on the old project would have access to those changes and could incorporate those changes if they so desired. That's the beauty of open source.

madjr
June 30th, 2008, 05:52 PM
This is what I was getting at. I don't want to use either rpm or deb package management, and I don't see how unifying on either is a good idea.

not saying that they should unify, just stating that they shouldn't had separated in the first place.

the whole rpm vs deb is just frustrating for users and developers alike.

when there are no standards, devs are just plain confused where to go to and how to archive it. They scratch their thing nothing else.

mrgnash
June 30th, 2008, 05:59 PM
Banshee and Rhythmbox come to mind.

Erik Trybom
June 30th, 2008, 07:53 PM
And if the new projects were forked off GPL'ed projects, all the changes they made in the new project would also be GPL'ed, so the people working on the old project would have access to those changes and could incorporate those changes if they so desired. That's the beauty of open source.
Yes, yes. I've said nothing against forks. Most of them are made for a reason, and some of them turn out to be excellent. Ubuntu is, again, a great example.

All I want is for programmers, who realize they want a feature that no application offers, to ask themselves: "Is there an already existing project which I could join to achieve this feature? Must I start writing code from scratch that does what I want or can I just add some code to an existing application?"

At the same time, I want developers who are working on a project to think, "How can we make it easier for new developers to join us? Do we encourage others to get involved with our project?"

There are times when to start new projects, when to fork old ones, and when to contribute to old ones. The GPL makes it easy to do the two former, whereas the latter require a certain level of cooperation. I believe that almost every project would benefit from having a clear policy on how to welcome new developers.