> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <[email protected]> > wrote: > > It would certainly be possible to do an editor outside of the project, > whether LibreCorinthia or some other. That would still allow use of > components from Apache Corinthia that are provided under ALv2. Anyone can do > that. (And PayMeCorinthia could be done using the Commercial Qt license.) > > If an editor is to be a release from Corinthia, the challenge is to not have > a requirement for Qt, however that is accomplished. I have not suggested > that having an editor be abandoned. I have suggested that having Qt be > essential as the UI framework is a deal breaker.
I see the editor app primarily as a reference implementation. Certainly my main motivation coming into this was for Corinthia to be a library/toolkit upon which people can build a wide variety of applications. I agree that having the editor seen as “the” product can be detrimental to the project in that our goals are more general than just producing a particular application. Having said that, I still see value in having an app tailored at end-users as being a worthwhile goal. In addition to providing benefit to many people, it will also help increase the profile of the project and the notion of moving away from a single/proprietary file formats, allowing people to use whatever they want. For example, I’m not aware of any good WYSIWYG (or more specifically, visual) editors for Markdown - it’s a great format but the text-based nature of it can be a turn-off for some people. So I’m strongly in favour of having a desktop app as one of our outputs, though not the only output. Regarding Qt, I personally feel it’s an extremely unfortunate situation with the licensing situation. The unfortunate reality is that there are no good UI toolkits (that I’m aware of) which meet the requirements of Apache, and I think that puts Apache at a significant disadvantage when it comes to desktop apps. However, with Jan’s proposal, I think we can come up with a suitable solution which allows us to abstract over specific UI toolkits, so that another could be substituted. This is actually an issue which is not specific to our project, but has implications for Apache more generally. The most important question that’s come to my mind from this discussion is: What should an Apache project that wishes to produce a desktop app do? There’s no easy solutions which fit the licensing criteria, and writing a new UI toolkit from scratch is *hard*. I understand OpenOffice uses its own, largely since it did so for more than a decade prior to entering apache. But how do other projects handle this challenge? > > - Dennis > > RELATED THOUGHTS > > (This probably should be on a separate thread, but I think it figures into > the thinking about editors and whatever frameworks are used.) > > Experience on another user-facing project suggests that producing a branded > editor is a bad idea, because of versions that will be produced using the > same code but (1) loaded with adware and other unpleasant artifacts and (2) > used to charge fees while being passed off as the authentic project-supported > version. This creates an intolerable support situation. We know this > happens in App stores for mobile devices and tablets and the culprits will > pay for favorable ad placement. This is indeed a challenge. I assume you’re referring to OO here - I too have seen the requests on the mailing lists from people who don’t understand what Apache is about, sending legal threats to have their message to a public mailing list removed from multiple archives, and other unpleasant situations. But I don’t think the problem is bad enough to warrant avoidance of open source applications for end users - to me, it’s a question of how support issues are managed. When I think of what is the most well-known open source desktop app, I’d say it’s probably Firefox. I’m not sure how they handle support issues, but as an outside observer it seems to be an extremely successful product. So it’s certainly doable - perhaps we can look to Firefox and other projects to see how to best handle (or rather deflect) support requests. Part of it I think is managing expectations; we certainly want to avoid putting a major support burden on our team. As I said above though, I don’t think it’s reason enough to avoid end-user apps, but we do have to keep support issues in mind once we get closer to a 1.0 release. — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
