Fwd: Thinkings about the 6.5.0 release, OCCT status, and the relationship with the Community

[Bryan Bishop]

This message was sent from www.opencascade.org forum user Thomas Paviot
http://www.opencascade.org/org/forum/thread_20111/
------------------------------------------------------


Dear all,

The latest 6.5.0 version was release a few days ago. This new release was expected for a long time by the community. By 'community', I mean people who are not customers of OCC, who didn't pay any fee to the OCC company but just use the product for free or commercial products/projects.

There have been, and there still is, a kind of misunderstanding between the OCC company and the 'community' as previously defined. The community just expects OCC to deliver a good and reliable library, with updates, bugfixes, issue tracking and so on, that is to say provide a XXIth century open source product/project management. On the other side, the OCC first consider their customers request, because the licensing fees from the customers create income. This business model can easily be understood (it's not that original in FOS world), however the community deserves a better consideration from OCC. In my opinion, the OCC company didn't understand yet that the community can create value to the product/project, and that this added value can be converted back to money. This lack of consideration explicitely appears in the 6.5.0 announcement (read http://www.opencascade.org/org/forum/thread_20025/): not even any thank to the community, it's just incredible!

Anyway, the result of this strategy from the OCC company is that the community only benefits today from this poor forum interface to report issues, ask questions, send patches etc. Project plans, roadmaps, issue tracking, source code repository, unit test suite etc. are not publicly available. We (the community) only see the tip of this huge iceberg. Where does this iceberg sail?

After 30 months of work since the 6.3.0 release, the 6.5.0 is out. Expectations were great. Results are, in my opninion, a bit disappointing. Reading the annoucement, I see that "this release introduces about 230 modifications and bug fixes, over previous public minor release 6.3.". 'Minor' release means minor improvements. Well, this is an average of 7.66 bug fixes/minor improvements per month. For your information, from Firefox 4.0 beta 12 to Firefox RC1, 227 bugs were fixed (http://www.mozilla.com/en-US/firefox/4.0/releasenotes/buglist.html) in about two weeks, that is to say an average of 450 bug fixes/month. My conclusion? Although a version was recently released, OCC is not such an active project anymore: fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). Additionnaly, 6.5.0 release seems to introduce regressions, many obvious issues have not been fixed etc. It looks like OCCT is slowly dying, no?

Regarding the latest release, a few fixes are currently being contributed back by the community through this forum (search for OCC650PATCH in this forum). We cannot wait 3 more years (or more?) for the 6.6.0 to be released, and I'm not even sure that any other version will ever be released. Community fixes should be made available to community as soon as possible. Patches are not an easy way to trace modifications to the source code. Some projects were registered on sf.net (http://sourceforge.net/projects/opencascade/, http://sourceforge.net/projects/qtocc/), mostly to share patches, but we should have the complete code somewhere to be able to easily say up to date.

As a consequence, I registered the oce project on github : https://github.com/tpaviot/oce/. oce stands for *o*pencascade *c*ommunity *e*dition. The complete 6.5.0 source code was uploaded (the /ros folder actually). This repository is intended to gather modifs from the community (I'm bored with searching for OCCPATH or OCC650PATCH on this forum), merge OCC services packs from the Salome project etc. Git is a perfect tool to manage such a huge library as OCC.

This project is not a fork. The goal is rather to make the library living between two official releases, ensure a continuity, and setup a tool the OCC team does not want to provide us. There is a risk that this concurrent version diverge from the original one, or that the code is not enough tested and introduce regressions/bugs? Well, no risk, no fun, right?

I strongly encourage Denis Barbier, Pete Dolbey, Roman Lygin and others, who often report issues/bugfixes, to register a github account; then email me to get a write access to the repository.

All the best,

Thomas


------------------------------------------------------

--
- Bryan
http://heybryan.org/
1 512 203 0507

[Leo Dearden]

On 11 March 2011 07:13, Bryan Bishop <kan...@gmail.com> wrote:

Although a version was recently released, OCC is not such an active project anymore... 6.5.0 release seems to introduce regressions, many obvious issues have not been fixed etc. It looks like OCCT is slowly dying, no?

 

As a consequence, I registered the oce project on github : https://github.com/tpaviot/oce/. oce stands for *o*pencascade *c*ommunity *e*dition.

Bravo. Excellent response to a lack of engagement: "We'll do it ourselves."

This project is not a fork. The goal is rather to make the library living between two official releases, ensure a continuity, and setup a tool the OCC team does not want to provide us. There is a risk that this concurrent version diverge from the original one, or that the code is not enough tested and introduce regressions/bugs? Well, no risk, no fun, right?

Not a fork (Yet. Hopefully never).

I'd say we can't loose, really. Regarding the code quality, if we use good unit tests, and good integration tests, and peer review, we'll have good code. Regarding divergence, I would be surprised if the oce doesn't become the dominant implementation. Obviously, we'd prefer to keep getting the benefit of the work that the OCC is putting in, but if oce takes off in a big way either OCC will continue to accept the patches, in which case the two will stay in sync, or their contribution will be dwarfed by the community sourced improvements. After all:

 

> fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). 

I'm sure we'll do better than that. :-)

--
Leo

--

RepRapKit.com

[Bryan Bishop]

On Fri, Mar 11, 2011 at 11:21 AM, Leo Dearden wrote:

I'd say we can't loose, really. Regarding the code quality, if we use good unit tests, and good integration tests, and peer review, we'll have good code. Regarding divergence, I would be surprised if the oce doesn't become the dominant implementation. Obviously, we'd prefer to keep getting the benefit of the work that the OCC is putting in, but if oce takes off in a big way either OCC will continue to accept the patches, in which case the two will stay in sync, or their contribution will be dwarfed by the community sourced improvements. After all:

 

> fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). 

I'm sure we'll do better than that. :-)

Unfortunately, I am not as optimistic about OCC. As a developer, what incentive do I have for working on OpenCASCADE? The code base is awful. Awful a million times over. People say writing a CAD kernel is hard. You know what's harder than CAD? Fixing broken CAD. Good developers know to work on BRL-CAD instead. True, the features between OCC and BRLCAD are not exactly the same, but BRLCAD has been working on NURBS support and non-raytracing-specific code for a while now.

OCC is hardly a good representation of software code quality that can come out of open source projects. As Thomas said, they don't use any modern tools for open source development- no public repositories (though they had one in 2001-2003 or something), they don't seem to release unit tests (or even write them?), no communication with the developers, old concepts left over from the 90s, etc.

In my opinion, I've narrowed down what relevant projects I should contribute to, and one of them has always been BRLCAD. The other is a fictional, completely open source CAD kernel that I or someone else writes from scratch. Some of you may remember some of my 2010 work on lolcad, a tiny python-based CAD kernel based on NURBS, boundary representation and STEP file format export capability:

lolcad
http://diyhpl.us/cgit/lolcad

As it turns out, Bryan Cole- who was previously spending time on PythonOCC- wanted something similar (and didn't know about lolcad) so he started ToyBRep:

ToyBRep
https://bitbucket.org/bryancole/toybrep

Both of us agree we should be merging our code base somehow (hooray!). ToyBrep has some basic NURBS support, plus a minor ability to read/load STEP files. In lolcad, there's basic NURBS support, and an ability to export STEP. In both cases there is a need for more mathematical geometry work before all standard NURBS manipulation routines are finished.. so there's progress, and in my opinion, in a more manageable form than OCC and perhaps even BRLCAD. I say progress over OCC because (1) the fundamentals of CAD have been simplified to a project that a single man can approach [whereas most people claim CAD is impossibly hard] and progress over BRLCAD because (2) it's a very specialized kernel. #2 is kind of a cheat-- in reality, I should be writing software for BRLCAD, but I like to pretend I don't want to have to do all of the integration work into the BRLCAD libraries, which in actuality might turn out to be not that much work, etc. At the very least, there's a definite advantage in turning CAD from something "big and scary" to "a weekend project [once the programmer understands everything that needs to be written]".

Also an interesting alternative is to just buy the company behind OpenCASCADE as a group and then transform it into a more lively project. Where's Mark Shuttleworth when you need him?

I'm not sure I'll submit patches to Thomas' "opencascade community edition" repository. I'd rather apply patches against the official OpenCASCADE repository. Does anyone have the old 2001-2004ish cvs repository or access to it? It's something like...

cvs -d :pserver:Gille...@cvs.opencascade.com:/home/server/cvs/KERNEL

[Leo Dearden]

On Mar 11, 2011 5:40 PM, "Bryan Bishop" <kan...@gmail.com> wrote:
>
> On Fri, Mar 11, 2011 at 11:21 AM, Leo Dearden wrote:
>>

>> I'd say we can't loose, really. ... After all:

>>  
>> > fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). 
>>
>> I'm sure we'll do better than that. :-)
>
>
> Unfortunately, I am not as optimistic about OCC. As a developer, what incentive do I have for working on OpenCASCADE? The code base is awful. Awful a million times over. People say writing a CAD kernel is hard. You know what's harder than CAD? Fixing broken CAD. Good developers know to work on BRL-CAD instead.
>

> OCC is hardly a good representation of software code quality that can come out of open source projects. ...
>

Indeed, I'm happy to believe that there are many better, but it didn't seem _that_ bad when I looked at a few years ago. It seemed like a perfectly workable  basis for a first cut of a geometry aware heuristic CAM algorithm I've been mulling over.

I gave OCC less than a day and I've learned a lot about code quality since then so more warts may reveal themselves on further examination.

I'll give it at least the benefit of another look. :-)

> In my opinion, I've narrowed down what relevant projects I should contribute to, and one of them has always been BRLCAD.

Thanks for pointing me to BRL-CAD, it certainly has an impressive heritage and it's clearly industrial strength.

I have misgivings about doing that sort of work in C, but I'll give it a close look.

> I'm not sure I'll submit patches to Thomas' "opencascade community edition" repository. I'd rather apply patches against the official OpenCASCADE repository.

I don't care about the history, which could always be grafted in later, anyway. I'm interested in the future of the project. I'm delighted to use a git repo and I'd hate to return to the dark ages of CVS.

I'll be interested to see where this goes, and I may contribute (my backlog is long).

Cheers

Leo

[Bryan Bishop]

---------- Forwarded message ----------
From: <do-not...@opencascade.com>
Date: Fri, Mar 11, 2011 at 2:51 PM
Subject: [OCC Forum] Thinkings about the 6.5.0 release, OCCT status, and the relationship with the Community
To: Bryan Bishop <kan...@gmail.com>


This message was sent from www.opencascade.org forum user Thomas

http://www.opencascade.org/org/forum/thread_20111/
------------------------------------------------------


Hello All,

I really appreciate your efforts. I just won't make complains to the OCC team anymore. We know their positions, and they are basically saying "we do business here, and community doesn't return anything". Not true, but let them see what we can do together, and make change their minds! Even with all the limitations, having OCC open source is a great thing.

Since now, what comes from community:

- A wiki
- A cloned repository
- A large collection of patches from Roman, Denis and many others scattered around the forum
- A sourceforge project with previous versions patches.
- Some OSS community projects:
- Qt OCC
- CMake experimental builder
- older (improve cascade...)
- Salome ports
- Others?

- This forum


These OSS projects could be organized and merged in a single repo as "contrib features". Also patches would be useful if presented in a diff/patch format too , and categorized as "experimental, tested, etc...", so one can select witch one to pick, instead of the full "community edition". Could this be done with the wiki?

Also , having a simpler build system would be much better than mantaining 5/6 different project files. In windows, for a community user, it is unlikely to have 4 versions of visual studio installed (which can be normal in a developer machine), so updating a project can be hard.
Cmake is good at this, even with a bit frustrating syntax, but it would simplify so much the management of project files.

The risk of diverging too much is real, but what should we do?
With a complete repo we distribute the effort of having a patched OCC (that everyone has anyway). I suppose that with git you could ignore/revert some commits in your local copy, if you want.
A doubt: will it be easier to integrate the diffs between consecutive OCC versions in the repository, or reapply the patches to every new OCC version? This probably depends on how much the repo changes in the time.

A wiki page could be used to track the latest modifications/improvements done , and a list of common bugs/workarounds.

This is only "loud thinking", just my 2 cents.

I already cloned the repo (readonly by now), but as a subversion user I still have to become productive with git :) WOw, that's much faster than svn!!

Good bye
Thomas (another one, i will change my nick soon :)

------------------------------------------------------

--

[nat...@natasha.cc]

When using acronyms, say what they refer to upfront. There are
zillions of acronyms floating around.

Thanks,
Natasha

Quoting Bryan Bishop <kan...@gmail.com>:

> --
> You received this message because you are subscribed to the Google
> Groups "Open Manufacturing" group.
> To post to this group, send email to openmanu...@googlegroups.com.
> To unsubscribe from this group, send email to
> openmanufactur...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/openmanufacturing?hl=en.
>
>

[C Y]

(full disclosure - I work on the BRL-CAD project, but my comments here
should be taken as coming from just me as an individual, not
representing the opinions of any other group or organization)

On Mar 11, 12:40 pm, Bryan Bishop <kanz...@gmail.com> wrote:

> Both of us agree we should be merging our code base somehow (hooray!).
> ToyBrep has some basic NURBS support, plus a minor ability to read/load STEP
> files. In lolcad, there's basic NURBS support, and an ability to export
> STEP. In both cases there is a need for more mathematical geometry work
> before all standard NURBS manipulation routines are finished.

My sense is that the basic need for handling of NURBS is a common and
daunting problem for all open source CAD efforts. There are a number
of projects that have some capability for NURBS, but from my
standpoint the most interesting starting points are:

1) openNURBS: http://www.opennurbs.org/

OpenNURBS is from the developers of the Rhino3D software, and is
actually a subset of the code they use in production (which means it
gets hammered on for real-world use.) It IS a subset - they
deliberately do not release advanced code like surface tree building
routines and intersection functions - but it provides a very good
foundation and DOES have a lot of very useful routines. It's license
is extremely liberal, but it provides the basis for a solid NURBS
library rather than being one itself (more on that later). This is
the library BRL-CAD builds on for its NURBS support. Primary
documentation for this library is comments in the source code, and
some wiki documentation from the Rhino devs.

2) SISL: http://www.sintef.no/sisl

SISL lists the most comprehensive feature set I know of for an open
source NURBS library, including surface/surface intersection. It also
is licensed commercially for industrial use, so it presumably gets a
workout in real-world conditions. As its license is GPL (I believe
this is a deliberate - and sensible - choice to preserve commercial
licensing options) it is not a viable option for BRL-CAD and I haven't
dug into it any further. For people interested in doing a GPL CAD
system, that would be my first suggestion on the "existing tools to
evaluate" list. Their pdf manual looks like the place to go if you
want to get a real sense of its coverage.

3) Ayam (http://ayam.sourceforge.net/) is a NURBS modeler and
implements a variety of interesting features (but not, as far as I
know, the heavy duty intersection functions) and is BSD licensed.
Certainly a logical place for anyone doing open source NURBS work to
look.

4) Varkon (http://varkon.sourceforge.net/) is working on NURBS
support (I believe they already have some support for simpler splines,
but I can't speak to that with certainty). They are either LGPL or a
combination of GPL and LGPL pieces. Documentation is somewhat lacking
on their website.

>... progress over BRLCAD because (2) it's a very specialized kernel. #2 is

> kind of a cheat-- in reality, I should be writing software for BRLCAD, but I
> like to pretend I don't want to have to do all of the integration work into
> the BRLCAD libraries, which in actuality might turn out to be not that much work, etc.

BRL-CAD is building on the openNURBS libraries for NURBS support, but
openNURBS by design doesn't include everything that is needed. BRL-
CAD's extensions to openNURBS are indeed currently integrated into its
librt, but that means anyone wanting to use them would need to pull in
enough of a subset of BRL-CAD's libraries to build librt. Over time
that should get simpler (e.g. work is gradually progressing to move
the requirement for Tcl to a higher level in the libraries) but right
now it's a bit intimidating.

Some months ago, I put in a takeover request for the old libnurbs
project on sourceforge (they produced the open source, LGPL NURBS++
library). The project has been inactive for years and abandoned, so
my request was granted and I'm hoping to revitalize things. Rather
than use the pre-existing NURBS++ code, which most likely has a lot of
overlap with openNURBS, I propose to build on the actively developed
openNURBS code and add the missing functionality to make a full-
featured libnurbs that any interested CAD project can build on.
Initially I would like to see if the new libnurbs effort can remain
licensed under the New BSD license (logic is similar to openNURBS -
wide usage is good), so the original NURBS++ code won't be usable
unless the original author(s) can be reached and agrees to relicense.
It's not a major concern unless it turns out that the NURBS++ code has
major, difficult to design and implement functionality that openNURBS
does not - so far I'm not aware of any such, but if something turns up
I'll make another attempt to locate the original author. I should
stress that libnurbs isn't an official effort of the BRL-CAD project,
it's just me.

Right now, libnurbs is just the openNURBS codebase with CMake logic to
get it building and a couple of bug fixes from the BRL-CAD tree that
Rhino has decided not to apply yet for one reason or another. My
proposed plan is to:

1. Convert the header/source code documentation (which is pretty much
THE documentation) to Doxygen format so we can generate readable,
hyperlinked docs. That's a big job, and will take time, but I think
it's worth it.

2. Get openNURBS building with the strictest compiler flags that are
practical (lesson from BRL-CAD - make the compiler help you catch
things whenever possible)

3. Survey the available features, which parts of the code are
conditionalized on RHINO and OPENNURBS_PLUS flags (those are
indicators that we'll need to tie in new features like surface tree
building to those code locations), and write up a "here's the list of
things we need, and the order we need them in" TODO.

4. Start working down the list.

This obviously doesn't get us a working CAD kernel directly, but I
believe it is a necessary precursor to a robust NURBS capable CAD
kernel and since we all need it, why not do it once under a license
everyone can use?

Would that be a more manageable and approachable job than "integrate
new feature X into BRL-CAD"?

The other task along those lines is building the NIST STEP Class
Libraries into something that gives everyone a robust ability to
handle STEP files, but for at least some situations I think that
effort will need the libnurbs library or something like it to call on
for resolving NURBS issues. On the other hand, if NURBS doesn't
appeal there are a LOT of less mathematically rigorous jobs to do on
the STEP code (it predates STL and among other things rolls its own
string class, for example). If that's of interest we could see about
setting up a sub-project to improve that codebase too.

Does any of this sound like it would appeal to the folks interesting
in working on open source CAD?

Cheers,
CY