Hey Nick and others. ---------- Forwarded message ---------- > From: Nicholas Alexander <nalexan...@mozilla.com> > > As consumers, we have hard limitations that make it challenging for us to > even track upstream, let alone contribute back to upstream. Licensing; a > desire to build everything from source; hard restrictions on consuming > projects with Android resources; inability to use Gradle plugins. >
Are these requirements set in stone? The active development team is fairly small [1] and I think we can use any help we can get to move more quickly – perhaps this is a time to bend the rules. [1]: For comparison's sake, Lyft has 14 devs and I'd argue the scope of their work isn't any larger than ours. > As producers, we're a joke: I answer a few emails each week explaining > that we provide no support for GeckoView and will not fund it. And even > when we can jump the technical hurdles to enable code re-use, we don't have > support for that really anywhere in the management chain. Mozilla won't > even commit to providing an externally consumable Gecko-the-platform! > I apologize if I'm interpreting this incorrectly, but I don't think GeckoView/the platform needs to our only open source contribution. While it does emanate the manifesto more clearly than an arbitrary Android library, as I mentioned I think there are benefits to releasing unrelated open source libraries. > I think there are a few benefits to releasing libraries separately from >> the app: >> * More development help on these libraries, without the need for >> developers to learn the full Mozilla development process >> > > I don't think this will happen quickly, if at all; and if it does happen, > we will be forever balancing the need of a library's community with our own. > fwiw, I watched a talk at Droidcon about developing an open source library and the speaker suggested giving your library a narrow focus to make community maintenance (e.g. should I accept this pull request?) simpler – e.g. on Github, Picasso is, "A powerful image downloading and caching library for Android". If it was, "An library to get pngs from urls and put them into ImageViews", it's more difficult to scope creep and reduces the maintenance burdens. > Square, Facebook, and pretty much every other "open source ecosystem" > participant publishes work but maintains near-complete control of the > development direction. > Which appears similar to the strategies in use in your comment. I would like to see our favicons library separated for testing, which could > lead to contributions back from the Brave development team. > A neat idea! However, I fear that if it doesn't happen soon, the code will have diverged too much and it'll be too difficult to merge back in. > > I care about libraries as a way to : > > * simplify and improve our architecture, and > * improving our testing, so that we are more robust. > I'm also glad we agree on these topics! In any case, I'd love to reduce the barrier to entry for using and contributing open source libraries using industry standards (e.g. maven/ivy, right?) for if (when?) the opportunity presents itself and I don't have a clear understanding of what the currently existing barriers are (beyond the brief descriptions mentioned above) – what are the action items? Is the first step to ship with gradle on release builds? What's next? - Mike (:mcomella)
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
