The Birth of a FOSS Application

Joe Barr writes "Brice Burges explains why and how he created a new free software application, as well as what he learned from the birthing process, in a story on Linux.com. The story provides first-hand insights into the frustrations and satisfactions of developers working on free/open source projects. From the article: 'I'm always disappointed to hear open source project members say that they had "their developer" modify an aspect of the program without ever hearing from that developer or seeing any of the code. This is not progressive.'" Linux.com and Slashdot are both owned by OSTG.

Comments

Free != freedom

[EmbeddedJanitor]

Open Source need not mean that the project is open to allcomers. The projects that work tend to be managed by dictators (eg Linus). I currently work on 2 major open source projects and have done some minor work on others. Those that are run as democratic communal projects tend to lose their fiocus and crash onto rocks.

No different from any other software development really.

Re:Free != freedom

[Anonymous Coward]

The Free in FOSS indeed means freedom. Even though many successful projects are run by "dictators" or committees, not by a democracy of all developers, nobody can stop you from making changes yourself. There is a difference between "the" Linux kernel and "a" Linux kernel, and the Free in FOSS means you can have your Linux kernel and other people can have other Linux kernels. The project may not be open to all, but the product, the source code, certainly is.

Re:Free != freedom

[TheLink]

But if I had to choose between a Linus-approved Linux kernel or say Redhat/Suse's Linux kernel, I'd go for the latter.

Re:Free != freedom

[TekPolitik]

I've had some bad experiences with "dictatorial" projects; you typically have to go through a lot of red tape in order to get simple fixes in.

This is not so much a problem with the project being dictatorial as with the style of dictatorship and the dictator(s). A dictator who does not trust others at all will have a project that turns off new developers and ends up with much slower progress than a dictator who gathers more trusted people and seeks to nurture new developers.

Back in the 80s and early 90s open source project managers used to be highly responsive, and the irony is they were often using more primitive tools at the time. This was something that came from attitude. We were all contributors working towards common - or at least compatible - goals. Lack of responsiveness comes from an attitude that says only the project manager is providing a service, ignoring the fact that somebody offering a patch is also providing a service.

You can still find projects with the older - cooperative - attitude. My recommendation is that if the project you are trying to contribute to does not appreciate you, you find one that does. You should not have to put up with being treated like crap when you are trying to help a project out.

Where project dictatorship becomes a problem, it is because of a failure in the dictatorial model used or in its application - fundamentally it comes down to project management failures. The biggest project management failures are these:

1. The absolute biggest failure is when those managing the project allow patches to go without application and without any response. Quite frankly a project manager who allows this to happen regularly should be shot, or at least replaced in short order. This never seemed to happen in the 80s and we should not accept it now.
2. Second on my list of project management failures is when the project has strict requirements for patches that are not clearly documented. Take a look at the original GNU coding standards and patch submission standards - these spelled out exactly what you needed to do to get the patch accepted. If the dictators respond to a patch pointing out failure to comply with a rule (or drop it due to such failure) and they cannot point to the rule in the project's patch submission instructions, then they have failed to plan to maximise the value of labour going into the project. They are valuing the time of other contributors at nothing instead of looking at the right way to allocate their own efforts to support the efforts of contributors to get the highest output volume.
3. Third on my list of OSS project management failures is when the dictator fails to recognise or adequately comprehend the legitimate existence of different audiences for their product. Such a dictator will reject features because they either do not see the need for them for their own uses, or they do not understand how the feature or its implementation relates to the different audience. Frankly it's idiotic for a dictator with no experience in and understanding of an alternative use domain to tell a developer who is experienced in that use domain what features they need.
4. Fourth is not so much a project management failure as a failure of attitude. Some communities become insular and start to treat contributions from outsiders as being unworthy. If you are unwilling to treat new contributors as being as worthy as long term contributors, then you will have fewer new contributors willing to put in the time to become long term contributors.

There are others, but these would probably cover 95% of cases where OSS project management is being conducted in a way that hurts the progress of the project.

Re:Free != freedom

[Osty]

Huh? Do you even know what "Free Software" means? Sheesh.

Well, the Wikipedia definition says:

software which can be used, copied, studied, modified and redistributed with little or no restriction beyond the requirement that the source code must be made available for any binary distribution of another party's free software.

By that definition, BSD and MIT are not Free Software licenses because they do not require you to distribute the code for any changes you may make.

On the other hand, Wikipedia defines Open Source Software as:

any computer software whose source code is available under a license that permits users to study, change, and improve the software, and to redistribute it in modified or unmodified form.

Note that there is a distinct lack of requirement to distribute your own private or public changes to such source code. Thus the difference between Free and Open Source is whether or not you must make available the source for any changes you make to the code. Free Software is a subset of Open Source Software. Free Software will always also be Open Source Software, but Open Source Software need not be Free.

BIG CLUE STICK --> The BSD and MIT licenses are Free Software Licenses!

No, but they are Open Source Software Licenses.

Advertisement

[Imexius]

This article sounds like an advertisement more than anything else.

Different projects, different styles

[jd]

There is no all-encompasing style for Open Source, Free Software, or any other variety of the beastie. There is no Universal Way, no Grand Master Plan that all must follow, and no guaranteed recipe for either success or failure. There is only code, tended to by a cooperative under the policies of that cooperative, for no benefit other than the scratching of a collective itch.

One of the very reasons the term "Open Source" was so heavily slammed in the early days was that it meant too many damn things to too many people (some of whom might also be damned). People, as a whole, adopted it despite those objections and often belittled those who raised them. Now we're finding out that some of those same people are finding out that Open Source does indeed too many different things to too many people, and that people really are trying to achieve different results. Congratulations. Should I break into applause or just do a Kerr Avon impression and throw these people out the airlock?

Nice Checklist

[jlarocco]

The checklist on the lower right is probably the best part of the article. It's all pretty obvious stuff when you think about it, but nice to have it all listed.

Don't say "FOSS"

[YGingras]

Don't say "FOSS". If you mean free software, write free software; if you mean open source, write open source, write open source; if you don't know the difference, look it up because there is one and it does matter. By using an empty term like "FOSS" you alienate both worlds by you lack of commitment. I bet some people even pronounce it like "fuss". This is removing all the meaning that was left from the term.

Not really

[jesterzog]

I didn't see anything hypocritical about it. He stated pretty clearly that the reason he didn't fork an existing project was because he couldn't do so and achieve his goals, and he gave several reasons. (eg. Nothing had the right framework for where he wanted to go, he wanted the experience of developing his own project, etc.) Also, immediately after the part that you quoted, he says:

"I hope to transition poMMo development efforts to a wider group of individuals. I am always happy when others seek to help out, maintaining open discussion and policy."

I think he fully understands that people have a licensed right to modify the code, and is okay with this. He simply thought it was disappointing that people who do this often don't bother to make their changes available back to the developers. If anything, he was just mentioning that he wants to make his own project one where people are actively encouraged to do so.

It's not exactly a revolutionary article in FOSS development, but it's handy for anyone who wants a general idea, and hopefully people don't blame him for writing a simple article when it was Slashdot that decided to link to it.

Re:Not really

[Kjella]

I think he fully understands that people have a licensed right to modify the code, and is okay with this. He simply thought it was disappointing that people who do this often don't bother to make their changes available back to the developers. If anything, he was just mentioning that he wants to make his own project one where people are actively encouraged to do so.

Well, I haven't heard much about the project but I assume it's not a very big one. Why don't people contribute back? Well, here's a few reasons:
1. They don't want to argue about if, as in it scratches my itch, I don't care how/if it fits the big picture
2. They don't want to make it production quality. I've hacked around stuff to make it to exactly what I need, whatever else breaks I don't care.
3. They don't want to follow a coding styling, naming convention or document it aka "I did it myyyyyyy way".
4. They don't want to be bugged about bugs in their code.

In short, if you're taking over an unknown code base of unknown quality with an "upstream" that's not really interested in helping you out, it might easily take you just as long as rewriting it yourself. Work on the developers that actually do come back and say "I'd like this to become part of the main application.", and be very friendly, helpful and mostly forgiving with them. I think that'll pay off far better than trying to lure out people's pet modifications.

Re:How much effort should a person go to?

[gregmac]

I ran into an annoying little bug with Perl Win32::SoundRec, figured out how to fix it, patched my own system, and then spent 30 minutes trying to find info on where to submit the fix. I finally emailed the author and got no response. Months later, the bug is still there. The fix is three lines of code and two extra calculations. That's a real problem, but it's really a fault of the project, not the open source process in general. The nice thing about this is you can at least post your patch somewhere (like the mailing list) and at the least other users who encounter the same problem can fix it. At best, if the author never comes back and fixes it, someone (or you) can fork it and maintain their own version with that and possibly other fixes/enhancements..

So, when I as a 99.9% user tries that 0.1% of the time to contribute, why is it always a pain? I would love to contribute. If the bar were lower, if I could take a 1-line fix and get someone to pay attention, or if I could take that bug and get support in debugging it other than "compile it yourself", I am sure my contribution rate would quadruple. Again, it's really up to the project. I've been involed with projects where the only interaction between the developer and users is a forum (eg, this is where bugs/patches/etc go) and although it's easy to contribute a patch (just post a message), it's incredibly irritating in many other respects. There's no real way to "track" bugs/patches, they're just messages that eventually get lost on page 2+ (I say this as a user, but I'm sure the developer(s) would have as hard a time as I).

On the other end, some projects use ticket tracking systems that are overly complex - eg, you have to register first, and then fill out 50 fields, search 4 or 5 times to be sure it's not duplicated, etc. In some projects this tracker is not linked to from the main web page, which makes the process even more difficult. In some projects, after reporting a bug you'll get a response "please try in the latest cvs/svn version". All of these things add up to make it a hassle for the causal user to report bugs. From a developers point of view, they mean the developers (who are volunteers, remember) spend less time going through false bug reports.

I think the answer lies somewhere in between. Having to register is a response to spam - there are a lot of spam bots that attack the common bug tracking systems. Having too many fields is annoying, but in a big project it can be useful to get people to report the proper information and be sure the right people look at it. Sometimes asking the user to try the lastest version is appropriate (eg, if there's a possible fix in, but not totally tested for all cases), but sometimes it's just lazyness.

I'm active on a decently large project now, and there are a LOT of false bug reports - bugs reported in branches that are obsolete (and have been fixed for a year), people posting what amounts to help questions as bugs, and bugs that say "____ doesn't work" (eg, utterly useless). Luckily we have non-developer users that go through and close these, ocasionally CC'ing a developer to ask if it's legitimate. However, not all projects have these, and indeed, we didn't for the first year or so of existance. As a result, there were often bug reports that would sit there for a long time before someone got around to going through them. Let me tell you, it's pretty annoying to spend 30 minutes trying to duplicate a bug, only to find out in the end it was a configuration error or some other unrelated problem, where if the user had read documentation they would have solved it.

So basically what it gets down to is: do you make users spend slightly more time to file a decent bug report, or do you waste lots of developer time (in aggregate) tracking down false bugs? Since it's usually the developers that set up the bug tracking system, guess what the answer is...

Contributions

[Netsensei]

The involvement of the person behind the project is really important. Submitting bugs and patches is one thing, but if none one looks at them, why bother? In fact it's a two way route: the more involved the original developer, the more people will take interest in the project.

I submitted bugreports on several occasions in various projects. Most rewarding was when I submitted a small bug in Magpie. I got a personal reply by mail from the original developer. Seeing how your solutions are considered by the developer and how your contributions matter is big aspect of what's open source all about.

There isn't one and it doesn't matter

[Per Abrahamsen]

The Open Source Definition was an attempt to formalize the requirements of free software, and any difference between the lists of open source licenses and free software licenses are due to nuances in interpretation, rather than anything substantial.

There is a philosophical difference between the main advocates of "free software" and "open source", it just doesn't matter for the majority of developers who just want to share something cool they have done. From my own days as a free software project leader, I'd estimate that for every developer discussing the ethical implication of various licenses on the net, there are 99 who couldn't care less about the license, and would even contribute their code to proprietary project if that had been necessary to make it available to others. [Of course, for every developer discussing the various licenses, there are also 99 non-developers with the mistaken belief that their opinions matter. ]

In conclusion, stop trying to create an artificial ridge between free software and open source when it isn't there or doesn't matter, depending on your point of view. It is 99% overlap, the remaining 1% is just enough for ESR and RMS to stand alone and feel important.

Re:There isn't one and it doesn't matter

[a.d.trick]

There is a philosophical difference between the main advocates of "free software" and "open source", it just doesn't matter for the majority of developers who just want to share something cool they have done.

The funny thing is that one of the things we argue about is just this: how much it matters. Generally open source fans go for the "it doesn't matter" side while the Free Software people feel the difference is fundamental to their position (which it is). To the open source guys, we Free Software supporters look like self-important fanatics quibbling over inane details as if our only goal in life was to create strife with our allies. On the other hand, Free Software people see the open source movement as sell-outs. We want a system that is not only free now, but forever. We see temporary freedom as a nasty form of trickery, and products like the Tivo are ultimately failures as far as our movement is concerned.

Just because you think something is unimportant doesn't mean the other guys think that same, and it certainly doesn't make the issue go away.