Hubris. Ego. Not a shred of a clue about image editing. The entire batch of current systemic problems are a byproduct of this developer's efforts and architecture.
EDIT: I'm willing to give the GIMP a boost. I don't know this developer. Is someone knowledgable about this particular developer. Is it likely they are the right person to do it?
EDIT2: He's contributed a lot already for a long time and still keeps on going strong. It looks good to me.
The campaign is also listed here http://pippin.gimp.org/ - in the header.
So as long as the "pippin" user of https://www.patreon.com/pippin is the same as GIMP's pippin, it seems legit.
The Gimp project has been quite abrasive to the graphics research and software development communities for many years. The Gimp team 'knows better' then the highly qualified and experienced graphics programmers who offered to help the project bring there code base into the current standards for graphics.
There has been a lot of goodwill that has been squandered by the Gimp developers to the point that I seriously doubt that anyone with the skills or the time to work on OSS graphics is willing to invest any time in the project.
Any further development of Gimp will more then likely be an upgrade to the latest version of the GTK+ toolkit slapped on top of the same outdated 8bit early 1990's architecture fallowed by praise by people who have little experience or interest in graphics at any serious level.
I don't know much about those highly qualified graphics programmers - but every good project has a pace and a development plan - GIMP definitely has a roadmap in place, that can't and shouldn't be turned 180 degrees everytime someone comes with an idea; and I've seen quite a few people who see the rigors and the standards set in place as "abrasiveness"
Could you point us to some mailing list messages that would support the claim though? I don't follow the mailing list closely, mainly the news announcements.
The Gimp has been 'transitioning to GEGL' for how many years now? Something like six or seven years. And getting the data structures in place is only part of the challenge. How fast is this going to be for users? If the speed is to slow for users to efficiently get there work done at an intuitive pace then you have still failed.
From the initial GEGL integration attempts I saw the whole thing was hacked together with no clear thought to performance. And the performance was indeed quite abysmal.
There are very few sustainable free/open source projects, which have corporate or some other kind of backing - GNOME (redhat), Linux (linux foundation) and Blender (blender institute) are the only one that come to my mind.
It would be unreasonable to expect from unpaid volunteers if they has no ambition to do such work. Which is why I suggest that if you want to see advanced features and professional quality graphics software with a predictable cycle of development then you support the projects that actually try to create such programs.
Krita has a regular development cycle, a clear set of priorities and goals and funded development efforts that clearly lays out what features and improvement are going to be achieved with your hard earned money.
That has been an ENORMOUSLY successful improvement for both the programmers who can now get paid to work on there projects and the artists that now get quality continuously updated graphics software.
If Gimp or any other project deserve funding they have to step up and show the discipline and commitment to there project that successful projects like Krita have. I do not see that at this time so my recommendation is to support the projects that I listed in the OP.
As far as performance is concerned OpenCL or Cuda is not going to save you if your cpu bound memory architecture is not carefully thought for performance. This has always been a major problem for gimp for a long time. The higher bit depth and resolutions that are used now only exacerbate the situation. A general use case now could easily have tens of gigabytes worth of data that the user wants to manipulate delete and expand in real time. I have never seen this addressed in a serious proposal.
btw: I do love Krita, and I'm not saying they deserve any less support in favor of GIMP, but Krita is a lousy choice for certain image-editing routines where GIMP excels. Krita much more tailored towards artists, and I'd rather it stay that way.
The project has /always/ been unfriendly and abrasive. There's a reason why there aren't many contributors--the core team drove most of them away. I was a contributor in the early 2000s as a maintainer of the Print plugin (now gutenprint). I distanced myself from contributing because it was so painful and unpleasant. Same for GTK+. I went and worked on other stuff.
The other reason is technical. Why is the transition taking so long? Because the codebase is written in GObject-based C, and writing and refactoring this stuff is a nightmare. This also puts of a lot of potential contributors, and for good reason. Were it written in C++ or something else more amenable to ongoing maintenance and refactoring, it would have been possible to get this done much more quickly, and it would also have a vastly lower barrier to entry for potential contributors.
Moving to Qt is definitely possible; I've done it for other GTK+ projects. It can even be done incrementally; you could move the whole lot to use GTKmm widget by widget, and then once it's all C++ you can start the move to another toolkit. I'm not saying this because of any sort of Qt vs GTK+ zealotry, but rather because GObject-based C is inappropriate for sizeable codebases; the ability to maintain and refactor and contribute to a codebase matters, and this impedes all of them. Looking at the glacial progress of GIMP and other big GTK+ applications, as well as the bugs it causes, demonstrates this repeatedly. Plenty of other projects made the move and didn't look back, because once done it's vastly more productive to work with a C++ codebase, and with a significant increase in code quality. It's not 1997 any more.
Note: I've donated to Krita, GIMP, digiKam and other software, animation projects and libregraphics meetings in the past.
Unfortunately groups of humans act that way sometimes. Wouldn't it make sense for the more qualified and experienced graphics programmers to simply fork it and make their own better product?
A lot of people would like to work on a established project rather then bootstrap a new one. And many could not do that anyways because of NDA terms.
The climate is getting better but only because there is a new crop of applications that sprung up in the last few years that has more interest and understanding of who the graphics community is and how it works. And seems more interested in contributions by people who have highly specialized and deep expertise in graphics.
My general sense is that it has been more fruitful for people to work on specific projects privately or in there professional environment that solve there problems and then release those projects as OSS. Rather then try to wrangle the politics and project structure of some of the older established open source software.
I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's. I have never seen a clear design document explaining what this new core is suppose to achieve and for what uses Gimp expects to be used by professional level Artists workflows.
The last development that I was paying attention to was the decision to switch to GEGL for there core compositing and pixel engine. But it looked like it would simply be easier and probably better to start from scratch and build an entirely new software build around a 32bit image architecture rather then try and retrofit there 8bit custom build compositing system.
I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core. That shows rather skewed priority focus for a software that has some serious issues.
I don't see the port to GTK3 as being such high priority. It's not even on the roadmap to 2.10; The roadmap seem sane to me.
I don't think the program was intented specifically for painters, but it did include the MyPaint brush engine. And I find the program easier to use with every new version.
But this time I can address this issue: I commited $8/month, and I'm promoting the campaign heavily.
Also, thank you for your support. We do appreciate it!
Anyway, GIMP is getting faster - with 2.9 you can already use GPU accelerated operations and plugins, if that is your concern.
What you don't want is a program that crashes all the time, or one that is so convoluted (because "performance"), that nobody is able to develop it further, since nobody can wrap his head around of all the implication of a modification.
Oh, and btw. Stop using the "GPU accelerated" argument as it was a silver bullet. GPU is not a crutch to make slow operations barely usable, it should be used as an extra performance boost for operations that already work.
There are cases where coding for performance from the get-go is the way to go - think the_silver_searcher vs ack; there are cases where "computer power will eventually catch up" - the GNU coreutils did just that, they where coded for a system where a large amount of RAM was available(even if at the moment, in the '70's it wasn't), and removed many limitation that the proprietary tools had at those times.
But in a large program, that aims to grow even larger as features add up, performance is not your primary concern. If you have good abstractions, and you optimize at pixel conversion layer by 50% (say babl), all those optimization will add up. If you write your code in assembler, for speed's sake, you'll never surpass the complexity of MS Paint.
I worked on a web application that was a bit over 100k lines of code (at least the subsystems I had access to) - some bad architetural decisions made progress stall, and features were delayed by as much as half a year. Every change at deeper levels broke all kind of things at the UI level. Those were some shitty days, trust me.
So we, in fact, completely agree.
* Project management.
* Goal/benchmark definition.
* Human resource allocation.
I can't decide if what you say is truly so. One thing that I know, though, is that the old GIMP has been very useful to me for editing images (nothing fancy). I'm not an artist/painter but if I were, I'd start that with Krita instead of GIMP. In my mind, GIMP is more of a toolbox for doing the boring stuff like cropping/converting/annotating/correcting some random images and saving them in various formats. Gaining proper color management would be a good thing in my opinion, even if everything else stayed the same.
My concern is with Professional quality tools for artists. These tools already exist on Linux but they are predominately closed source. If Linux and OSS is going to be an option for Artists then the tools have to meet the same high quality standards that other professions that use Linux expect. But in graphics this is not the case and has not been the case for many years.
The best way to encourage the momentum for better tools is to support those projects that take the quality of there software seriously and have some urgency. The projects I have mentioned previously have demonstrated that they have that focus.
He's using Krita as his main painting tool, but:
"Gcolor2 is a colorpicker, Inkscape my favorite vector editor, Gimp for manipulating images and Shutter for taking advanced screenshots."
I don't see why we shouldn't support the development of both programs. I personally like GIMP better, maybe just because I'm used with the interface, and I don't do paintings, only image manipulations.
Krita has a very refined process for development donations. They collect donations through a Professional funding site not a personal Patreon account and there is a clear time frame for development and a clear set of features that will be 'Finished' at the end of the development cycle.
They have successfully delivered with this model and the people who gave them money got what they paid for and will more then likely fund them again and other projects.
Can you say the same for gimp? No, someone might give some money to a Gimp developers Patreon making all sorts of promises that never get finished. The person who gave that money will probably never contribute again.
Thats a big problem for every OSS graphics project now. We have to give people who are willing to put down the money what they expected to get or they will stop funding.
Its important that the most professional, serious projects get promoted and funded to serve as a model for other projects to follow. And to grow the amount of users that feel comfortable giving there money.
You can see the same sort of professionalism with Blender and Natron development. And they also are producing quality software. If the project is fallowing this professional model then they deserve to be promoted IMO. But simply putting a bunch of promises on a personal Patreon and asking for money will do more harm then good to the larger OSS graphics community.
Commits speak louder than baseless accusations.
But you made up an argument about driving off experienced developers. So what's actually stopping you from making more stuff up?
> I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's.
Nope. It started around 2006 at small steps.
> I have never seen a clear design document explaining what this new core is suppose to achieve
So you've never visited gegl.org?
> and for what uses Gimp expects to be used by professional level Artists workflows.
So you've never visited gui.gimp.org?
> I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core.
Wrong. 2.10 is all about rewriting the core. We need GTK+3, because GTK+2 has tablet support is broken on Windows.
Name one such programmer.
> Any further development of Gimp will more then likely be an upgrade to the latest version of the GTK+ toolkit slapped on top of the same outdated 8bit early 1990's architecture
8bit has been gone since 2012. Wake up and smells the floats :)
After more then a decade of failed and failing software development and funding modes that tried to shoehorn artist driven intuitive graphics applications into a development model that tangentially works for lone wolf kernel device driver hackers we have started to overcome the damage and move in a positive direction with Krita, Natron, Blender Foundation etc.
The Gimp project and development model has not produced a productive environment or a compelling product for any of the groups I mentioned. That has been the case for many years. After a lot of hard work other projects have managed to formulate better more productive models to develop OSS graphics programs and find funding to do so. The artists are happier because they get better more competitive software and they are willing to fund its development. The programmers are happier because they have a clear direction and understanding of who there users are and where the software needs to go. And the researchers are happier because they see a community who is interested in and welcoming of new and useful graphics algorithms and research.
None of this has happened because of the Gimp. It has happened in spite of the Gimp project sucking most of the air out of the room for many years and contributing nothing to the OSS graphics community as a whole.
If you care about fostering the growth of OSS Graphics software and a community of talented Artists that feel comfortable and productive using OSS software then you need to promote the people and the projects that are making that happen.
The gimp project needs to take a break and perhaps hand the reigns over to a new group with a different vision. The current project and its structure, soliciting money form the Artist community into developers private patreon accounts with vague promises to make Gimp great again is not helping Gimp or the OSS graphics community.
Last time I checked, the GIMP was open source. If this group of fresh-bloods has a better vision, let them fork or start from scratch - there is simply no good reason to kill the current project. "Sucking up all the air" is just another way to say "it's difficult to compete with" - and blaming the GIMP project for that says more about the potential up-and-coming than GIMP. XFree86 didn't "suck most of the air out" of XServer market- x.org was just better, ditto OpenOffice vs. LibreOffice.
Oh I dunno. I see people doing excellent work with GIMP all the time. How about you?
> The gimp project needs to take a break and perhaps hand the reigns over to a new group with a different vision.
There is no "new group". There's just us.
Yes, and now would be a good time to admit that the reason why that is the case is because the Gimp project and development model are unproductive and failing when compared to other projects who do not have any problem attracting new people or resources.
The Gimp project needs to dismantle itself and take some time to think about how it can build a more productive and sustainable model that attracts developers based on the successful examples that other projects have.
Begging for coins into your Patreon is not part of building a large, productive and sustainable project. Its more of the same misguided and shortsighted mismanagement that has brought Gimp to its current sorry state.
Yes, I expect you would want that.
> the same misguided and shortsighted mismanagement
It's amazing we managed so far at all without your expert input.
There are many reasons things are the way they are. That you don't know much about those is a whole different story.
I feel the post really should be conveying what they will be providing if they reach their patreon marker. A better competitor to Photoshop, Paint.net. What features will be worked on, etc. Its gotta market itself in some way.
GIMP is free software and ethical. Paint.net is the same rental model that Photoshop is now using and is completely against the public interest for us to put our resources into that sort of business.
For anyone interested, the MIT-licensed source is still out there: https://github.com/rivy/OpenPDN
I release most of my own code under a license similar to MIT (the ISC license) and as long as the people who are using my code honor the conditions of the license they are free to rebrand it and sell it if they want to or to do whatever else that doesn't violate the license.
Often I feel that if someone is going to redistribute an MIT licensed project with modifications, they should rebrand it. For example say that I wanted to sell copies of FreeBSD as a whole with some of my own patches and modifications. I would not be able to call that FreeBSD without first working out an agreement with the FreeBSD Foundation . The reason for this being that FreeBSD is a trademark of the FreeBSD Foundation and so they get to retain control of it. This is how it should be. This is what I like about the MIT family of licenses, the code is free but the license does not grant rights to use a trademark. When I say rebrand, note that proper attribution is still required.
However, if binaries are redistributed unmodified then I think it should be ok to refer to it by the original name because then that name is an accurate representation of exactly what is being distributed.
Furthermore I think that when just maintaining source changes in a public repo it should not be necessary to rebrand.
Meanwhile, if someone completely stripped my name from something I wrote and they didn't give me the proper attribution, they'd be in violation of the license and therefore the license would be void. If someone is going to use my code, they are going to attribute me in the manner that is set out in the license.
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
They can also continue doing that too, since changing string of a disassembled binary isn't that hard.
I wouldn't call this a "shame". A project as complex and significant as GIMP/paint.net may take a lot of time to maintain and to improve. If you can't find a persistent way to fund yourself, turning it proprietary becomes a tentative option. I understand and respect the decision of the developer of paint.net. As open source developers (I am one of them), we are responsible not only for our users but also for ourselves and our families. Everyone has a life after all.
> used for expressing sympathy or disappointment
We're talking about http://www.getpaint.net, right? This is proprietary desktop software, but as far as I can tell, it is gratis. (They do solicit donations, but paying has no bearing on the license.)
Implying that non-free software is unethical? That's a rather rude thing to say.
> A program is free software if it gives users adequately all of these freedoms. Otherwise, it is nonfree. While we can distinguish various nonfree distribution schemes in terms of how far they fall short of being free, we consider them all equally unethical.
For people who think that users deserve the freedom to run, copy, distribute, study, change and improve the software they use, nonfree software is indeed unethical. Even more so when the software is used by the developers as an instrument of injust power.
Implying that non-free software is unethical isn't rude. Especially since I
didn't insist that this particular software is deeply unethical. I just
suggested that support for ethical software like GIMP is the right thing to
do and so supporting less ethical software is something I'm suggesting
Now, having learned from other comments about this particular case, I'll agree that as proprietary software goes, Paint.net sounds unusually good in the ethics realm, just not quite on par with GIMP, but I'd say net ethical after all.
Absolutely. It is.
There may be few other options in the current global economic system, but it does not make it any more ethical.
* They rewrite the core of the software to allow a lot of new features.
* The developers could not agree on all critical details on how to proceed.
* Some developers got frustrated because things were not going their way or proceeding too slowly.
* The new model of how things work makes much of the old code obsolete.
* There are a lot of modules which need to be rewritten to use the new core.
* Before thinking about releasing the new GIMP >50% of the total work has to be done making transition hard.
* Due to its 'unique' interface a lot of people don't like the GIMP even if it would do everything they need.
* Designing and implementing a new interface is another pain point.
Considering that currently the GIMP is at a critical point in its development, a full-time developer could really be the pivotal element in making it succeed. I don't know much about this particular developer, though.
If you ever tried slipping a few line of code for a side-project or a free/open source one, you know how hard it is to focus when you have such limited time and energy.
1. Hideously over-engineered pixel path makes performance, if at all possible, worse.
2. Broken concept of colour management and pixels. See sRGB debacle and the concept of hard coded spaces.
3. Anachronism of imaging model.
4. Ignored fundamental problems that many people pointed out years ago. See the ridiculous "unbounded mode" that even a 100 level image computer student could have demonstrated would never work.
5. As per 4., ignored all evidence and designed a worthless software model around.
The project needs to die.
Look - irrespective of the truth of the message, remember that there are humans reading it and framing matters
"LNB and CCE both allow the user to easily produce radiometrically correct editing results. LNB provides fewer user choices for blend modes and for various operations, but the defaults for the operations and blend modes that I've looked at are logical and useable."
LNB is the linear-is-the-new-black branch of upstream GIMP. CCE is her patched version.
No, the problem was with Qt itself. The whole reason GTK was created, is because Qt wasn't really FOSS. Only much later Qt was really opened up. So yeah, today Qt is open and it's clearly much better. But the damage was already done, and the split happened.
I think the grandparent is definitely right. A lot of projects were started post-1999, when Qt was already open. But GNOME was the default desktop of many distributions (including Red Hat and later Ubuntu). Moreover, it is harder to bind Qt in order languages, since it is C++. There was a strong dislike for C++ in parts of the FLOSS community.
"You should completely rewrite this project, consisting of hundreds of thousands of lines of code that people have worked on for years, using the tools I like better!"
Because that's pure gold.
For extra enjoyment, look at the way they convert a function definition to Rust. You'd hope that the new version would be at least somewhat nicer than the original, but of course not. As lng as it's Rust it must be better, right?
Also, can't you just position floating windows in the right place so that they look pretty much docked in-place?
Note that I don't have any OS X machines to confirm this myself, this was at a designer's mac a few weeks ago.
What do you find about Gimp that is hard to use?
It's mostly quite good and has very high feature parity. Although it can't resize a selected image portion and so i still use paint.net.
As an aside, I've tried Krita, but am too used to how things work in Gimp, particularly the shortcuts. How different is Paint.net?
Apples to oranges.