Announcement

Collapse
No announcement yet.

Reasons Why You Don't Contribute To Open-Source Software

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    The barrier between "not contributing" and "contributing" is rather thick. It might not seem like it to those that are already contributing, but those that aren't know exactly what I'm talking about. Entering a community and communicating efficiently is never easy. But entering a FOSS Project community is a billion times more difficult.

    I'm 34 years old and have wanted to contribute to FOSS most of my adult life... but it seems every time I've tried I've ended up putting my elbows on the table, putting my salad fork on the wrong side of my plate, and shifting uncomfortably in my seat until I leave. And usually before the appetizer has even been served.

    It's a difficult table to take a seat at.

    Really.

    With that in mind, I very much hope middle school and high school teachers are getting kids involved in FOSS Project communities early on. And showing them the proper placement of salad forks.

    Comment


    • #32
      Well, GCC is pretty efficient and world-wide respected crosscompiler. Also. this thing builds whole linux stuff together, so its ok for it to have higher standards and clean license requirements. I dont notice FSF or GPL doing anti-social practices, I barely know any programmer who does not program for food, giving away rights on his code, so its pretty normal to have FSF control the compiler, requesting clean code and strictly opensource license.

      Personally, if I find bug - I submit it, I have reported long array of bugs for single packages and for linux distributions.

      I also ignore nvidia from now on and already ignoring canon and lexmark for hardware. I buy opensource hardware. I have personally migrated 5 PCs that dont belong to me to linux, purging windows from them, all run without a fuzz. Yes, gnu/linux is a much much better for IT than apple and especially microsoft.

      Comment


      • #33
        I *do* contribute, but...

        I am a scientific programmer, not a compiler writer. I do contribute to Open Source software: I'm the chief maintainer and the primary author (>99%) for a set of open source environmental modeling support packages that currently total 359903 lines of code.

        But when I interact with the gcc people, what I get is a mix of arrogance and idiocy. A prime example is the Gnu handling of command line flags. It is a Unix industry standard for linkers that "-o <name>", with whitespace, is used to control the name of the output file. The vast majority of the industrial compilers use "-openmp" to indicate that the program is using the industry-standard OpenMP parallelism. Most compilers simply warn -- but neither fail nor do something idiotic -- in the presence of unrecognized compiler directives.

        But Gnu Fortran takes "-openmp" as a directive to generate an output file penmp. Ignoring the lack of whitespace. I'm told "that's the way the GNU toolkit works, and that's the way it should be."

        That whitespace should be significant has been recognized in the general compiler community for at least forty years; the GNU tookit kind of idiotic arrogance has even avoidable in Fortran for twenty years.

        I'm an unhappy camper.

        And GNU compilers will be second-class citizens for the packages I maintain until this kind of idiocy is fixed.

        Comment


        • #34
          Why i don't contribute to GCC; I have no C/C++ coding skills at all. Well i might be able to bang out a working "print('hello world');" in about 30 minutes.

          As for other projects I do usually in the form of bug reports. I've opened and helped close a few bugs for gentoo now. Again the problem is lack of C/C++ skills, Makefiles, configure scripts, etc. I'd like to contribute doc, but that requires understanding how the code works. Another barrier is the large size of a lot of the projects i use, XCFE, pidgin, openoffice, ffmpeg, mplayer, chromium/firefox, gvim, gimp, linux kernel. granted I'm not sure what else i would like out of the kernel.

          Comment


          • #35
            Originally posted by coats View Post
            And GNU compilers will be second-class citizens for the packages I maintain until this kind of idiocy is fixed.
            couldn't your configure script handle that for you?

            Comment


            • #36
              Autoconf is another problem...

              Autoconf makes it difficult to maintain multiple simultaneous binary types. For a given source base, I want at least the following:
              1. Optimized
              2. Debug
              3. Optimized profiling
              and I want it to be the same source tree that drives all of them. Anything else is asking for referential integrity problems.

              Comment


              • #37
                I've written a few smaller patches for some software or the other over the course of the years.

                On some projects, I wrote a simple patch, got some helpful advice, refined the patch, it finally was accepted and someone said "thanks, good job". Yay!

                on other projects I submitted patches only to see them ignored, I submitted bug-reports only to see them closed without comment, I provided working patches that fix valgrind-warnings and memory-leaks only to be told "it doesn't matter", or I volunteered to work on new features only to be screamed at how I could dare to try polluting their clean code structure with complicated features (which a lot of their users need, but still...).


                The first bunch of projects, I'd contribute to again if I had an itch. The others were a waste of my time and I'll stay away.


                It's very important to have a positive and helpful attitude towards newcomers. That's not easy, because it's always the newcomers that produce the most hideous patches and expect them to be accepted. Educating the newcomer is often more work than fixing the problem yourself, and the payoff for education is low: some will just sulk and leave. Others will just fix their patch, but won't continue to contribute.

                Unfortunately, a project has to go through all the time-wasting one-timers to finally find the good long-term contributors and make them stay.



                Why don't I contribute more? Because I currently lack the time for anything but smaller stuff, I'll try to be helpful on several forums instead.
                I'd love to contribute code to ATIs OSS drivers, but having to spend a weekend understanding stuff before I can start being productive puts me off. Once there's basic 2d/3d-accel for evergreen I'll dump fglrx though, by that time I'll install the OSS driver's sources and hopefully some patches will come out of it. We'll see.

                Comment


                • #38
                  Autoconf is another problem...

                  And my default test-builds on my base system run for four different compilers. That's 12 different build-directories, that autoconf doesn't know how to manage.

                  Comment


                  • #39
                    i don't contribute because my coding skills in C or C++ are just above "hello world"

                    however i released two icon sets (gnome-look), made the icon for a project (dead now i think) and participated in one or two logo contests

                    i d like to be more involved in aesthetics related project but many of them require coding skills which i don't have and in Open Source "if you don't have codes you are useless"

                    Comment


                    • #40
                      Well, all I know is, the GNU style of code indentation really makes my eyes cross.

                      Other Free Software projects, I do contribute. But I need to be able to at least read the code without getting a headache.

                      Comment


                      • #41
                        I notice two things in this thread.

                        "Patches welcome" is our way of saying, "Look, none of the main developers are really interested in adding this feature. We've discussed it, and come to a general consensus that this feature would either be unused, inefficient, a legal liability, harmful to stability, or a combination of the above. So we're not going to implement it. I'm sure somebody, somewhere, has both the coding skills and the desire to make it happen, but we're not really going to help. Sorry." (And we usually re-iterate this several times, too.)

                        Code is code is code. If you don't like the code style, just relax and live with it. (I prefer 1TBS over GNU, but I know how to do both. Also, death to tabs.) If you don't understand the code, take it in chunks and re-document it. If nobody knows where the code came from, annotate it in source control, track down the original author, and ask him questions. A little bit of vigilance and diligence is required to work on coding projects of this size, open- or closed-source.

                        Comment


                        • #42
                          Originally posted by DavidNielsen View Post
                          Blind hate is rampant in the FLOSS world. It is quite a put off when people take the extreme position without really understanding why they should take it and how it SHOULD effect many other decisions. Often people pick up on the notion that they should hate something and don't recognize that the arguments for such an extreme should also apply to other things that they don't hate at all.

                          It comes down to being in a state of ignorance, holding double standards, or (and quite probably) both. I can respect people for making a stand only in the absence of these two things. Very often the Mono hate club is a prefect example of it.

                          The same Mono hating flamers often don't have a problem with Wine (other than it might not work right--a statement which also implies that they don't have a problem trying it out), Samba, NTFS support, Exchange integration, win32codec packages, etc.

                          People like to praise AMD for taking the open road and apply hate to Nvidia for not doing so. Yet the same haters will turn around and point to AMD's closed binary as a high performance solution. From the same mouths that spread the Nvidia hate (because it's closed) you'll hear a complaint that Adobe Flash is buggy so they use Opera to keep it in check. Why is one closed product hated for being closed, but others are apparently welcome enough to try or use on a regular basis?

                          Bandwagon hate is definitely a barrier in the Linux world. I'm sure lots of people hate me for calling them out on it too, but people should put down the torches and pitch forks unless they are genuinely on board with the cause. If you hate Mono, you should hate a lot of other widely accepted technologies that realistically are in the same boat. You shouldn't hate Nvidia for being closed source and play closed games on your closed ATI blob at the same time.

                          I'm sorry if this seems like an off topic rant, but paranoia, hate, and bandwagons are often a barrier for many many things in and around the FLOSS camp. Its absolutely relevant when you ask why no one wants to help out.

                          Comment


                          • #43
                            Originally posted by Jimmy View Post
                            Blind hate is rampant in the FLOSS world. It is quite a put off when people take the extreme position without really understanding why they should take it and how it SHOULD effect many other decisions. Often people pick up on the notion that they should hate something and don't recognize that the arguments for such an extreme should also apply to other things that they don't hate at all.

                            It comes down to being in a state of ignorance, holding double standards, or (and quite probably) both. I can respect people for making a stand only in the absence of these two things. Very often the Mono hate club is a prefect example of it.

                            The same Mono hating flamers often don't have a problem with Wine (other than it might not work right--a statement which also implies that they don't have a problem trying it out), Samba, NTFS support, Exchange integration, win32codec packages, etc.
                            I don't use Mono-based Linux applications, I don't use Samba for Linux-Linux file sharing, I don't use NTFS on my disks, I don't use Exchange, I don't use win32codecs (completely useless anyway).

                            I do use Mono, Wine, Samba, NTFS for Windows compatibility. So the server serves me SSH, and my dad Samba. My Wine installation is used for Windows games, and not for Linux applications. Mono is installed in Wine for the same purpose. One USB stick has NTFS to share data with friends. That's what I like about these projects. What I hate about these projects, is that some developers tend to use this MS technology in favor of "our" own stuff. As if the free software community can't design a nice language.

                            One may call me a hater, but I never harassed anyone. I just choose not to use software that I don't agree with. If ethics didn't matter to me, I could just as well use Windows. I didn't exactly switch because free software worked better.

                            People like to praise AMD for taking the open road and apply hate to Nvidia for not doing so. Yet the same haters will turn around and point to AMD's closed binary as a high performance solution. From the same mouths that spread the Nvidia hate (because it's closed) you'll hear a complaint that Adobe Flash is buggy so they use Opera to keep it in check. Why is one closed product hated for being closed, but others are apparently welcome enough to try or use on a regular basis?
                            Maybe they aren't the same people?

                            Comment


                            • #44
                              Originally posted by coats View Post
                              But Gnu Fortran takes "-openmp" as a directive to generate an output file penmp. Ignoring the lack of whitespace. I'm told "that's the way the GNU toolkit works, and that's the way it should be."

                              That whitespace should be significant has been recognized in the general compiler community for at least forty years; the GNU tookit kind of idiotic arrogance has even avoidable in Fortran for twenty years.

                              I'm an unhappy camper.

                              And GNU compilers will be second-class citizens for the packages I maintain until this kind of idiocy is fixed.
                              You're being idiotic yourself here. All you have to do is use another option for GCC instead of crying like a baby. I may sound harsh, but you should just listen to yourself. You're not even telling the whole story and their arguments and perfectly valid reasons of why it's not a good idea to change this. You're just pointing at them and saying "no you!"

                              Seriously, lighten up. The GNU standards are made for the GNU OS. And Gnu's NOT Unix.

                              Comment


                              • #45
                                I doesn't contribute (anymore for a while) to open source because my last try was as receptive as a shark waiting it food. FOSS developers tend to be harsh and the best, masters and almighty. They do not understand that newbies trying to help doesn't need to know everything and are still learning. Sorry, but the total lack of politeness for me is the major factor to be away from helping FOSS projects from others. Beside that, I have my own FOSS project (http://www.seedframework.org), and I try to do my best with my (few) collaborators as I'm still learning from it.

                                Comment

                                Working...
                                X