Hey there!
So, one of my assignments at the moment is to write piece on open-source software development. I have some experience of this, but I thought JMonkey would be a great place to ask :).
I recall a discussion on t0neg0ds topic prior to the release of the epic GUI plugin as arguments against it’s release were posed because of prior problems that arose. I guess from work becoming split and not combined? Open-source projects I guess offer more opportunity for the projects to fork, and for work to separated rather than combine thus resulting in multiple projects that each have their own advantages and disadvantages and no single solution.
Are there any comments on this? What other advantages/disadvantages are there on open-source project collaboration, decision making, etc? Is it better to have one ‘dictator’ who can sign off on decisions or for decisions to be reached by voting?
Could there be problems where users want more fancy features(and these being more fun so are more likely to have people working on them) at the expense of the less-boring but possibly more important tasks being complete?
Advantages:
- Creates communities (jME3!!)
- It makes really sophisticated programs available for anyone
- Creates opportunities for people with an idea, to start it off, and it be finished by many
- Companies which use Open source software benefit from it being improved, and so can put manpower behind it (i.e Facebook with MySQL), so everyone benefits in the end.
- Allows people to dig through code of others and learn from them.
- GSOC (Google Summer of Code) teaches students, and helps open source projects
Disadvantages:
- A lot of projects often get abandoned (jME2!!!) (but then an advantage, they can be picked up by other people (jME3!!)
- There will be some stuff about direction and control over the project, but i’m not so familiar with the issues here
I’m sure you can dig some stuff about Android. It was a very “closed” open source project at one point
Hmmm…
I think the only disadvantage to opensource is a greater potential for lack of common direction and focus. At some point, your vision needs to be decided by few people and driven by a single person… and at this point (aside from contributions, which are typically reviewed and rewritten), you’re back to closed source–or a project with so many forks it looks like a snapshot of an explosion.
It is also hard to know when to make something opensource,as well. Nothing (well, almost nothing) starts out that way. It is usually developed by one or two people to start and then moves in that direction once enough interest is generated (which is exactly what I am hoping to do with the GUI library at some point, as there are so many people just in this community alone that are worlds beyond my abilities in coding).
Once the interest is there, I believe opensource is a far better idea, as people tend to inbreed ideas after a while without fresh perspectives.
@avpeacock said:
Could there be problems where users want more fancy features(and these being more fun so are more likely to have people working on them) at the expense of the less-boring but possibly more important tasks being complete?
Also a very valid point. I know I am guilty of this. I almost have to jump back and forth between these to keep the motivation up.
Different open-source projects follow different strategies.
There’s the “benevolent dictator” model, which works well if the leader is a friendly, collaboration-minded personality. (Linux works that way.) The downside is that such projects tend to get into massive trouble when the dictator loses interest or dies.
Then there’s the “steering committee” model. This can get bogged down if the members of the committee disagree fundamentally, and it does require a written charta so that all rules by which a project runs are made explicit so people at least know how things are supposed to go. On the plus side, projects are less dependent on the continuous committment of individuals. This is the model that the Apache Foundation demands of projects that wish to be hosted by it, and it works well, too.
Forks are not a serious problem in practice. It’s easy to start a fork, but keeping a fork alive requires constant dedication.
Either the fork was over a matter that’s serious enough, in which case both projects stay alive (Linux vs. FreeBSD vs. OpenBSD). Most copy code or at least ideas from each other.
Or the fork wasn’t serious enough, in which case one of the projects simply dies and the remaining collaborators migrate to the surviving project.
Or the fork was just exploring an alternate path, and once it turns out which path works better, the forks merge again.
Then there’s the fork that’s due to personality issues (cdrecord). This is usually the sign of a disruptive personality, and one of the fork then quickly dies because the developers vote with their feet. Such forks are so short-lived that they usually don’t make it even into the news.
And the fork due to policy. The project lead tries to force a policy change and most important developers disagree. Again, a feet vote happens and the original project usually dies. Happened to Mambo (which forked off as Joomla and eclipsed the original Mambo within a year or two).
In all cases, forks remain active until they have served their purpose.
Then there’s the model of actively encouraging forking, but making it easy to merge the forked code back into mainline. This doesn’t work for SVN-based projects because SVN’s merge support, while getting better, isn’t up to the task; the usual recommendation is to use git or Mercurial.
This is an interesting example of how availability of some technology can enable additional modes of collaboration. WIth SVN, a few weeks of independent work can make two source trees essentially unmergeable; with git or Mercurial, mergeability can be maintained over years (and in fact this has been done with moderate effort for e.g. the real-time and the KVM extensions for Linux, until the code could finally be merged into mainline).
Well, how we sort of work when it comes to bringing items into Core is to consider several points, discuss them, and then sort of casually vote on it.
If the module up for consideration is something not too specific, and is going to be maintained, then it is a candidate to go into Core. The biggest problem really is maintenance. It is a large code base and if the owner of that code disappears, then the code gets left behind when large engine updates happen.
We have begun to push more out of core and into separate plugins or modules, enticing the contributors to build plugins for the SDK, for this reason.
As for direction and new features, it really boils down to what people are wanting to work on; be it core developers or the community. It is very much community driven. Often the community will want certain changes and if the core team doesn’t implement them fast enough, the community will implement them and contribute the code. This does cause duplicated work as you mention; several implementations of the same idea. But at least something was added.
It is difficult to get people to combine their code for several reasons. First, it takes a lot of time and would definitely derail the project those devs are working on. Second would be code ownership: sometimes people just don’t want to give it up. This happens in closed-source companies too where people don’t want to let others go in and change their code, for whatever reasons.
I don’t really see it as a waste of time or resources if two people work separately on the same feature, for the reason that their time wasn’t really allocated to the project in the first place. It’s still value added to the project either in code-form or in discussions. However it would be nice if forces could combine and produce one, finished, feature. So I guess there is some opportunity cost. I just can’t get worked up over it.
And, sometimes, forcing the two developers to work together won’t necessarily produce more or better code if they cannot work together.
What I think can have a huge benefit to open source projects is having full time developers focused just on the project. Then they can take in these separate modules and dedicate time to mold them and maintain them.