In Avoid Ratchet for PhoneGap/Cordova development, the author describes how he decided not to use Ratchet examples in his book because of a technical flaw that was easily patched. I agree with the general premise there, that managing open source libraries was out of scope of the general theme of the book's focus on PhoneGap itself.
However, he went one step further and simply recommended against patching the open source library, in spite of the simplicity of the patch. The excuse was, "I worry that Iâ€™ll update the framework six months down the line and either forget about my mod or my mod will no longer work." (Update: the author's clarification: "I certainly do not believe that and actively do create PRs on projects. I just don't know if that is the right solution for someone in this case.")
I agree, that is a possibilty. However, to me this shows is a failure of process and discipline, and perhaps one would be better as a writer to present the case for a discplined process of open source library management, rather than deterring people from using a library.
We're all developers (at least as far as your audience is concerned). While yes, we can be forgetful in not double-checking that a one-line patch we did X months ago was applied to an update of a library, feature and regression testing should exist that would detect it, and the memory quickly jarred to go "oh yeah, we may need to do this again." Especially something like this where just about nothing would work without the patch applied.
One line patches like this are why open-source exists at all. If anything, the library itself should have its own fork in your source repo with documentation on why things were changed that someone should read before updating a library. What you're describing as potentially happening is not a failure of technology, but an unwillingness to assert a healthy development process.
Managing open source libraries is part of the process of professional contemporary software development, not something to be avoided as if the libraries were closed. This is just the same as the process of tracking the workarounds in your own code for bugs in the library you leave unpatched: the process of development should include reviewing each of those workarounds to see if they are still necessary.
I think you make some really good points Joe, and I also see your followup responding to my note about this being for a book, but I think it is fair for us to discuss this outside of the context of a book too, since I think it brings up interesting points. :) (I think I wrote that a bit weird, what I mean is, let's pretend this isn't for a book for a moment.)
Would I still make the same recommendation if I wasn't doing a book? I'd probably say yes. I don't disagree with you about the nature of open source. I think you are 100% right. But I think there is a gray area between the "philosophy" of open source versus the practicality of development.
If I were building a project for a client, I'd look at this bug, and the lack of updates, as a possible sign that the project is dead. I can definitely do a fork! But the question is, do I want to? Do I want to - essentially - shepherd my own version of this project? I may have no interest in improving it, maintaining it, etc. Therefore I'd be disinclined to fork/fix and simply look for a better solution.
As much as I love open source, I think there is a huge disconnect sometimes between people who work in that world versus people actually using it. Should we expect more from people using open source projects? Maybe. Will that ever happen? Probably never.
Do those concerns/comments make sense to you? (Even if you - probably - strongly disagree. ;)
Well, with that comes the concern that I also tend to disagree with generally: just because a project hasn't had many updates doesn't necessarily mean it is dead. We used to call that "stable", unless there are so many bugs it was just abandoned as even its own developers found something better. A rapid update cycle often means incompatible changes can happen at any time (I refuse to willingly use ruby for this very reason). And even the most active project may find itself abandoned as the core developers get pulled by professional commitments, or corporate politics gets involved.
Choosing to use a library (open source or not) that requires knowing its dependencies. How tied is it to another library (e.g., node or jquery)? What are the chances of THAT library being updated in a way that introduces breaking incompatibilities. NPM manages this by isolating a library's dependencies from the core application, at the expense of having to replicate code if the developer chooses to also use that dependent library - such a solution obviously can't scale for web or mobile.
The truth is that code that works, works. That isn't a tautology, that is a fact. It continues to work until something it is dependent on changes. If you don't see any potential change like that coming, then what is there to fear? The code will still work. Code doesn't just "break" after working for months or years. I have Java code (Java 2D Mapping/GIS libraries) that I wrote more than 15 years ago. They still work in Java 8. I haven't changed a single line of code in them.
If you do fear such an update of a dependency, then are you yourself also dependent on that potentially breaking change? By choosing another library, are you instead setting yourself up for a similar breaking change because as an active project, an incompatible change can happen at any time (true for the hundreds of 0.x libraries out there), or maybe the library you choose will also die as its developers move on to other things, or choose not to update because of the incompatible dependency change?
Here I look directly at your mention of Ionic, given the way angular is throwing any backwards compatibility out the window in their 2.x. How long will a library like that stay supported when its own dependencies are abandoned? This idea that a library without support is a library of little use I actually find somewhat annoying (even as there are times I'm guilty of that myself, so some of that annoyance is self-directed).
All of this has to be balanced against the time you yourself plan to give to supporting your app. Is this a months long commitment? A year's long? More than that and you're bumping into a lifespan expectency that's very different from what it was years ago.
Mobile apps in particular currently have relatively short lifespans before going through significant rewrites because of new mobile design fashions (Material, IOS8), new mobile technologies (how many mobile-driven APIs have been published?), and the need to stay fresh in light of the large competition market and ease of entry.
Managing this requires improving the separation of concerns, which is why many JS developers (including myself) are starting to look away from monolithic frameworks like angular and more towards integrating libraries at each layer (model/store, controller/statechart, views without controller dependencies, and cleaner observer/binding made possible by O.o() and observe-js).
This I believe is the heart of mobile-web development.
Mobile apps tend to be short-term entities, expected to be significantly different within 3 years, or they will be replaced in the market by something that is significantly different. Whether or not you are still there depends on your own commitment to the problem domain your app is targeted for. Fashion, in technology or appearance, is much more the driver of change in mobile than actual features. Some apps lose out to competition with fewer features, merely because the older version looks clumsy or "old" in light of the sleeker competition, and I don't see that changing anytime soon.
The core exceptions are products that target enterprise markets, but there, the rules (and the money) are different.
But in all of that my core thought remains: using open source libraries requires having a process in place for dealing with them, either for incompatible updates or for internal bug fixes. But at least it is possible. With closed-source commercial libraries, there's only tracking incompatible updates, but there's no way to fix things yourself when the vendor can't, or won't, or simply doesn't (or they cease to exist which happens just as much as it does in the OpenSource world).
We have more options, but taking advantage of those options requires commitment to process. I believe it is better to accept it as the reality of modern development than to just hope someone else comes along with something better and maybe they won't move on this time.
Nobody said this job was easy. :)