Thanks for sharing @bitacovir ! I watched it a few times but couldn't really understand exactly what was being proposed (other than the creation of a legal company from the guys behind IFCJS). The website (https://thatopen.com/) also seems to be just a landing page and a subscription button.
@Moult said:
Thanks for sharing @bitacovir ! I watched it a few times but couldn't really understand exactly what was being proposed (other than the creation of a legal company from the guys behind IFCJS). The website (https://thatopen.com/) also seems to be just a landing page and a subscription button.
I've invited @agviegas to write a post on OSArch.org advertising the new platform. Here's a summary for those who prefer text:
"That Open People" A social website which (I think?) supersedes their previous Discord channel which includes chatrooms, recorded videos, threads, etc (based on CircleOS - a proprietary social platform).
"That Open University" A new online course platform with a focus on IFCJS. I believe it includes their older courses but includes a bunch of new content both paid and free.
"That Open Engine" A rebranding of IFCJS and its components, as well as new libraries and components to build your own BIM apps. One of the most exciting new components is something called "Clay" which can edit IFC geometry. Other components include widgets to show properties.
"That Open Editor" a hosted distribution of a bunch of IFCJS components which will become an online BIM application. It includes both ThatOpen Company built and community built components. Nice! Nothing like this currently exists I believe.
"That Open Services" the hosted BIM app editor needs a platform to store and serve models, do cloud processing, etc.
"That Open Store" an online marketplace to sell IFCJS-based components.
... It's disappointing hearing @agviegas giving the impression that IFCjs / That Open Company is the only opensource thing ever to have happened in all of AEC/BIM ... he started here in this forum/chat getting help from existing experts in IFC. There, I got that out of my system.
@Moult said:
I've invited @agviegas to write a post on OSArch.org advertising the new platform. Here's a summary for those who prefer text:
I prepared a similar summary tldr;
Open Engine: A common free open IFCJS-based technology stack (viewer and parser)
Open Store: A marketplace where developers can sell tools, and users can buy them directly for use in their projects.
Open Editor: A free web-based geometry editor (CLAY) that allows users to run all apps directly in their web browsers.
Open Services: Processing, storage, and analytics services developed by That Open Company to help developers create and release software.
That People Community: Meet other members, forums, chats, and meetings every six weeks within That Open Company's team to find out what's happening exclusively things while sharing opinions.
Open University: A new(? rebranded) platform built by That Open Company to create a path from zero knowledge about programming to becoming a software developer in less time than possible, with teachers supporting students in their career paths.
At this point it seems that they are open to collaborating with other tech like IFCOpenshell Speckle, but on an inbound basis only. i.e. other projects have to be built for the Open "aecosystem". No criticism for that, bandwidth is a precious commodity.
@duncan said:
... @agviegas giving the impression that IFCjs / That Open Company is the only opensource thing ever to have happened in all of AEC/BIM ...
+1. We are standing on the shoulders of giants. That's how open source works. None of us work alone.
@jsdbroughton said:
At this point it seems that they are open to collaborating with other tech like IFCOpenshell Speckle, but on an inbound basis only. i.e. other projects have to be built for the Open "aecosystem". No criticism for that, bandwidth is a precious commodity.
It does seem to be that way unfortunately. This is one of a few things that make "That Open Company" seem a little hypocritical / openwashing. I don't think this is a good thing - open source is not about technology ... it's about a culture and mindset: communities should work together because that's the right thing to do, even if their technologies have different technical strategies (and especially if we have different technical strategies ... all strategies have pros and cons and are suitable for different people). A few other (constructive?) criticisms I have are the secretive nature of "That Open Company", and the centralised / closed-door fashion at which decisions are made.
I was sent this message from Jesus Valderrama after I posted about the BlenderBIM Add-on on the "Share your wins section" and was asked to remove my post. Emphasis my own added in bold, which highlights the difference in mentality between open source in name vs open source in culture:
That Open People is not and does not pretend to be the meeting space for the open source advocates in the AECO sector. We understand that there are other forums like OSarch that are. You do a great job, we would love to participate and we will be very happy with all the success you can accumulate.
For That Open Company, open-source is a means, not an end, and its goal is not to promote open-source but to open the market, increase competitiveness in the sector and turn as many users as possible into AECO Software Developers. To achieve this we are developing That Open Platform, a technology platform that among other things has That Open Engine, which is and always will be Open Source and free.
We have created That Open People to support all who want to participate in this goal.
This is just personal opinion of course. For example I love playing NetHack and that's as secret as it gets when it comes to free software ;)
I have the impression that is their stab to build a community which they plan to somehow monetize later on. Maybe build the platform/eco-system and take a cut if contributors start selling stuff. Kind of like Gumroad i would imagine. That's why they hype it so much as they need content creators in the long run and a lot of them. Nothing wrong with that IMV. Though the term open-washing seems kind to fit.
Anyway, that cult like intro "you are a slave ... we show you the freedom in money/time/life" doesn't resonate well with me.
All of this launching is kind of unfortunate. Specially, because one can perfectly make money and contribute to the community at the same time. I tend to be very understanding and open minded with respect to these topics, after all, we are a gazillion people in the world, and it's statistically unlikely to agree among many of us on how to tackle any project up to the tiniest of the details. To me, it's as easy as producing a positive net outcome towards the outside world, either as an individual or as a group/community/company. A clear example that doesn't fit into this brief description could be a company that hinders progress from its field in order to keep its monopolistic position, i.e. AutoDesk. Being focused on licensing fees instead of on adapting Revit to the decade we live in definitely doesn't help.
Another example: Modular. They're building Mojo, a superset of Python suited to systems programming. They've just raised the absurd quantity of $100 million. They've said Mojo will be open sourced in the future, but currently isn't. As a potential future user, I'm really curious about how they plan to recover the investment. A programming language that charges for its use? doesn't look feasible. Will we get ads while compiling? who knows. I'm definitely willing to see how that gets resolved, but in the meantime, a LOT of things must be being done with that money. Comparing apples to apples, if some enthusiast devs had attempted the same task, we would have a fully open source lang from the first day, but evolving at a much much much slower pace. Which option is better? I don't know, in a couple of years we'll have more info, if the compromises to use Mojo put a slice of those $100 million on me as a user, it may not be a good option regardless of how good the language is. But what I try to say, is that in my view, neither the VC funding option, nor the fully open source option, are intrinsically better or worse. I wouldn't say neither of them is the right thing to do, it depends on the details.
With this mindset, something like IfcOpenShell / BlenderBIM is truly fantastic. They don't ask for anything, and give back a top class lib / full-fledged desktop software. I could argue that sometimes they could plan more ambitiously and achieve the same goals faster without renouncing to their spirit (every now and then I tend to make suggestions along these lines), but overall I'd say it's 9/10. Difficult to improve, very easy to make worse.
In turn, IFC.js / That Open is not bad either, there's already web-ifc-three / viewer, fragment, components, clay... with MIT license. It would be even better if they were more open in nature and further collaborated with the rest of the AEC open source community, sure. But it can't be denied that some of the achievements they've had are precisely because of the expectations of either users paying courses or companies looking for an ACC alternative. For the sake of fairness, if comparing apples to apples, in order to criticize their closed-door behavior, it's worth taking into account that the state of the MIT libs would be more primitive otherwise. Now, having said that, I was seeing this video about issues arising in Zig for a 5000$ bounty, and definitely recalled the bounty program from IFC.js... which no longer exists. I don't know what Tooeen was. I don't know if they are going to keep suporting IFC or not. I don't like their aggressive marketing while promoting their company, before having explained how it will work. I don't even know if the IFC.js name will prevail or not. And I don't know how many more upside downs will occur during the next years. I guess a bit more transparency would be appreciated by the community. The message asking Dion to remove his post? not pretty either. Probably a reason was because ifcopenshell-wasm was mentioned. But if it was crystal clear that the message board is part of their closed side, Dion probably wouldn't have posted, or would have posted a different message.
All in all, in my view That Open could avoid a ton of misunderstandings if they just clarified the parts in which they are not open or don't plan to be. As I said at the beginning of the post, I find it totally reasonable that they want to monetize the new platform, but being ambiguous with even Open in the name doesn't help. We already know about OpenDataBIM for a case which doesn't fit the name very well.
Hi all, and thank you all for your interest in That Open Company!
I’m more than happy to clarify what our approach is and I hope this will solve the concerns you have expressed.
Let’s start with the core. Movements arise from the need to solve a problem. For us, the main problem is that software creation in the AECO sector is monopolized by a few big players and that greatly limits the freedom of users. Since there are no alternatives, users have no choice but to follow the rules of these big players. And we think that’s not good.
To try to solve this problem there may be many different possible solutions, and we respect them all. But since we cannot execute them all, we have chosen one: the one that we think may be most effective in solving it. Could there be others? Of course! But this is the one we have chosen. And this solution is based on the premise that if anyone can create software for the AECO sector, easily and for free, many people will start creating software, which will increase healthy competition and break the oligopoly of the big players.
That is our goal. Everything else is just resources that will help us achieve it. Open source, for us, is a resource that allows us to offer free technology to everyone with the guarantee that if we disappear, the technology will still be there for them forever.
Open source. Free. Forever. And here I answer one of your questions: yes, the technology that That Open Company is developing so that anyone can create software for the AECO sector will always be open source and free. Because we think it is the best way in which we can help solve the problem.
That said, we are aware that solving this problem is not easy: we will need strength and speed. For this reason, we have given our movement the format of a company. Because a company can dedicate resources to speed up the process, and that's what we're doing at That Open Company.
Obviously, to dedicate resources, we have to generate income. And for that we have created a series of services associated with the free and open source technology that we offer. And the income we obtain from these services will allow us to continue developing free and open source technology for everyone much faster.
Is it mandatory to contract these services? Of course not. As I told you, anyone can access the technology for free. And this will be forever. But paid services are a way to increase the speed with which we can develop free and open source technology, and therefore help solve the problem faster.
And they are divided into 2 types:
Services that help developers to make their work easier (That Open Services)
Services that help non-developers to become developers as fast as possible (That Open University).
That being said, let's get to the topic of “Open” in the name “That Open Company”. Our “Open” refers to 2 things:
The first and most important one refers to our solution to solve the oligopoly problem of the big players. Which, as I said before, is to “Open” the market, allowing anyone to develop software easily and for free.
And the second is that we do create open source technology (MIT) to make it available to people for free. Because we think it's the best thing we can do to help solve the problem.
Does this mean that we think everyone must offer their technology for free? Obviously not. If the new players that we want to enter the market (to generate healthy competition and break the oligopoly) cannot make a living from it, there will be many fewer of them and they will have much less strength. And this could even mean that the problem will never be solved. Because spending 8 hours a day creating technology is not the same as spending some of your free time.
In the video game industry, anyone can create video games and make a living from it thanks in part to the fact that there are tools to create them that are open source. Even though most games are not open source, the market is accessible, just as we want our market to be. Likewise, we will be free and open, but we will never force our users to follow our example and make their technology open source or free, although we will encourage and welcome it!
And this is part of the goal of That Open Company. To help everyone who wants to become a BIM Software Developer to free the market so they can make a living doing it. Just like I did.
I have been working full time as a BIM Software Developer for an external company and it has been going very well. And at That Open Company we want to offer that same opportunity to everyone who wants to take advantage of it. And also help everyone who wants to create their own businesses based on our technology, because they will also generate healthy competition and help free up the sector. And we will do this through That Open Store, where anyone will be able to sell their apps (or give them away for free, if they want).
I hope that clears up our position, our goal, and how we believe is the best way to achieve it. And, of course, you are all invited to be a part of it ?
@agviegas I think you're missing the point. The point isn't about trying to make money or setting up a company or charging. It's about a free software culture. This culture is many things to different people, and it's hard to describe, but there are some things that IFCJS are doing that feel foreign. At least to me, and I've been around a lot of free software projects for a long time - in contrast, the FLOSS culture in AEC is relatively new. It's hard to describe unless you've experienced it yourself, but I'll do my best.
Some of these cultural aspects are transparency vs secrecy. Traditionally, FLOSS operates transparently. For example, in IRC chatrooms, private images are often frowned upon and all Q&A happens in the open. Text discussion are preferred over voice to allow participation across timezones, languages, and to be more objective. Leadership role discussions are mostly public. So when ThatOpen holds back data and decides behind closed doors and the consistent answer to questions are "it's under wraps now, you'll know later", it doesn't feel right. It also feels wrong that code documentation is locked behind a registered-user-access-only proprietary platform.
Another is supporting other complementary FLOSS software. There's a lot of code sharing, helping out in debugging and bugreports, and pointing out similar / overlapping technologies. Have you ever noticed how many free software readme files actually list alternative projects that do the same thing? Censorship and one-way relationships aren't cool, especially when the FLOSS space in AEC is really tiny already and all the major projects do very different things and aren't competing because they have very different stacks and usecases - nobody isn't really competing with each other (except perhaps a few things like LibreCAD / QCAD where they really do overlap). But if FLOSS is just a means to an end, I can see why it isn't fun to join the party.
This is an odd one and not necessarily bad, but the emotional marketing seems out of character. The highly emotive "you are a slave" combined with a sell first, build later approach isn't something I've seen before. It seems overconfident to talk down to the users, especially when the software is incomplete. Users and developers really should be treated as equals because culturally FLOSS software development happens hand in hand with users. Developers themselves are standing on the shoulders of giants and no one developer has all the answers. We're all just another pair of eyeballs in Linus' law. Maybe by itself this is fine, but I've experienced that a lot of the marketing to be false in the end. For example Tooeen was heavily promoted as an open source CDE ... and now the plan seems to be that Tooeen is closed and if you want a CDE you have to build it yourself.
A few other strategies also seem at odds with those usually done by FLOSS organisations, probably again due to cultural differences. For example, it rings alarm bells to me when a store or learning platform becomes centralised at a very early stage. I know that's what makes your strategy unique (and potentially successful?), but it's definitely a rarity. It's also an alarm bell to me personally when non-open protocols or non-free software are not supported for social media (e.g. see what most FLOSS orgs do: 1, 2, 3, 4, 5, 6, 7, 8, 9).
There is often a distinction between free software (the original term) and "open source". Free software is a political and ethical choice. If you're using open source as a means to an end (i.e for its technical and marketing benefits) as opposed to the original ideology, that's where the discrepancy arises.
You can't buy a culture. A company can't dedicate resources to speed up the process in creating a culture.
I hope this helps, and if this doesn't resonate, that's OK. I'm still really grateful for having an open source option filling a really needed void in our industry, but if some of this makes sense, perhaps it will help reach out to a wider audience.
Thank you @moult for your comments and for providing your point of view. Probably I haven't expressed myself clearly enough in the previous post regarding culture.
We think the traditional FLOSS culture is excellent, but we are a private company with our own culture: the one that we believe will help us solve the oligopoly problem and help our users achieve their goals faster. As you mentioned, for us open source is a means and not a goal. We create open-source software and we give it away for free (and we always will) because we think it is the best way to help the sector open the market and our users to be able to make a living from it.
Our culture is thoroughly explained in the first spaces of our community, That Open People. We are not buying a culture, but we are not blindly assuming other existing cultures either. We are creating our own culture based on our community and the market's needs, together with all the people and companies who want to share our vision.
I hope I’ve thrown some light upon what we are and what we are not. I personally welcome the diversity and heterogeneity of both cultures, and I hope we can continue to grow and thrive in the industry.
On the grand scheme of things, we're talking about the current state of the AEC industry, which exists in every country of the world, has a market size of $9 billion, and is currently having subpar performance due to its obsolete Software. Meaning, there should be A LOT of interest in improving it, because even the slightest enhancement can have a significant overall impact. I'm with @agviegas on this. A "culture" can be good if it achieves a positive end result, but the inclusion of more diverse points of view has the potential to make an even bigger difference. In other words, 2 or 3 AEC devs working at the purest FSF style can achieve some things, but 10000 people (made up numbers) from overall the industry paying attention to the productivity of these newly available tools... is something else. Including that the most idealistic among them could add up to more than those original 2/3 devs in this example. So in my view, it just wouldn't make sense not to address a broader audience, in broader terms.
Then, we already have an open standard like IFC, which AutoDesk created and promoted when interoperability helped them get their market share, but are currently trying to frame as a PDF. It is indeed complex, with simple entities in imbricate relationships, without everything rooted (having a GlobalId), with tricky arraying/mirroring... but it's an ISO standard and it's written in stone. Zero problems coming from constantly updating versions. Eager to see what the HOK guys build with USD, but IFC already works. It's impressive how people knowing nothing of IFC are convinced that it has some fundamental flaw, AutoDesk has clearly scored us all a goal on this one. Moreover, we must keep into account that any attempt at defining another simplified schema, risks to learn the hard way that complex things aren't easily simplifiable. BTW, is That Open going to develop another simplified schema? and also @agviegas , would you take a stab at the rest of the questions? you made a long text but didn't answer them. That's the kind of thing I criticize (and would criticize from a traditional company making privative software, or from a movement following the FSF culture, that's totally independent), users need to know what they get involved into.
In addition, @Moult what's so wrong with the sell first / build later approach? Look at @Andrej730 now at IfcOpenShell, doing an awesome job. What if there were 10 more Andrejs? It could be "sold" that if companies contributed with, say $300/month, they'd have preferential support, including meetings / custom instructions oriented towards their projects, and the promise BlenderBIM would reach 1.0 ages sooner. Of course, Blender is Blender and some people run away on seeing a screenshot, but some others do not, and given its power and the pricing of Revit licenses, a bunch of big companies could be already interested in something like this. Even more... authoring in Blender and following up on the web with the platform That Open is building? The end game. You guys should be collaborating.
The copyleft / permissive debate is also very interesting in my view. I tend to lean more towards the freedoms of MIT licensing. It's true that any Blender add-on requiring to be GPL can prevent some companies from joining in if they can't commercialize a custom add-on. But seeing where BlenderBIM already is, I believe it just makes sense by itself if they can just use it internally and progressively substitute Revit.
Enough IfcSlab for today! ;) I'd be truly glad if views around these two awesome projects could be brought a bit closer.
Sure @agviegas. You explained the philosophy behind That Open in detail, as well as the thought process to include "open" in the naming, but avoided the rest of the questions. I rewrite and list them below:
1) You guys are building a BIM platform, you must then know which data schema you're going to be building upon. Is it IFC or something else?
2) The name/brand IFC.js is going to be deprecated?
3) What happened with Tooeen? even if what was built is now within That Open Services, how can you guys convince users that the new thing is going to be stable in time? in terms of naming / scope / direction. I guess some more info will come out when you have your roadmap ready.
4) If I may ask, can you give some public feedback about what the involved companies are interested in? just using the platform internally, selling some addon on That Open store, or anything else?
5) Do you want to clarify anything regarding the suggestion to Dion to remove his post on That Open People?
6) Do you see ifcopenshell-wasm or xeokit as competition? And hence, are comments involving in some way these open source projects considered promotion in accordance with That Open People community guidelines?
I find all of these are interesting and valuable for users to know more about what That Open can become. Thanks in advance!
I guess I'm pointing out that TL;DR there are very different mindsets here: free software as an ethical choice, and free software as a means to an end. Both ends always find the other alienating. It's generally hard to bring these views closer - people generally sit somewhere on the spectrum and rarely budge.
You guys should be collaborating.
We should. Absolutely. Let's focus on this now that we've clarified our differences. Here are some ways I think we can collaborate:
Low hanging fruit: Promotion of each other's projects. More IFC being used: good for both of us! BBIM/IOS isn't good at online collaboration platforms / CDE like things to share IFCs once they're created. Vice versa, ThatOpen isn't good at original authoring. If we promote each others projects, users win! Actions: 1) more posting about ThatOpen news / events on OSArch (I already share all IFCJS posts on social media). 2) vice versa allow promotion of non-ThatOpen tech on That Social People (maybe create a dedicated section called "External resources" if you want to separate it from ThatOpen tech) and 3) more shared events together (how about a hackathon showing a model going from one to another?)
Slightly harder: Code sharing. IOS/BBIM has been around a long time and has many features which are useful when delivered via a web serivce / CI / BIM server / CDE, but we haven't wrapped it in any web-accessible interface. Things like IfcPatch, IfcCSV, IfcFM, etc could be wrapped in a RESTful interface and used by ThatOpen to immediately bring users much more value as a set of "CI-components". Vice versa, Blender is really poor at being an interface to certain aspects like gantt charts and cost schedules and desperately needs an accompanying web UI, we could work on bundling an offline or local IFCJS implementation or work on widgets together like Gantt charts or smart cost schedules (we have a lot of experience in this area of IFC). Actions: perhaps start with a knowledge sharing session to the full scope of features each technology has, and then determine which features could be easily isolated / bundled for each other's stacks.
Much harder: API alignment for native apps. Most of the mammoth's work in IOS is determining clean subgraphs to edit. This requires a lot of sitting down and co-developing to ensure that native IFC editing can be shared across multiple platforms. E.g. if ThatOpen claims to author / edit IFCs, it would be so much more powerful if that native IFC authoring worked out of the box across BBIM, FreeCAD, and IfcGit. Native authoring is a lot harder than people think. Actions: a detailed technical discussion around some of the higher level APIs like Clay or IFCJS's equivalent of "get_psets" et all. Especially a discussion about how IFCJS handles representation contexts.
Even harder: alignment of drawing generation strategies. IFC has the potential to completely change how drawings are used in our industry. If our drawing semantic conventions were aligned, we could together put forward a strong proposal to buildingSMART and help define the standard for drawing semantics. Things like sheets, drawings, schedules, and more.
Interoperability with non-SPF IFC data like SQLite and MySQL, or partial change with IfcJSON. SQL and JSON are excellent in web environments and can allow IFC to be used in many more stacks.
Shared geometry test suites. IOS has built up a large collection of test suites over the years to ensure correct geometry. It would be good to share efforts in maintaining a comprehensive set of complex geometries that often fail to be parsed to ensure that all our platforms work.
Shared external psets, asset libraries, and offline classification libraries.
I'd like to point out that I didn't actively avoid answering the questions. With all the ideas and feelings in this thread before my first post, I did my best to try to address everything. I'm sure next time I'll do better, but I hope that we are on the same page here. ?
That said, here are the answers @cvillagrasa ! I've taken the liberty to split some of your questions that address multiple topics.
1) IFC! As you know, we are also building fragments, but that's not a schema. It's just a geometric data structure to allow Three.js to represent big amounts of BIM data efficiently. The reason why we are doing this is because more naive strategies (1 mesh per IFC object / the whole IFC as a single mesh) proved to be insufficient to draw buildings beyond medium size. If you have alternative ideas and three.js code, I'd love to see them.
2) We honestly don't know. Right now it's not and we have no plans to deprecate it. It will depend mainly on our community's wishes.
3a) Tooeen is a project in progress that made it possible to make huge progress forward in the libraries (check out the development of the components repository from February to see exactly what that progress was), as well as the platform and the services (which are WIP right now).
3b) Indeed, we are preparing a roadmap that we will publish as soon as possible; it will give a view forward with the next steps. As you know, this has been a time of change for us; from now on, the name, direction, and scope of the project should be stable for quite some time. That said, that depends on the community. I think we haven't changed our ideas and ideals since I started IFC.js, but if tomorrow our community asks us to go in a different direction, we'll do it.
4) We hope to be able to publish something soon! In the meantime, for more specific details, you can check the progress in the components repository since february.
5) Just as any community, ours has public guidelines. As Jesus told Dion, we have created the Share your wins space so that our users have a dedicated place to share their achievements with our technology in their learning process. Therefore, that post on that channel was off-topic. We personally celebrate achievements with other technologies, and we believe OSArch is the best place to share them. We thought the guidelines are clear, but I'm going to Talk with Jesus to see if we can improve them.
6) Not at all! In fact, Dion has talked about them and suggested them as alternatives in every response he posted in our chat, and we think that's ok as long as our users are comfortable with that.
Thanks for the answers @agviegas. I definitely have a better idea now.
@agviegas said:
If you have alternative ideas and three.js code, I'd love to see them.
Not very much three.js on my side, but I used both IfcOpenShell and IFC.js to develop an interactive Jupyter Notebook environment. Just last week I was proposing to create a PyPI package to further automate things in Google Colab. I guess now your advice would be to use components instead... although the lib doesn't mention IFC in the README, that's why I asked question 1.
@agviegas said:
I'd like to point out that I didn't actively avoid answering the questions.
I know, just don't get mad at me if I point out now that you have a wonderful set of proposals from Dion in the message above. I repeat, it would be great if these two amazing projects could collaborate together!
@Moult thank you for your ideas! They look great, especially those that allow sharing of efforts / code and APIs to ensure that what we do is as compatible as possible with IOS / BBIM and vice versa.
Right now we're up to our necks in work. As you can imagine, building a company is not easy, and we're working around the clock from Monday to Sunday to make sure we get it off the ground. Right now it is going to be very difficult for us to dedicate time to these tasks. What do you say we wait a few months until we stabilise, and when we are sure that the ship is stable and sailing we revisit this thread?
@agviegas cheers, more than happy to wait a few months. In the meantime, would you be OK / is there a section in the ThatOpenCompany's social media where it would be appropriate to share non IFCJS technology?
@Moult thanks, cheers! As it is now, it will still be possible to talk about and recommend open-source technologies other than IFC.js in the chat rooms (for example, when Xeokit or IOS is recommended as an alternative to IFC.js). We think it doesn't make much sense to have a specific channel for other open-source technologies when OSArch is fulfilling that mission much better than we could. In fact, wouldn't this be a good opportunity to foster people from our community with those interests to post on OSArch?
For my part, I'm going to share the posts I see on Linkedin about other technologies to give them as much diffusion as possible!
@agviegas that's great! Can I clarify which rooms you're referring to? For example my post was deleted from the "Share your wins" section, but is the "Share a resource" OK? Or only the "Ask the Community"?
@Moult said: @agviegas that's great! Can I clarify which rooms you're referring to? For example my post was deleted from the "Share your wins" section, but is the "Share a resource" OK? Or only the "Ask the Community"?
I appreciate the efforts to clarify their position with regard to acceptable post material. With my poor memory, I will probably forget in 2 months and get my posts deleted.... after 10 or so future deleted posts my muscle memory should kick in and I will post in the correct room.
Everything should be clear in the guidelines! Otherwise, you are also free to propose improvements in Help us do better. The goal of our community is to have a space mainly dedicated to the open-source technology we have worked (and are working) so hard for. In general terms, if the post/comment has anything to do with IFC.js, it's ok
(even if it's "hey, have you tried Xeokit / IOS to do this thing you are trying to do with IFC.js?").
I'll do my best to redirect the people interested in other topics here.
Comments
Thanks for sharing @bitacovir ! I watched it a few times but couldn't really understand exactly what was being proposed (other than the creation of a legal company from the guys behind IFCJS). The website (https://thatopen.com/) also seems to be just a landing page and a subscription button.
You need to wait until september 20... ;)
That doesn't seem very open / transparent to me ...
I've invited @agviegas to write a post on OSArch.org advertising the new platform. Here's a summary for those who prefer text:
I think its awesome! Not just the community being able to use IFCjs libraries but I am really looking for the possibilities of IFCjs + IFCOpenshell.
... It's disappointing hearing @agviegas giving the impression that IFCjs / That Open Company is the only opensource thing ever to have happened in all of AEC/BIM ... he started here in this forum/chat getting help from existing experts in IFC. There, I got that out of my system.
I prepared a similar summary tldr;
At this point it seems that they are open to collaborating with other tech like IFCOpenshell Speckle, but on an inbound basis only. i.e. other projects have to be built for the Open "aecosystem". No criticism for that, bandwidth is a precious commodity.
+1. We are standing on the shoulders of giants. That's how open source works. None of us work alone.
It does seem to be that way unfortunately. This is one of a few things that make "That Open Company" seem a little hypocritical / openwashing. I don't think this is a good thing - open source is not about technology ... it's about a culture and mindset: communities should work together because that's the right thing to do, even if their technologies have different technical strategies (and especially if we have different technical strategies ... all strategies have pros and cons and are suitable for different people). A few other (constructive?) criticisms I have are the secretive nature of "That Open Company", and the centralised / closed-door fashion at which decisions are made.
I was sent this message from Jesus Valderrama after I posted about the BlenderBIM Add-on on the "Share your wins section" and was asked to remove my post. Emphasis my own added in bold, which highlights the difference in mentality between open source in name vs open source in culture:
This is just personal opinion of course. For example I love playing NetHack and that's as secret as it gets when it comes to free software ;)
I have the impression that is their stab to build a community which they plan to somehow monetize later on. Maybe build the platform/eco-system and take a cut if contributors start selling stuff. Kind of like Gumroad i would imagine. That's why they hype it so much as they need content creators in the long run and a lot of them. Nothing wrong with that IMV. Though the term open-washing seems kind to fit.
Anyway, that cult like intro "you are a slave ... we show you the freedom in money/time/life" doesn't resonate well with me.
@doia ' monetize later' sounds right
All of this launching is kind of unfortunate. Specially, because one can perfectly make money and contribute to the community at the same time. I tend to be very understanding and open minded with respect to these topics, after all, we are a gazillion people in the world, and it's statistically unlikely to agree among many of us on how to tackle any project up to the tiniest of the details. To me, it's as easy as producing a positive net outcome towards the outside world, either as an individual or as a group/community/company. A clear example that doesn't fit into this brief description could be a company that hinders progress from its field in order to keep its monopolistic position, i.e. AutoDesk. Being focused on licensing fees instead of on adapting Revit to the decade we live in definitely doesn't help.
Another example: Modular. They're building Mojo, a superset of Python suited to systems programming. They've just raised the absurd quantity of $100 million. They've said Mojo will be open sourced in the future, but currently isn't. As a potential future user, I'm really curious about how they plan to recover the investment. A programming language that charges for its use? doesn't look feasible. Will we get ads while compiling? who knows. I'm definitely willing to see how that gets resolved, but in the meantime, a LOT of things must be being done with that money. Comparing apples to apples, if some enthusiast devs had attempted the same task, we would have a fully open source lang from the first day, but evolving at a much much much slower pace. Which option is better? I don't know, in a couple of years we'll have more info, if the compromises to use Mojo put a slice of those $100 million on me as a user, it may not be a good option regardless of how good the language is. But what I try to say, is that in my view, neither the VC funding option, nor the fully open source option, are intrinsically better or worse. I wouldn't say neither of them is the right thing to do, it depends on the details.
With this mindset, something like IfcOpenShell / BlenderBIM is truly fantastic. They don't ask for anything, and give back a top class lib / full-fledged desktop software. I could argue that sometimes they could plan more ambitiously and achieve the same goals faster without renouncing to their spirit (every now and then I tend to make suggestions along these lines), but overall I'd say it's 9/10. Difficult to improve, very easy to make worse.
In turn, IFC.js / That Open is not bad either, there's already web-ifc-three / viewer, fragment, components, clay... with MIT license. It would be even better if they were more open in nature and further collaborated with the rest of the AEC open source community, sure. But it can't be denied that some of the achievements they've had are precisely because of the expectations of either users paying courses or companies looking for an ACC alternative. For the sake of fairness, if comparing apples to apples, in order to criticize their closed-door behavior, it's worth taking into account that the state of the MIT libs would be more primitive otherwise. Now, having said that, I was seeing this video about issues arising in Zig for a 5000$ bounty, and definitely recalled the bounty program from IFC.js... which no longer exists. I don't know what Tooeen was. I don't know if they are going to keep suporting IFC or not. I don't like their aggressive marketing while promoting their company, before having explained how it will work. I don't even know if the IFC.js name will prevail or not. And I don't know how many more upside downs will occur during the next years. I guess a bit more transparency would be appreciated by the community. The message asking Dion to remove his post? not pretty either. Probably a reason was because ifcopenshell-wasm was mentioned. But if it was crystal clear that the message board is part of their closed side, Dion probably wouldn't have posted, or would have posted a different message.
All in all, in my view That Open could avoid a ton of misunderstandings if they just clarified the parts in which they are not open or don't plan to be. As I said at the beginning of the post, I find it totally reasonable that they want to monetize the new platform, but being ambiguous with even Open in the name doesn't help. We already know about OpenDataBIM for a case which doesn't fit the name very well.
Hi all, and thank you all for your interest in That Open Company!
I’m more than happy to clarify what our approach is and I hope this will solve the concerns you have expressed.
Let’s start with the core. Movements arise from the need to solve a problem. For us, the main problem is that software creation in the AECO sector is monopolized by a few big players and that greatly limits the freedom of users. Since there are no alternatives, users have no choice but to follow the rules of these big players. And we think that’s not good.
To try to solve this problem there may be many different possible solutions, and we respect them all. But since we cannot execute them all, we have chosen one: the one that we think may be most effective in solving it. Could there be others? Of course! But this is the one we have chosen. And this solution is based on the premise that if anyone can create software for the AECO sector, easily and for free, many people will start creating software, which will increase healthy competition and break the oligopoly of the big players.
That is our goal. Everything else is just resources that will help us achieve it. Open source, for us, is a resource that allows us to offer free technology to everyone with the guarantee that if we disappear, the technology will still be there for them forever.
Open source. Free. Forever. And here I answer one of your questions: yes, the technology that That Open Company is developing so that anyone can create software for the AECO sector will always be open source and free. Because we think it is the best way in which we can help solve the problem.
That said, we are aware that solving this problem is not easy: we will need strength and speed. For this reason, we have given our movement the format of a company. Because a company can dedicate resources to speed up the process, and that's what we're doing at That Open Company.
Obviously, to dedicate resources, we have to generate income. And for that we have created a series of services associated with the free and open source technology that we offer. And the income we obtain from these services will allow us to continue developing free and open source technology for everyone much faster.
Is it mandatory to contract these services? Of course not. As I told you, anyone can access the technology for free. And this will be forever. But paid services are a way to increase the speed with which we can develop free and open source technology, and therefore help solve the problem faster.
And they are divided into 2 types:
That being said, let's get to the topic of “Open” in the name “That Open Company”. Our “Open” refers to 2 things:
The first and most important one refers to our solution to solve the oligopoly problem of the big players. Which, as I said before, is to “Open” the market, allowing anyone to develop software easily and for free.
And the second is that we do create open source technology (MIT) to make it available to people for free. Because we think it's the best thing we can do to help solve the problem.
Does this mean that we think everyone must offer their technology for free? Obviously not. If the new players that we want to enter the market (to generate healthy competition and break the oligopoly) cannot make a living from it, there will be many fewer of them and they will have much less strength. And this could even mean that the problem will never be solved. Because spending 8 hours a day creating technology is not the same as spending some of your free time.
In the video game industry, anyone can create video games and make a living from it thanks in part to the fact that there are tools to create them that are open source. Even though most games are not open source, the market is accessible, just as we want our market to be. Likewise, we will be free and open, but we will never force our users to follow our example and make their technology open source or free, although we will encourage and welcome it!
And this is part of the goal of That Open Company. To help everyone who wants to become a BIM Software Developer to free the market so they can make a living doing it. Just like I did.
I have been working full time as a BIM Software Developer for an external company and it has been going very well. And at That Open Company we want to offer that same opportunity to everyone who wants to take advantage of it. And also help everyone who wants to create their own businesses based on our technology, because they will also generate healthy competition and help free up the sector. And we will do this through That Open Store, where anyone will be able to sell their apps (or give them away for free, if they want).
I hope that clears up our position, our goal, and how we believe is the best way to achieve it. And, of course, you are all invited to be a part of it ?
@agviegas I think you're missing the point. The point isn't about trying to make money or setting up a company or charging. It's about a free software culture. This culture is many things to different people, and it's hard to describe, but there are some things that IFCJS are doing that feel foreign. At least to me, and I've been around a lot of free software projects for a long time - in contrast, the FLOSS culture in AEC is relatively new. It's hard to describe unless you've experienced it yourself, but I'll do my best.
Some of these cultural aspects are transparency vs secrecy. Traditionally, FLOSS operates transparently. For example, in IRC chatrooms, private images are often frowned upon and all Q&A happens in the open. Text discussion are preferred over voice to allow participation across timezones, languages, and to be more objective. Leadership role discussions are mostly public. So when ThatOpen holds back data and decides behind closed doors and the consistent answer to questions are "it's under wraps now, you'll know later", it doesn't feel right. It also feels wrong that code documentation is locked behind a registered-user-access-only proprietary platform.
Another is supporting other complementary FLOSS software. There's a lot of code sharing, helping out in debugging and bugreports, and pointing out similar / overlapping technologies. Have you ever noticed how many free software readme files actually list alternative projects that do the same thing? Censorship and one-way relationships aren't cool, especially when the FLOSS space in AEC is really tiny already and all the major projects do very different things and aren't competing because they have very different stacks and usecases - nobody isn't really competing with each other (except perhaps a few things like LibreCAD / QCAD where they really do overlap). But if FLOSS is just a means to an end, I can see why it isn't fun to join the party.
This is an odd one and not necessarily bad, but the emotional marketing seems out of character. The highly emotive "you are a slave" combined with a sell first, build later approach isn't something I've seen before. It seems overconfident to talk down to the users, especially when the software is incomplete. Users and developers really should be treated as equals because culturally FLOSS software development happens hand in hand with users. Developers themselves are standing on the shoulders of giants and no one developer has all the answers. We're all just another pair of eyeballs in Linus' law. Maybe by itself this is fine, but I've experienced that a lot of the marketing to be false in the end. For example Tooeen was heavily promoted as an open source CDE ... and now the plan seems to be that Tooeen is closed and if you want a CDE you have to build it yourself.
A few other strategies also seem at odds with those usually done by FLOSS organisations, probably again due to cultural differences. For example, it rings alarm bells to me when a store or learning platform becomes centralised at a very early stage. I know that's what makes your strategy unique (and potentially successful?), but it's definitely a rarity. It's also an alarm bell to me personally when non-open protocols or non-free software are not supported for social media (e.g. see what most FLOSS orgs do: 1, 2, 3, 4, 5, 6, 7, 8, 9).
There is often a distinction between free software (the original term) and "open source". Free software is a political and ethical choice. If you're using open source as a means to an end (i.e for its technical and marketing benefits) as opposed to the original ideology, that's where the discrepancy arises.
You can't buy a culture. A company can't dedicate resources to speed up the process in creating a culture.
I hope this helps, and if this doesn't resonate, that's OK. I'm still really grateful for having an open source option filling a really needed void in our industry, but if some of this makes sense, perhaps it will help reach out to a wider audience.
Thank you @moult for your comments and for providing your point of view. Probably I haven't expressed myself clearly enough in the previous post regarding culture.
We think the traditional FLOSS culture is excellent, but we are a private company with our own culture: the one that we believe will help us solve the oligopoly problem and help our users achieve their goals faster. As you mentioned, for us open source is a means and not a goal. We create open-source software and we give it away for free (and we always will) because we think it is the best way to help the sector open the market and our users to be able to make a living from it.
Our culture is thoroughly explained in the first spaces of our community, That Open People. We are not buying a culture, but we are not blindly assuming other existing cultures either. We are creating our own culture based on our community and the market's needs, together with all the people and companies who want to share our vision.
I hope I’ve thrown some light upon what we are and what we are not. I personally welcome the diversity and heterogeneity of both cultures, and I hope we can continue to grow and thrive in the industry.
On the grand scheme of things, we're talking about the current state of the AEC industry, which exists in every country of the world, has a market size of $9 billion, and is currently having subpar performance due to its obsolete Software. Meaning, there should be A LOT of interest in improving it, because even the slightest enhancement can have a significant overall impact. I'm with @agviegas on this. A "culture" can be good if it achieves a positive end result, but the inclusion of more diverse points of view has the potential to make an even bigger difference. In other words, 2 or 3 AEC devs working at the purest FSF style can achieve some things, but 10000 people (made up numbers) from overall the industry paying attention to the productivity of these newly available tools... is something else. Including that the most idealistic among them could add up to more than those original 2/3 devs in this example. So in my view, it just wouldn't make sense not to address a broader audience, in broader terms.
Then, we already have an open standard like IFC, which AutoDesk created and promoted when interoperability helped them get their market share, but are currently trying to frame as a PDF. It is indeed complex, with simple entities in imbricate relationships, without everything rooted (having a GlobalId), with tricky arraying/mirroring... but it's an ISO standard and it's written in stone. Zero problems coming from constantly updating versions. Eager to see what the HOK guys build with USD, but IFC already works. It's impressive how people knowing nothing of IFC are convinced that it has some fundamental flaw, AutoDesk has clearly scored us all a goal on this one. Moreover, we must keep into account that any attempt at defining another simplified schema, risks to learn the hard way that complex things aren't easily simplifiable. BTW, is That Open going to develop another simplified schema? and also @agviegas , would you take a stab at the rest of the questions? you made a long text but didn't answer them. That's the kind of thing I criticize (and would criticize from a traditional company making privative software, or from a movement following the FSF culture, that's totally independent), users need to know what they get involved into.
In addition, @Moult what's so wrong with the sell first / build later approach? Look at @Andrej730 now at IfcOpenShell, doing an awesome job. What if there were 10 more Andrejs? It could be "sold" that if companies contributed with, say $300/month, they'd have preferential support, including meetings / custom instructions oriented towards their projects, and the promise BlenderBIM would reach 1.0 ages sooner. Of course, Blender is Blender and some people run away on seeing a screenshot, but some others do not, and given its power and the pricing of Revit licenses, a bunch of big companies could be already interested in something like this. Even more... authoring in Blender and following up on the web with the platform That Open is building? The end game. You guys should be collaborating.
The copyleft / permissive debate is also very interesting in my view. I tend to lean more towards the freedoms of MIT licensing. It's true that any Blender add-on requiring to be GPL can prevent some companies from joining in if they can't commercialize a custom add-on. But seeing where BlenderBIM already is, I believe it just makes sense by itself if they can just use it internally and progressively substitute Revit.
Enough IfcSlab for today! ;) I'd be truly glad if views around these two awesome projects could be brought a bit closer.
Sure @cvillagrasa! My bad, I thought I had adressed them all. Would you mind listing them so that I don't miss any? ? Cheers
Sure @agviegas. You explained the philosophy behind That Open in detail, as well as the thought process to include "open" in the naming, but avoided the rest of the questions. I rewrite and list them below:
1) You guys are building a BIM platform, you must then know which data schema you're going to be building upon. Is it IFC or something else?
2) The name/brand IFC.js is going to be deprecated?
3) What happened with Tooeen? even if what was built is now within That Open Services, how can you guys convince users that the new thing is going to be stable in time? in terms of naming / scope / direction. I guess some more info will come out when you have your roadmap ready.
4) If I may ask, can you give some public feedback about what the involved companies are interested in? just using the platform internally, selling some addon on That Open store, or anything else?
5) Do you want to clarify anything regarding the suggestion to Dion to remove his post on That Open People?
6) Do you see ifcopenshell-wasm or xeokit as competition? And hence, are comments involving in some way these open source projects considered promotion in accordance with That Open People community guidelines?
I find all of these are interesting and valuable for users to know more about what That Open can become. Thanks in advance!
I guess I'm pointing out that TL;DR there are very different mindsets here: free software as an ethical choice, and free software as a means to an end. Both ends always find the other alienating. It's generally hard to bring these views closer - people generally sit somewhere on the spectrum and rarely budge.
We should. Absolutely. Let's focus on this now that we've clarified our differences. Here are some ways I think we can collaborate:
Thoughts?
I'd like to point out that I didn't actively avoid answering the questions. With all the ideas and feelings in this thread before my first post, I did my best to try to address everything. I'm sure next time I'll do better, but I hope that we are on the same page here. ?
That said, here are the answers @cvillagrasa ! I've taken the liberty to split some of your questions that address multiple topics.
1) IFC! As you know, we are also building fragments, but that's not a schema. It's just a geometric data structure to allow Three.js to represent big amounts of BIM data efficiently. The reason why we are doing this is because more naive strategies (1 mesh per IFC object / the whole IFC as a single mesh) proved to be insufficient to draw buildings beyond medium size. If you have alternative ideas and three.js code, I'd love to see them.
2) We honestly don't know. Right now it's not and we have no plans to deprecate it. It will depend mainly on our community's wishes.
3a) Tooeen is a project in progress that made it possible to make huge progress forward in the libraries (check out the development of the components repository from February to see exactly what that progress was), as well as the platform and the services (which are WIP right now).
3b) Indeed, we are preparing a roadmap that we will publish as soon as possible; it will give a view forward with the next steps. As you know, this has been a time of change for us; from now on, the name, direction, and scope of the project should be stable for quite some time. That said, that depends on the community. I think we haven't changed our ideas and ideals since I started IFC.js, but if tomorrow our community asks us to go in a different direction, we'll do it.
4) We hope to be able to publish something soon! In the meantime, for more specific details, you can check the progress in the components repository since february.
5) Just as any community, ours has public guidelines. As Jesus told Dion, we have created the Share your wins space so that our users have a dedicated place to share their achievements with our technology in their learning process. Therefore, that post on that channel was off-topic. We personally celebrate achievements with other technologies, and we believe OSArch is the best place to share them. We thought the guidelines are clear, but I'm going to Talk with Jesus to see if we can improve them.
6) Not at all! In fact, Dion has talked about them and suggested them as alternatives in every response he posted in our chat, and we think that's ok as long as our users are comfortable with that.
Thanks for the answers @agviegas. I definitely have a better idea now.
Not very much three.js on my side, but I used both IfcOpenShell and IFC.js to develop an interactive Jupyter Notebook environment. Just last week I was proposing to create a PyPI package to further automate things in Google Colab. I guess now your advice would be to use components instead... although the lib doesn't mention IFC in the README, that's why I asked question 1.
I know, just don't get mad at me if I point out now that you have a wonderful set of proposals from Dion in the message above. I repeat, it would be great if these two amazing projects could collaborate together!
@Moult thank you for your ideas! They look great, especially those that allow sharing of efforts / code and APIs to ensure that what we do is as compatible as possible with IOS / BBIM and vice versa.
Right now we're up to our necks in work. As you can imagine, building a company is not easy, and we're working around the clock from Monday to Sunday to make sure we get it off the ground. Right now it is going to be very difficult for us to dedicate time to these tasks. What do you say we wait a few months until we stabilise, and when we are sure that the ship is stable and sailing we revisit this thread?
It would be exciting to see open, honest and active collaboration between these two projects.
@agviegas cheers, more than happy to wait a few months. In the meantime, would you be OK / is there a section in the ThatOpenCompany's social media where it would be appropriate to share non IFCJS technology?
@Moult thanks, cheers! As it is now, it will still be possible to talk about and recommend open-source technologies other than IFC.js in the chat rooms (for example, when Xeokit or IOS is recommended as an alternative to IFC.js). We think it doesn't make much sense to have a specific channel for other open-source technologies when OSArch is fulfilling that mission much better than we could. In fact, wouldn't this be a good opportunity to foster people from our community with those interests to post on OSArch?
For my part, I'm going to share the posts I see on Linkedin about other technologies to give them as much diffusion as possible!
@agviegas that's great! Can I clarify which rooms you're referring to? For example my post was deleted from the "Share your wins" section, but is the "Share a resource" OK? Or only the "Ask the Community"?
I appreciate the efforts to clarify their position with regard to acceptable post material. With my poor memory, I will probably forget in 2 months and get my posts deleted.... after 10 or so future deleted posts my muscle memory should kick in and I will post in the correct room.
Everything should be clear in the guidelines! Otherwise, you are also free to propose improvements in Help us do better. The goal of our community is to have a space mainly dedicated to the open-source technology we have worked (and are working) so hard for. In general terms, if the post/comment has anything to do with IFC.js, it's ok
(even if it's "hey, have you tried Xeokit / IOS to do this thing you are trying to do with IFC.js?").
I'll do my best to redirect the people interested in other topics here.