Discussion about OCE future

[Thomas Paviot]

Dear all,

OCE-0.6.0 was just released, and then the question is (Denis): and now? In some recent posts, Max and Jelle seem a bit confused with the way to choose, especially regarding the relationship between OCE and OCC : it's not worth fixing compiler warnings if they're not integrated by upstream (Max), "a more cohesive OCC/OCE community?" (Jelle). Good questions! Here is my opinion about that.

The OCE project has started in april 2011, it's 6 months old. It's quite young for a baby, but in software development, months count as years! So far we fixed many bugs, compiler warnings, improved portability, patches were packaged and submitted to the OCC forum, bugs were reported etc. And what? Nothing. Absolutely nothing from the OCCT vendor. No contact with any OCC developer. No technical cooperation. OCC announced in June that they will get closer to the community  and move to open development (see http://www.opencascade.org/about/news/issue173/), did anyone see any significant change?

After 6 months, I'm convinced that patches will never be integrated into upstream. May because of IP issues, maybe because they're not interested in this work, who knows? I hope be wrong, let's wait for the next release to be sure. But in the meantime we must consider this asumption with a high probability of occurence.

Each commit to the OCE git repository makes integration back to upstream harder. We're thus in an incomfrtable position: do we go on our way, or do we wait for upstream approval before going on? In my opinion, OCE has already diverged from OCC. Not from a technical viewpoint though. We have according to me 2 possibilities (under the previous asumption) :
* going on the way we use to work, starting to work on other projects that may officially and irreversibly diverge from upstream; (1)
* wait for the current patches to be integrated into OCCT so that we can move on. (2)

Of course I suggest the first solution. What would be the drawbacks of such a decision? I let you give your opinion, here are my arguments :
* no one here, on this ml, ever request to remain 100% compliant with OCCT.
* the OCC company only releases a few version per year (1 or 2). We waited for 2 years the last OCCT release. Honestly, reading the changelog, are there so many important new features? Are these changes really important for the community? I guess they are for OCCT customers, but on my side I never noticed any feature that I was missing in 630. In my opinion, the most important change is the improved support for multithreading and TBB. It was contributed by Roman Lygin. I think that the developments at OCCT are pulled by their customers order, but I do think they are very specific to their needs. I would prefer to see the Denis' roadmap implemented rather than changes in the TNaming module. Getting tied to this library? It's not a requirement.
*  Would there be any benefit from diverging? I think so. Recent changes suggested by Denis and Max are much interesting!
* If we diverge, how could we ensure that the OCE project will live, will be maintained etc.? Would it still be safe to use OCE rather than OCCT? I would reply to these questions with a few other questions: are you sure that OCCT is currently properly maintained? Are you sure that the bugs reported will be fixed in the next release? Do you know when will be released the next version? Do you trust an open source product that does not even make its test suite freely available? What do you expect from the next release? Do you have any overview of the project and its roadmap? Guess you replied 'no' to most of these questions ;-) I agree that, so far, the OCE project is very dependant upon QbProg and Denis. What will happen if you decide to move away guys? Well, we'll see...

To conclude this long post, I wanted to claim my optimism. We don't have to be afraid of any divergence or incompatibility with upstream. If we stand, we fall. Let's move one, and decide what to do according to technical criterions, the availability of human ressources etc. In a few words, let's do what we think is the best for the library, nothing else.

All the best,

Thomas

[jelle feringa]

Each commit to the OCE git repository makes integration back to upstream harder.

Just to be sure; by upstream you mean OCC?

 

We're thus in an incomfrtable position: do we go on our way, or do we wait for upstream approval before going on? In my opinion, OCE has already diverged from OCC. Not from a technical viewpoint though. We have according to me 2 possibilities (under the previous asumption) :
* going on the way we use to work, starting to work on other projects that may officially and irreversibly diverge from upstream; (1)
* wait for the current patches to be integrated into OCCT so that we can move on. (2)

Of course I suggest the first solution.

+1

not being held down by OCC is a main raison d'etre for OCE...

 

What would be the drawbacks of such a decision? I let you give your opinion, here are my arguments :
* no one here, on this ml, ever request to remain 100% compliant with OCCT.
* the OCC company only releases a few version per year (1 or 2). We waited for 2 years the last OCCT release. Honestly, reading the changelog, are there so many important new features? Are these changes really important for the community? I guess they are for OCCT customers, but on my side I never noticed any feature that I was missing in 630. In my opinion, the most important change is the improved support for multithreading and TBB. It was contributed by Roman Lygin. I think that the developments at OCCT are pulled by their customers order, but I do think they are very specific to their needs. I would prefer to see the Denis' roadmap implemented rather than changes in the TNaming module. Getting tied to this library? It's not a requirement.
*  Would there be any benefit from diverging? I think so. Recent changes suggested by Denis and Max are much interesting!

for sure...

 

* If we diverge, how could we ensure that the OCE project will live, will be maintained etc.? Would it still be safe to use OCE rather than OCCT? I would reply to these questions with a few other questions: are you sure that OCCT is currently properly maintained? Are you sure that the bugs reported will be fixed in the next release? Do you know when will be released the next version? Do you trust an open source product that does not even make its test suite freely available? What do you expect from the next release? Do you have any overview of the project and its roadmap? Guess you replied 'no' to most of these questions ;-) I agree that, so far, the OCE project is very dependant upon QbProg and Denis. What will happen if you decide to move away guys? Well, we'll see...

To conclude this long post, I wanted to claim my optimism. We don't have to be afraid of any divergence or incompatibility with upstream. If we stand, we fall. Let's move one, and decide what to do according to technical criterions, the availability of human ressources etc. In a few words, let's do what we think is the best for the library, nothing else.

i agree its an interesting situation, though perhaps I can add to your optimism; i think the earlier discussion today [ moving away from OCC's typed containers horror show ] leads to a much more sane code base. its not unlikely that such pretty drastic code changes in fact contribute to the lifespan of OCE than work against it...

so given the projects solid base & esthablised workflow, perhaps its time to really move on some more bald revamping of the API?

-jelle

[Max]

Eh, hard choice !

On one side, I'd be *very* happy to see OCE/OCC code modernized. OTOH,
it would
be a gigantic task..... Are we able to take it to an happy end ?
If the codebase would be, let's say, 1/20 of what it's now, I'd say
yes, of course.
Being like it is, we'd need at least 20-30 developers working on it,
or 5-10 working
on it fulltime.
Second question.... I'm a fairly good C++ programmer with few time
besides work and family,
and with almost no idea of 3d modeling mechanics.
Let's say I could help templatizing containers, for example, but not
at all on cleaning or perfecting
modeling stuffs.
What about other people involved ?

OTOH, to be optimistic, removing those crap macro-containers alone
would mean to shorten OCC
code by a quite large amount of lines.....

Max

[Roman Lygin]

Hi Thomas,

Interesting post. Let me offer some thoughts on this.

But before that, let's return the credit for TBB integration to the
OCC team. That was entirely their job. Even if we met to discuss
technical and other challenges several times, the technical job and
testing was the core team's work.

As for the whole roadmap, I would start as usual, ... from the
end ;-). Defining the strategy, I usually ask:
1. Where do I want to be in 3-10 years ?
2. How would I define the success ? # of projects using OCE ?
Positively influenced OCC with community-friendly eco-system (adopted
tools, processes, etc) ? Etc, etc... Ideally objectives should be
SMART (http://en.wikipedia.org/wiki/SMART_criteria).

Here are possible examples I could think of:
1. Role model how you would like to see OCC and influence it. For
instance, drive adoption of the best OSS environment (git, bug
tracker, wiki, …). Once done, stop OCE as no longer needed. Continue
technical contributions though.
2. Define a flagship community-developed OCC/OCE-based project (e.g.
FreeCAD-like) and make modifications in OCC as needed to support that
project. That is, act as the OCC team doing their customer projects.
3. Build a new business on this. Fork another open source kernel,
catch up with proprietary kernels (e.g. ACIS, Parasolid), leave OCC in
the dust, migrate its customers on your kernel, eat OCC market segment
share and eventually let it die. This will require VC (venture
capital) and strong professional team.

Anyway each of the community member should be clear about his/her
personal agenda. Why does anyone here spend their time ? This could be
for instance:
- Curiosity and learning something new
- Professional challenge (whether I am able to solve these technical
problems)
- Recognition and influence
- Business agenda (supporting own project at employer, own business
ambitions, ...)
- Making this world better (sharing knowledge, adopting the best of
OSS culture into CAD/CAx world,…)

Hope this makes sense and helps somehow.
Roman

[D. Barbier]

Hello Roman,

Thanks for sharing your thoughts, this is very interesting.
Thomas tried several times to request inputs from users, without much
result, and I do not understand why. This is frustrating, we wanted
to drive development based on user expectations. I guess that we have
no other choice than follow your advice, and define a long-term
strategy to decide where we want to go. That is not easy, we need to
think more about it.

Denis

[Pierre JUILLARD]

Hi all,

Maybe my input is useless, or not adequate, but let's share it nonetheless :).

Thomas, I see your mail as a call toward potential user, and maybe toward OCC as well.
In addition, I see that OCE / pythonOCC developpers take it seriously.

On the other hand, I don't know OCC people, but it seems that they don't know what to do of OCE and are not very fond of web communication.

OCE developpers, now that you have achieved something, if you have time and will to spend on OCE development, and OCE presentation at conferences, why don't you take the time to contact directly an OCC representative to speak face-to-face about their feelings, OCC future and OCE future?

Only my 2 cents. Maybe useless, but I have noticed that a good discussion from time to time usually allows mutual understanding, and this seems to be a good time.

Congratulations for what you already achieved!
Bests,

Pierre

[D. Barbier]

Thanks Pierre for your mail.
To clarify, I was not referring to Thomas' mail in this thread, but to
other ones like
http://groups.google.com/group/oce-dev/msg/0733fc19280efff2
http://groups.google.com/group/oce-dev/msg/851afda67efe7fa7
http://groups.google.com/group/oce-dev/msg/010875cc3d49ed2e
Users tell that they like OCE, but do not tell what they want to see
implemented, that was my point. But of course this was confusing in
this thread.
I still have to reply to Thomas' mail, maybe +1 is enough ;)

Denis