corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Is Qt the right choice ??
Date Wed, 29 Jul 2015 16:51:13 GMT
> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <dennis.hamilton@acm.org> 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
pmkelly@apache.org

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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message