Let’s talk about what it’s like to work on an open source project. Just about all the software I use is Open Source. I’m not a programmer, but I do like the idea of people volunteering their time to put free tools in the hands of users.
How are the projects run so there is not duplication of effort?
What motivates people to put their efforts into an open source project?
Finally, I notice that for all the powerful open source tools out there, a common weakness is that the documentation sucks. Not always, but often enough to bother me as a user. What motivated this post is the recent update to RT’s Wavelet documentation. For a long time I’ve wanted proper documentation on that tool, because I keep hearing how powerful it is, but I could never find any decent guides on how to use it. It’s written in Spanish and I’m thinking about doing an English translation but don’t want to spend the time if someone else is already doing it. I’ve also thought about writing documentation for G’Mic, but don’t know how to get involved with that either.
I’m hoping this will turn into a meandering thread that can demystify the “behind the scenes” of open source software projects.
I can’t say how the projects are ran, but I will say that from my end, when I get a working code, I do a merge request, follow up, and then if all goes all, it is pushed. That’s the only thing I know. I wish I had more times to do more. The only two projects I contribute to would be Krita, and G’MIC-QT.
So explain this to me. You look at the code for Krita or G’mic, and you think to yourself, “Hey, I can make this better.” So you modify the code on Github, notify whoever manages the project and then maybe they include it in the official release?
As I non-programmer, I only have a vague understanding of merges, pulls, pushes etc…
What is your personal motivation to do the work you do?
My motivation for G’MIC-QT is that it isn’t biased toward software, and therefore I can support multiple softwares at once, and it empowers people by breaking software barrier. You would not need Paint.NET for certain filters or GIMP for certain filters, and if you don’t like either of these softwares, G’MIC-QT enables you to work within another software that you like.
As for Krita, it does offer non-destructive editing already and it is very stable as a software, and my final krita goal is to have LCH blending modes alongside with guided filter smart selection. High depth, color correction, clone layer, file layer, transform mask (smart object is file layer+transform mask combined) and so on are part of Krita. It does have some degree of options for editing pictures like healing within clone brush engine, automated editing via clone layers. I have been able to automate pat david luminosity mask tutorial, and applied color adjustment filter masks.
I just like helping people, learning about projects (their triumphs and struggles) and seeing what I can do to help. I do it because I want to with no expectation that I will get anything in return. In general, I like this community, since for the most part they have been receptive to my ideas and contributions. It is like gift giving. It hurts the most when people don’t accept your gift. But when people are receptive and thus are helped, it brings me joy.
Each project will have its own communication style. The classic FOSS communication channels are mailing lists, issue tracker, and IRC.
Communicate with the project before you put in a major effort. For smaller patches/fixes, check the issue tracker before working and leave a comment says ng that you’ll work on it.
There are many different reasons, but the #1 is probably scratching your own itch. You have a problem to solve and contributing to something (especially complex like image processing) rather than starting from scratch may be easier.
If you come to understand FOSS as a bunch of people solving their own problem and collaborating where there is overlap, things make a lot more sense.
Sadly documentation comes second. If you can’t code and want to contribute, this is where you can make a difference. If the documentation is not written by the developer but by a user, the user figures it out and writes it down. To me, that is the best kind of documentation, since it’ll likely be understandable by other new users.
Usually, there sits one person or a very small group of people who vet the commits that finally make it to the master branch (in git terms). But before that, there can be competing efforts to do the same thing, and that’s not bad. A lot of time, the final commit is an amalgam of the best of those.
Me, I wanted to make a raw processor that let me order the operations. The closest thing I’d found was G’MIC, but that took a prior demosaic by something like dcraw, which definitely had its own notion of ordering. So, rawproc.
Now, rawproc gave me the opportunity to participate in a community-organized project, librtprocess. It was kind of an “alignment of the planets” sort of thing, libraw was abandoning their inclusion of demosaic routines other than dcraw processing, and I wanted that in my rawproc toolset. I was just about to start teasing apart the libraw routines when @CarVac announced librtprocess, where the RawTherapee routines were to be packaged to make available to other projects. Now, that’s open source at its best, where significant artifacts are made available not just as their source code, but organized into a library with a proper programming interface. I was able to rather easily incorporate the librtprocess routines into my meager little demosaic tool, and I got the chance to submit an additional port, AHD, as a pull request. Very Cool Beans!!
I’m rather new to the community part of open source, but I’ve been publishing stuff I’ve written for more than ten years now. It’s definitely not the most efficient way to develop software, but the multiple eyes on a code base are the single most effective contributor to maturating its quality. That also brings more expertise to the table; librtprocess is arguably the most comprehensive offering of demosaic routines, open source or proprietary.
It happened to me: I came to RT because of its wavelets tool, among other reasons, and the documentation was…, well, not good. So I decided to translate and update it for my own needs. Later on I thought that as I was doing it anyway, why don’t share it with the community. And here it is.
As said by @paperdigits, a user looks at a tool from a different perspective than the programmer, so documentation written by a user will usually be better understood by other users. That doesn’t mean you can write the best possible documentation without talking with programmers, of course, just that you are able to translate the programmers jargon into understandable sentences
It would be better that the programmer himself wrote some kind of documentation draft, so a willing user would have a good start, but I guess that is not really feasible (many programmers hate documenting their code…).
And don’t forget that it’s the least sexy part of a program: it takes time, and effort to write in a clearly way what you want to say, in a way that any user will understand, and in the end the programmers get all the glory… C’est la vie…
In such a case, the best action would be contacting one of the heads of the program or the documentation (in this case @Morgan_Hardwood ) and offer yourself to help with the English version. He will know how you can help. I’ve already offered myself.
We all have different skills, and different interests.
I’m not a brilliant programmer. I have worked with enough people who are brilliant to know my own limitations. But I’ve also worked on enough large commercial software projects to know that coding is a fairly small part of the overall effort. There is also, in no particular order: specification, design, management, leadership, developer documentation, user documentation, testing (alpha, beta and regression), marketing, fixing bugs, and so on.
Non-commercial voluntary projects are massively different. We all do whatever we want to do, which is often adding new whizz-bang features that no-one else understands. The developer doesn’t need documentation, so why bother spending time writing it when the next whizz-bang feature needs developing?
I stumbled around, and sometimes faced problems I knew I had solved before, but forgotten how. So I kept notes, and figured that some might be useful for other users, hence snibgo’s ImageMagick pages.
And, yes, I added new whizz-bang features. I documented them because my memory is useless.
I started Filmulator to do what I wanted: make an open-source raw editor that gives good results out of the box. As far as duplication of effort goes, I didn’t actually do much investigation. I was totally unaware of darktable until only a few years ago, actually. But it seems like Filmulator is still the only open-source raw editor with this goal, so no effort is being duplicated… if only by chance. Within the project, I have been doing the vast majority of the work recently, so there are no toes for me to step on.
I started librtprocess because it needed to be done after LibRaw removed the functions I wanted, and it required not too much effort beyond what I would have to do anyway. So I decided to share the result and also accept contributions from others.
If I need something, I just do it myself. That’s what open source is about for me. The ecosystem enables me to do things, and then I share my results back.
I will try to reply only to this question: “What motivates people to put their efforts into an open-source project?”
I interacted with a dozen of developers in the last twenty years so I can tell you this.
It is one of the main questions that I asked. I was always curious to know how they started building or participating in their project.
The most common reason that I found was passion. Most people that I talked with told me that they just wanted to create something or found a solution at a specific problem only to discover later that a bunch of other people appreciated their effort. For some, this became a hobby, or for very few, it became both a hobby and a way of living.
The passion goes away because of real life. Family, job, health, and other reasons that might put what is seen as a hobby in the second place. Thanks to Open Source others will continue your work.
Get in, see how it works, do something else, hopefully, better. That’s how the web grew.
Thanks, Sam. This is very similar to how I feel. I don’t do programming, but I think I can help with user documentation for some of the software packages, which seems like a common weakness among them.
I’d like to have excellent, free tools available for people to reduce the barrier to entry. I think about a creative and inspired artist or photographer who may not have a lot of money and can’t afford an Adobe subscription. The more user-friendly the FLOSS tools are the better it is for that person.
This is literally the exact reason I try to help wherever I can (and tried to start a community around Free Software photography tools). I used to be the poor kid who couldn’t even dream of owning an Adobe product (that was pirated). Somewhere out there are more people who might be talented but encounter a barrier-to-entry to realize that creativity. That makes me sad.
It hit home for me when I was talking to a good friend of mine who is a hardware wizard. He told me that he collects old computers, discarded computers, or even parts from them, and re-assemble them into a new system. He’ll then put some lightweight Linux variant on them, and give them away to community organizations or families that can use them.
Local to me is a photographic arts center that hosts shows, and produces affordable classes to teach photography techniques. They do a lot of programs targeted at poorer areas in the city. They have whizz-bang computers with all the Adobe stuff that people can rent out by the hour.
A couple years ago, I asked them if they knew anyone with expertise in GIMP, and they did not. At the time, I was just getting started in OSS image manipulation and didn’t know anything, but at this point, I think I could probably teach a beginner class in GIMP. The next time I am there, I will pitch the idea to them, as it would be nice to spread the knowledge that I’ve gained and put the tools into more people’s hands.
It is possible that Adobe have done them a deal, perhaps with free licenses. In the same way that drug pushers give out free samples, hoping to get users hooked. I don’t mean to imply that Adobe is doing anything illegal, of course.
I suppose you could get some useful answers from people if you ask them directly. But people often give poor explanations explaining why they do things, for all kinds of different reasons. So you’ll get a truer explanation by observing what people do.
I’d be especially interested in the feelings of others here who put food on the table via programming, and also contribute to open source projects. Do you have some dividing line in your mind between those subject areas where you will contribute to open source and those you won’t? What’s that line?
For me, the distinction is whether the software category is primarily used by for-profit entities. In my business life, I work on software that is only used by large corporations. In that environment, I think it’s entirely appropriate to charge for my work. On the other hand, software that is often (or mostly) used by individuals/hobbyists seems ideally suited to FOSS, and contributing freely to such projects not only is good, but feels good!
