How to make Sigil live

[rkomar]

Hitch, I'm not trying to draw you back into this, I just want to say that it's clear from all your posts that sigil's good health has always been a priority for you. I don't accuse you of trying to intentionally undermine it in any way. I was just worried that, perhaps in despair, your talk of forking was doing that, anyway. For the reasons I outlined, forking a living project is problematic. If sigil becomes dead as a doornail, then forking makes sense, but not until then.

People showing up to implement what they themselves need is normal for open source programs. The fact that most disappeared again from sigil shows that it largely does what it needs to do. When EPUB3 becomes necessary for many, I expect that some fresh developers will come to help implement that, as well. I see the current situation more as a lull in sigil's development rather than the death rattle. As long as it remains a viable place to come and make changes, then it won't be dead. I say this to everyone here, let's not give sigil the coup de grace just to end our own sense of desperation.

[mrmikel]

No one has shown up yet, and anyone actively using Sigil uses Mobileread.

Hitch does not have the luxury of waiting around to see what happens, since this is part of her business. Any successful business has a sense of urgency, of getting done what must be done in a timely manner. As a hobbyist I can wait months to see of anyone pops up.

If it were my business, I would already be trying to see how I can switch over to something which will deal with the inevitable, if apparently glacial, switch to epub3 which is different from epub2 in its structure. I would be looking to see if there was anything else which could meet my particular business needs. That is just smart business. All it takes is something which is a show-stopper to pop up out of the blue to bring her livelihood to a stop.

[Hitch]

Originally Posted by mrmikel

No one has shown up yet, and anyone actively using Sigil uses Mobileread.

Hitch does not have the luxury of waiting around to see what happens, since this is part of her business. Any successful business has a sense of urgency, of getting done what must be done in a timely manner. As a hobbyist I can wait months to see of anyone pops up.

If it were my business, I would already be trying to see how I can switch over to something which will deal with the inevitable, if apparently glacial, switch to epub3 which is different from epub2 in its structure. I would be looking to see if there was anything else which could meet my particular business needs. That is just smart business. All it takes is something which is a show-stopper to pop up out of the blue to bring her livelihood to a stop.

And if it were just me, I'd be less stressed, as well. But I am acutely aware of the responsibility to my crew, the other people who rely upon me to pay their mortgages, rent, groceries...in this economy, it's extremely unnerving to have that wearing on you, as it's not like jobs are plentiful on the ground, if my company rolled over and played dead. Don't misunderstand me, I'm not implying that we're the only game in town, of course we're not, but no small business owner can be unaware of that weight, of those other peoples' livelihoods. I just can't risk sitting around praying that the Savior d'Sigil will show up and start coding. That's the nuts and the bolts of it.

Hitch

[mrmikel]

People who are not business owners have trouble understanding.

I have only me and my wife dependent on the business, but I have to make my customers happy and have the tools on hand, ready to do it.

If I can't do the job or have the tools to do it, then I don't get paid. In your case, you have to figure out how to pay your workers AND Uncle Sam who is exceeding uncharitable to those who don't pay their employment taxes.

[rkomar]

I was not saying that the current slowdown isn't a problem. My only point was that forking at this time didn't make sense to me. I'm sure that looking at other options is a wise decision.

[Hitch]

Originally Posted by rkomar

I was not saying that the current slowdown isn't a problem. My only point was that forking at this time didn't make sense to me. I'm sure that looking at other options is a wise decision.

rkomar:

You're absolutely right. As it is, Sigil is pretty damn wonderful. I'm just a worrier by nature. ;-) That, and getting my nose kicked in at least once a week by Amazon, Apple or B&N tends to give me a pessimistic view. (Amazon: "we don't need to set no stinking SRL's in front of the in-line TOC, we don't care what your Guide items say!" B&N: "We don't need to honor your stinkin' stylesheets! Ours are better!" Apple: "What ePUB standards?")

Not to be Dora Doom or anything.

Hitch

[varlog]

Ok, now perhaps some statistics:
Sixteen members of this forum have had something to say.
Here are, as I see it, the ideas we have produced and number of approving members:

1.Let's talk about something else: 5
2.Why bother, everything is OK: 4
3.Let us find some other program: 3
4.Port to another language: 2
5. Epub 3 is a must: 4
6. Epub 3 is not a must: 3
7. Big publisher sponsorship: 2
8. Not clearly to order: some

Then there is there private fork idea of Hitch which is of course of no interest to the rest of us - unless she would be willing to "privately" share - but then her needs are not everyman’s (reports? what is it? I had to open Sigil and look for it just to still my curiosity!).

Ad 1. Well, this thread is about something else.
Ad 2. Well, I think it is not. The next generation of (free) e-readers will know at least some of Epub 3.
Ad 3. At the moment it is the only open source with this scope and maturity.
Ad 4. Forget it.
Ad. 5&6. I would say we agree (4 to 3!) Epub 3 is a must.
I have to admit that up to now I thought Epub 3 would be just some subset of html 5. Some posts seem to suggest it is something different. Lazy as I am I'll have to do some technical reading now. Feel free to share what you know.
Ad 7. No idea how to involve them... And they will have probably NIH-problem too.
According to professional epub maker companies expert (hallo Hitch) they (companies) will not feel they should step in, too.
Ad 8. Whatever.

Pondering on this I 've drunk a glass of red wine and tried to think pragmatically (sic!).
But seriously now.
DiapDealer (and others, he was the first) made some "plugins" to Sigil - even though it has no real plugin interface now. I think now (a glass of red wine makes all this complicated problems quite simple) this is the first feature that Sigil needs to live: a full blown plugin interface, preferably language indifferent, python at least, as it seems to be quite popular. All other problems will be (could be) than taken care off in due course.

@user_none: is it feasible? would you be willing to look at it? what has to be done?

[canpolat]

Thank you for the wrap up varlog. I think it was time that the thread would start addressing the quesion "How to make Sigil live" instead of discussing some private fork ideas.

Yes, C++ is not the easiest language to develop in, but it's still the 3rd most popular programming language according to this. So, I don't think this is the biggest problem.

Having a huge code base, on the other hand, can be very difficult to handle if you don't have a couple of "dedicatged" programmers.

To extend your idea, my suggestion would be to investigate which functions of Sigil can actually be converted into plug-ins. A smaller core would mean a smaller scope to focus and less effort for the core team.

One other option would be to drop cross-platform support and develop it only for GNU/Linux. That, I guess, would also simplify things for the core team.

To keep the project alive, I also think it's also key to spread the word. I suggest posting an "ad" (prepared by user_none, perhaps) to some of the forums that we contribute to to see if anyone would be interested in contributing.

[PeterT]

Originally Posted by canpolat

One other option would be to drop cross-platform support and develop it only for GNU/Linux. That, I guess, would also simplify things for the core team.

Not meaning to be argumentative here, but .. currently the developers don't provide a dircectly installable build for GNU/Linux... I'd actually suggest that providing a build for either OS/X or Windows only would make more sense (and in fact, I hate to say but it would seem that an installable version for Windows covers more flavours of Windows, than an installable version for OS/X covers OS/X flavours).

[canpolat]

Originally Posted by PeterT

Not meaning to be argumentative here, but .. currently the developers don't provide a dircectly installable build for GNU/Linux... I'd actually suggest that providing a build for either OS/X or Windows only would make more sense (and in fact, I hate to say but it would seem that an installable version for Windows covers more flavours of Windows, than an installable version for OS/X covers OS/X flavours).

I think it's perfectly reasonable to pick any platform that the development team would feel comfortable with. I only meant to suggest a way to reduce the work needed for packaging (and then sneaked in my platform of choice)

[EowynCarter]

Originally Posted by PeterT

Not meaning to be argumentative here, but .. currently the developers don't provide a dircectly installable build for GNU/Linux... I'd actually suggest that providing a build for either OS/X or Windows only would make more sense (and in fact, I hate to say but it would seem that an installable version for Windows covers more flavours of Windows, than an installable version for OS/X covers OS/X flavours).

As a linux user I object !
And going linux only don't really seam an option to me either.

[Toxaris]

Originally Posted by canpolat

Yes, C++ is not the easiest language to develop in, but it's still the 3rd most popular programming language according to this. So, I don't think this is the biggest problem.

It is the biggest problem. Although I do not have enough data to dispute the graph, it does not show the complete picture. If you take away the bigger commercial programs, the percentages will look different. There are much more (casual) programmers for C#, python and alike than C++. For sure there are a lot of C++ programmers, but most of them have jobs that really ties them up.

I think that most regular users of Sigil hang out here and that contributers must come from that area.

[canpolat]

Originally Posted by Toxaris

It is the biggest problem. Although I do not have enough data to dispute the graph, it does not show the complete picture. If you take away the bigger commercial programs, the percentages will look different. There are much more (casual) programmers for C#, python and alike than C++. For sure there are a lot of C++ programmers, but most of them have jobs that really ties them up.

I think that most regular users of Sigil hang out here and that contributers must come from that area.

OK. Let's accept your argument and assume that C++ is not that popular after all (or it's not easy to attrack C++ developers). The thing is: at this point, we cannot really do anything about it. I don't see much point in focusing on something that cannot be really improved/changed. So, in essence, my suggestion is to strip Sigil off of its "non-core" features and keep the "core" and then add features as plugins.

[varlog]

Originally Posted by canpolat

So, in essence, my suggestion is to strip Sigil off of its "non-core" features and keep the "core" and then add features as plugins.

Nobody's doing any stripping before plugin interface is there. And then it would be probably not necessary.

[OFF TOPIC]

...There are much more (casual) programmers for C#, python and alike than C++. ...

I was forced once to use C# for one of my trivialities - without knowing it, as usual. I hated it. My impressions: it depended very heavily on MS NET and tasted like some overblown degenerated spawn of Basic. Of course it runs on Linux with mono and executable brings (usually) source with it - nevertheless I hated it.
C++ on the other hand... feels like advanced programming language.
[/OFF TOPIC]

[user_none]

Originally Posted by canpolat

One other option would be to drop cross-platform support and develop it only for GNU/Linux. That, I guess, would also simplify things for the core team.

I use OS X so dropping other OSs would mean dropping Linux. That said while Linux is not supported with binary installable packages it is still supported as a source build.

Cross platform support really isn't a big deal from a source level. Building packages is where the time is spent. The majority of the cross platform support comes from Qt. There is a surprising little amount of actual cross platform code in Sigil itself.

Originally Posted by canpolat

OK. Let's accept your argument and assume that C++ is not that popular after all (or it's not easy to attrack C++ developers). The thing is: at this point, we cannot really do anything about it. I don't see much point in focusing on something that cannot be really improved/changed. So, in essence, my suggestion is to strip Sigil off of its "non-core" features and keep the "core" and then add features as plugins.

A plugin interface is would be a valid solution to the C++ barrier. With a proper plugin interface plugins can be developed in languages other than C++. That said a plugin interface is the largest "pending" project. So that in itself isn't going to happen.

Originally Posted by varlog

I was forced once to use C# for one of my trivialities - without knowing it, as usual. I hated it. My impressions: it depended very heavily on MS NET and tasted like some overblown degenerated spawn of Basic.

I've found C# to be Java but done right. I've only spent enough time to learn the basics of C# (enough to get by when needed) and I've found it very easy to work with. To the point that working on existing C# projects is very easy.

The big benefit to a language like C#, and Python is memory management. Not only do they (mostly) take care of it for you they hide pointers from the programmer so they don't have to learn about them. I'm amazed at the number of really good developers who work with languages other than C/C++ and they have no idea how to use pointers.