The Birth of a FOSS Application 104
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.
Free != freedom (Score:5, Insightful)
No different from any other software development really.
Re:Free != freedom (Score:5, Insightful)
Re:Free != freedom (Score:5, Funny)
Re: (Score:3, Insightful)
Re:Free != freedom (Score:5, Funny)
Re:Free != freedom (Score:4, Interesting)
Linus doesn't really care about stability or reliability of a particular release, he's already basically said he just does what he wants - which appears to be putting in nice new features, capabilities to the kernel, and trying to make it more efficient in most popular scenarios (which is good in some ways).
Sure Suse etc have had their screw ups as well, but they at least do a bit more testing (they supposedly have more resources).
FWIW, an Alan Cox approved Linux kernel counts for more to me than a Linus approved one.
Re: (Score:1)
Given those choices, which kernel would you choose?
Re: (Score:2)
Unless the day comes when you stop trusting Linus. Thus, free.
reputation. (Score:3, Interesting)
In the long run MS is right with their vista development recommendations [microsoft.com]. Not that i would recommend vista! It is just that their style rules make sense for 98% or the users. Users will go
Re: (Score:2, Interesting)
More accurately, the "Free" in FOSS means "GNU/Free", where RMS's definition of "free" is different than most. It's the "free" in GPL which means "free to do whatever you like, so long as your code is publicly available under the GPL if you publicly release your modified software." That's different than "open source" (BSD, MIT/X, etc) where you can do whatever you like with the source, even choosing not to redistribute your changes, so long as you keep the copyrig
Re: (Score:2)
Re: (Score:1)
I always figured the "OS" part covered "Open Source" licenses like BSD and MIT. The 'F' tacked on at the beginning is a concession to RMS's insistence that GPL is "Free Software" and not "Open Source Software". Otherwise the acronym need only be "OSS".
Re: (Score:1)
Re: (Score:2)
BIG CLUE STICK --> The BSD and MIT licenses are Free Software Licenses!
Re: (Score:2, Insightful)
Well, the Wikipedia definition [wikipedia.org] says:
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 define [wikipedia.org]
Hacking code != hacking project (Score:2)
In most of the best run projects you are free to take the code and fiddle ith it. You are not necessarily allowed to modify the project (ie. commit the changes).
Fork all you want, but most good projects are a result of staying focused.
If you disagree, try submitting a patch that Linus does not want and insist that he includes it "because you have the freedom".
Re: (Score:3, Interesting)
I've sent in a one-line fix for an obvious and reproducible error a number of times over a period of nearly two years to a dictatorial project (Indy for Delphi) and they refused to even take a look at it, sometimes not even responding; I should become a member of the development team (which would require several steps) and submit a patch (which would require even mor
Re: (Score:3, Insightful)
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
Advertisement (Score:4, Insightful)
Re: (Score:3, Interesting)
It also shows that small, niche, open source projects can survive. If anything, hopefully it will encourage a few dozen people to get onto Sourceforge.net and find projects they can contribute to.
Disclaimer (Score:2)
Ah! That would explain the disclaimer: "Linux.com and Slashdot are both owned by OSTG."
Re:Disclaimer (Score:5, Funny)
Re: (Score:2)
I won't 'Digg' things. I don't like that site, and don't like the idea behind it. People in aggregate are often blindly shortsighted and I do not trust them to make good decisions about what I should read.
Re: (Score:2)
Re: (Score:2)
When I'm moderating I do. And I often do when I'm following a discussion thread. But, it is also infeasible to have a core group of editors do all the moderating. I think there is a balance to be struck, and I think Digg is on the 'the mass mind has too much power' side of that balance.
Re: (Score:2)
Re:the re-birth of humans being decent to one anot (Score:1)
Re: (Score:2)
Read the source, Luke !
Re: (Score:2)
And yes, if James Joyce failed to demonstrate an ability to communicate using the rules of English grammar and spelling, I would have failed him and gladly.
Re: (Score:3, Funny)
And since coarse invective is the o
Re: (Score:1)
Different projects, different styles (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Hypocritical (Score:1, Interesting)
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.
But he felt it was entirely appropriate to simply start another project because existing mailers didn't have the feature he was looking for? I don't think that's progressive either.
Cute the defence of "but if he feels like it, why not?" Well, precisely. And if other developers feel
Not really (Score:4, Insightful)
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 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: (Score:2)
Then he should be using the RPL [opensource.org]. Any changes have to be sent back to the developers. But that's not free...
Re:Not really (Score:4, Insightful)
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: (Score:2)
Is there a problem with this? Community development is a great thing, but some things are better done on their own. That's one thing I really appreciate about open source software, that I can make modifications to the software for yourself with no strings attached. Some solutions are simply not worth the effort it takes to be merged back with the original code. It would be better to spend you time solving more useful problems.
Re: (Score:2)
I think he'd have been happy just to have someone say:
"Hey, thanks. I needed it to support UUCP so I hacked this on like so: "
That's not asking for CVS rights, looking to merge it, asking him to do anything, just letting him know what use his project it put to so that he could make it better. If ten people admit to writing hackish solutions to something he could use that as a starting point for doing it well.
Feedback isn't required, but helps everyone.
Re: (Score:1, Redundant)
Well, you're not looking at it enough: so he didn't find any project providing the feature he wanted, why didn't he help any existing framework adding the feature?
He doesn't explain it, but that's clearly because he wants to do things his way and he doesn't really care about the users or the other developers to help any existing framework.
Then he is disappointed that people makes change to without sending patches?
That's simple: they want to do things their wa
what. the. fuck. (Score:4, Funny)
Re: (Score:1)
wordnet.princeton.edu/perl/webwn
Time for the talk (Score:1, Funny)
Re: (Score:2)
Re: (Score:1)
Do you know what a metaphor is?
1995 called.... (Score:1, Troll)
Art History (Score:2, Redundant)
Don't say "FOSS" (Score:1, Insightful)
Re:Don't say "FOSS" (Score:5, Funny)
FLOSSY (Score:1)
Re: (Score:1)
There isn't one and it doesn't matter (Score:4, Insightful)
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: (Score:1)
And the grandparent got thumped by a 4-digit ID poster. Splat.
Re: (Score:2)
Re: (Score:2)
If you are right then two terms for the same thing is already too many and we don't need something as silly as "FOSS". You can disagree about the dichotomy but only a stroustrupian philosopher will dodge the issue with concatenation of all the options.
the two terms don't mean the same thing, he's saying that the FOSS term is a superset of both of the other terms that is useful for most people. the words "doberman" and "rottweiler" don't mean the same thing as each other, but "dog" summarizes both of them adequately enough for most people
Re: (Score:3, Insightful)
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 support
Re: (Score:2)
I think the parent point is that most people consider the subtleties of Free vs Open-Source software unimporant. You and handful of others might disagree, but that is still a tiny minority of people interested in FOSS. Fortunately.
Free software vs open source vs most contributers (Score:1)
- The free software philosophers believe that sharing is good for society, and to promote it they share some cool technology.
- The open source philosophers believe that cool technology is good for society, and to promote it they share some cool technology.
Most contributers don't care about what is good for society, they just have some cool technology they want to share. So they subtleties of free software vs open source really is irrelevant to most contributers.
Whether cool
Re: (Score:2)
I don't think that's accurate.
I think its more accurate this way:
- The open source philosophers believe that sharing and cool technology are good for society, and to promote both they share some cool technology, and let pe
Copyleft (Score:2)
Well... (Score:3, Funny)
How much effort should a person go to? (Score:5, Interesting)
I had some crashes with Mozilla and tried to get symbols, it turns out that the release build doesn't have published symbols so my effort to repro a stress bug and capture it in windbg was wasted.
In the pre-1.0 kernel days, I had problems getting two 3c509 nics to work in a box at the same time. With the help of a friend, we made a 3c509-2 driver by copying and changing all of the identifiers. The hack worked, but it was a hack. At the time, I didn't take the time to report the limitation anywhere or investigate further.
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.
Maybe a college student has enough time to spend decyphering how to contribute. I don't have that much time anymore.
Re:How much effort should a person go to? (Score:5, Insightful)
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...
Re: (Score:2)
That's why I now like to torment the users of my software.
Re: (Score:1)
A few times, especially with Perl, I follow the documentation step by step and it doesn't work. Spending time understanding the code, thank God that Perl is by definition open source, I usually find some undocumented dependencies that solve the problem.
With commercial projects and free projects requiring technically complex code, as often as not, I run into documentation that expects you to read and comprehend everything that the programmer had to comprehend to write
Re: (Score:2)
Or you borrow a leaf from the commercial page and build in automated tool(s) that provide most of the needed information, and the user fills out the rest.
That's assuming a crash (or something that can be identified by the computer as a problem) happened, and your system is relatively simple. If you're working with something that involves multiple services, and there is simply unexpected behaviour (eg, action A causes B to happen, when you were expecting C .. in other words, the outcome is 'successful' but it's not what should have happened), it's very hard to provide automated tools to gather the required information (without just dumping all logs for the l
Re: (Score:1)
Let's see. Two tries were on Win32 related problems, and one on Linux wasn't a contribution at all, as you didn't have time. So the answer is clear : contributing to FOSS projects on Windows is a pain.
On Linux, I never got these problems at all when contributing.
Extension to Mozilla (Score:1)
Re: (Score:2)
Have you ever been on the receiving end of patches?
Nearly all patches are unacceptable because they break something else that the original author does not care about. This patch
Re: (Score:1)
Nearly all patches are unacceptable because they break something else that the original author does not care about. This patch fixes 64-bit code... at the expense of all 32-bit code. This patch fixes a warning... at the expense of not compiling with anything but gcc. So on and so on.
In fairness, I have not really been in that situation. I have been on the receiving end for really small projects with only a handful of users.
For large projects, I can empathi
Re: (Score:1)
This attitude is one thing that erodes the strengths of both Free software and Open so
Re: (Score:2)
Good points. I'm not the only one, so we do have a group of people. Even though, we really don't have the time to test out every single patch. Maybe if I was working on it full-time, but as a hobby, no way
Contributions (Score:3, Insightful)
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.
Cease and desist letter because of name (Score:2, Informative)
But with naming his project he just used his initial and "mail". A simple google search would have shown him that this is no good name.
When releasing something to the public I try at least to find a name that doesn't collide with existing projects (and certainly not c
Re: (Score:2)
I followed what was written in the letter.
(not) slashdotted... (Score:1)