It is useful to remind that early 2022 a new director suggested TDF to distribute full LibreOffice Online for free.
Which is exactly in line with TDF‘s mission, goal and objectives. As a director, one needs to first and foremost have TDF‘s interest in mind, which this new director obviously did.
There’s a few tools like Teable, Baserow, and Mathesar that take up this mantle but through web browsers. DBeaver on Linux also comes to mind, as does Kexi and DBGate (probably the most advanced in development).
I’m not against developing Base further, but just keep in mind there are lots of accessible FOSS solutions that are streets ahead of Base now.
I am curious how quickly one could improve Libreoffice code by loading it into an LLM and using Vibe-coding to improve the software. This will minimize onboarding time in the future and make it easier to replace the clearly self-interested and bitter Allotropia and Collabora for building business models that try to exploit and gatekeep a public good. I remember when Thb and Cors were on the board and they could barely contain their biases for their corporate interests. At least I respect Meeks’ transparency and intent for mutual benefit.
Just remember there’s always developers from emerging markets that will work double time for a fraction of the price and if you give them proper knowledge transfer (AI can help) then the output code ain’t half bad.
it’s quite hard to say how much potential Base has - simply because it’s been so far behind the other applications in the LibreOffice suite, for such a long time. So the argument that Base is ~unused, therefore any investment is useless - is circular IMO.
Those community members working with Base are IMO best placed to assess its potential:
and
Also assuming that usually, a TDF-funded developer would be able to spend a significant fraction of their time mentoring, and taking into account the existing volunteer Base developers in the project - this proposal appears to have a decent chance to kickstart & sustain a Base modernisation initiative.
It just means that we don’t do tendering, but engage in a different process, appropriate for the situation of a single service provider. The legal controls and the procedure might be different, but in itself, that is not a problem.
Of course, that is ignoring the bad blood and outstanding claims on both sides with Collabora & Allotropia, which are still not resolved.
It just means that we don’t do tendering, but engage in a different process, appropriate for the situation of a single service provider. The legal controls and the procedure might be different, but in itself, that is not a problem.
I seriously doubt awarding contracts to always the same company is compatible with the rules we are subject to, nor desirable - even if there was no past history.
We are a nonprofit foundation, not a business club.
It has been explained more than once that your reading of TDF’s mission is not the only one and especially not the one from the meaning of the German wording, that learns that ‘free’ is as in freedom, not free as in without payment.
Your words further more seem to suggest that you do not understand TDF’s mission to unite all stakeholders in a balanced way.
It is interesting to look the outcomes of the facilitated meetings we had in Bucharest. Do read what it says about Rebuilding trust and Charitable purposes/objectives.
(Give the situation still looks quite wrecked, one wonders how it could happen that some audit concluded that spending to work on improving the internal situation, should be considered as being not in TDF’s interest.)
Why do you seriously doubt that? This is an objective constraint. And many organizations face it.
As for it being undesirable - the undesirable part is not the contracting with Collabora/Allotropia (as you are implying), it is the fact there are usually no other organizations or freelancers with which we can contract. Perhaps we should focus more resources on making LO development more accessible and easier to become experienced with, so as to facilitate the ability of others to participate in tenders. We should not cancel the budget for contracting work to be done outside the TDF.
Why do you seriously doubt that? This is an objective constraint. And
many organizations face it.
Do you have an example/reference for a nonprofit in Europe, if not
Germany, that repeatedly and for non-trivial sums over a long period of
time contracts or tenders always with the same company and has no
problems with that? I’d love to hear about it.
As for it being undesirable - the undesirable part is not the
contracting with Collabora/Allotropia (as you are implying), it is the
fact there are usually no other organizations or freelancers with which
we can contract. Perhaps we should focus more resources on making LO
development more accessible and easier to become experienced with, so as
to facilitate the ability of others to participate in tenders. We should
not cancel the budget for contracting work to be done outside the TDF.
The goal of hiring developers is to retain competence inhouse and mentor
others, so it is one element indeed of facilitating the ability of
others to participate.
You can’t ask me that question. The onus is fully on you (= the BoD and you personally) to establish that this is in any way forbidden.
Suppose I live an isolated village and there’s a single grocery store there; you’re basically saying that the village cultural foundation can’t get short-order grocery deliveries from it since it’s effectively a single supplier. That’s not the way things work and I challenge you to show otherwise.
You can’t ask me that question. The onus is fully on you (= the BoD and you personally) to establish that this is in any way forbidden.
So you make the remarkable claim what the board plans is punishing a company, and then you tell me you have no insight into the legal details actually.
Suppose I live an isolated village and there’s a
We are not an isolated village. We are an internationally active nonprofit.
But I think this discussion becomes somewhat moot now.
@SolarDesalination I appreciate the DB managers you mentioned, some of which I was already vaguely aware, but none of which are truly equivalent local & remote GUI alternatives to Base. Kexi comes close, but isn’t fully cross platform & has other limitations. Every search for a FOSS MSAccess alternative seems to come up empty.
The LLM idea is interesting, but consider this meme:
Local and remote; agree it’s a unique feature of Base.
And to your pic. Yes I agree that AI hasn’t replaced human ingenuity and critical thinking. But it’s not about getting AI to fix all the problems at once. I see it as the same concept as a data scienctist working at an organization with a data catalogue vs. without. Without, the data scientist takes months to understand the data and its context, with a data catalogue, they can search for the field and find it well defined and its lineage.
Asking AI about specific aspects of TDF code while programming speeds up the ability to see where potential regressions can occur, leverage previous work to implement similar features, and optimize specific functions or libraries. It should be used to augment developers not try to replace them. And I do think it will speed up development for those who know how to use the tech properly.
@EyalRozenberg@floeff
I don’t have a lot of experience to strongly comment on what should be prioritized. However, as someone who isn’t deeply involved, here’s what I think Base should be:
Stability: This is the most important quality for any good database management system.
Reliable Built-in Database: It should have one dependable local database (like Firebird or SQLite) and strong connections for MySQL, MariaDB, and PostgreSQL, both locally and remotely.
SQL Standards: Base should follow SQL standards closely, ensuring that relationships and constraints are consistently supported in both the graphical user interface (GUI) and command line interface (CLI).
User-Friendly Tools: The tools, especially forms and reports, should be easy to use. It should be simple to convert a local database prototype into a larger remote database using the same forms. Eventually, it would be great if these forms could be exported to HTML, which could help web designers create web forms.
Consistent and Intuitive Interface: The interface should be easy to understand and use. Common tasks should be straightforward.
Specific Suggestions:
Fixing Bugs: Yes, definitely! A database management system must be stable, predictable, and user-friendly. Beyond just fixing known bugs, it might be time for experienced software designers to review the code and improve it to prevent future issues and make it simpler to use.
Switching from Java to C++: Yes! Or maybe consider using Rust to attract more developers, improve stability, and bring fresh ideas to the code.
Migrating from HSQLDB to Firebird: While moving away from Java is good, we need to be careful. If we drop support for HSQLDB, we might lose many users who have been using it for years. It’s important to ensure that users can still import and export their existing HSQLDB databases. Keeping backward compatibility is crucial for user satisfaction.
SQLite Support: This is nice, but it would be better to choose between Firebird and SQLite first. Focus on making one local database perfect before adding more features. Also, ensure compatibility with MySQL, MariaDB, and PostgreSQL connectors.
In an ideal world, Base would select one local database to develop and also have a way to easily convert forms into a full GUI manager for external databases like MariaDB. Eventually, it could even allow forms to be converted into a simple PHP-based web interface.
@Tigerdev : I am convinced enough by answers to my question about the merit of a programmer working on Base. But - I am still worried about the apparent general direction of killing the contract-work budget by hiring 5-6 developers in permanent positions.
I do not understand this and the following posts. The community is asking for TDF devs since basically a decade and working in special areas and resolving long time issues. Now, finally, the foundation got the OK by some layers and having the will to do it.
Outsourcing is always including other time consuming tasks. And a tender might not even faster nor cheaper.
It’s not like hiring and managing developers is some kind of final frontier where no non-profit has gone before. That was a bad argument to begin with and has since been demonstrated as false by TDF successfully hiring and managing developers.
Is an excellent one for TDF to address inside its education mission. I was rather disappointed to not see the funding of quality structural and developer documentation for the LibreOffice code included in the budget. That would seem something transparently educational, and extremely valuable for getting new developers started in our community. I commend it once again as an approach to the board, an idea that can accelerate development without dividing us.
There are some (inexplicable) concerns aired around the place about how hard it is to find and contract software development consultants for TDF: that seems beyond overblown - the world is full of them. However good technical / design manuals for the code would help make all new developers volunteer or paid more effective.
I am following La Suite with interest of course. There are a large number of etherpad successors with varying UX polish in the world. Docs was initially described as “the collaborative note-taking solution that lets you focus on your content”. Grist seems to be more of an airtable-like database visualization as a spreadsheet. I’m fairly convinced that they are not targetting becoming full-featured, interoperable office productivity tools anytime soon: instead they focus on different market segments.
With the benefit of a decade+ of experience selling FLOSS subscriptions, it is hard for me to imagine how that could be so. Currently Collabora uses a model similar to say Nextcloud - whereby the brand for the community project: CODE is the same as the paid product COOL - and we up-sell subscriptions. I would commend Bob Young (a RedHat founder)'s quote in our FAQ from when the COOL developers moved here: FAQ | Collabora Online - Community Page
In a model where the community version is presented as free of price, with a different brand, and with no effective way to understand that people investing the Euro millions to make it great are not in fact those who own the shiny brand - this seems to me extremely likely to cause the economic harms I have predicted. Doing that would exploit a core weakness of FLOSS vs. proprietary software that people who can build the binaries are assumed to be the creators and maintainers.
With respect I stand by my assertion that a plan to bring to market a LibreOffice branded Online would be excessively risky for the economics of half of the code contributions to LibreOffice. From the replies here - that seems to be the plan, and without any mitigations this will inevitably threaten our ability to fund LibreOffice developers.
Thanks Dennis. I agree, and I support hiring developers on specific tasks. I was pleased that the previous board finally managed to vote through Jonathan and Michael Weghorn’s positions. They have been doing great work. Hiring smart-people to work for TDF on specific things seems like a good idea in principle and practice as I’ve said many times.
They should however work on things that are not already being done, and not funded elsewhere. First for reasons of prudent use of donor funds, and secondly to avoid the appearance of divisive competition that can destroy value for TDF (as discussed elsewhere in the thread). As said many times before I believe new staff should also strengthen TDF’s charitable, educational mission by curating easy-hacks, mentoring newbies, and encouraging the growth of the volunteer base around LibreOffice in their specific area, which also acts as a force multiplier.
We know what things are not being worked on already: the Mac port, Base, and no doubt many other areas (eg. writing deeply technical code & structural documentation as a force-multiplier).
Eyal is spot on re: sustainability concerns. If TDF chooses to hire more staff than it can sustainably fund, it should be transparent with applicants that these are not permanent positions. Then again TDF has an extreme level of financial reserves which helps here I think.
Beyond the common-sense bits - I also want to kill the idea that TDF is, or has been a major source of funding for Collabora; it has not. Going forward Collabora wants to continue building a business that contributes to LibreOffice and COOL, but has minimal dependency on the complicated, troubling and changeable volunteer politics of TDF.
I think you’re again comparing pears and apples. Your selling a product and your developers are paid also out of that. That you reversed the development to TDF doesn’t make your developments for free, they already have been paid by your clients.
Also, I wonder what is the value you estimate from what you take from the community? say for example what is the value of the 54178 strings we translate in the UI vs 1499 for CODE. Or the 57256 strings of documentation vs 0 for CODE. It’s just a small example, not speaking about the rest of what the community offers.
As long as you will consider TDF and the majority of its community as a concurrent, you will not be able to see the value it can bring to your brand. Because you always seem to consider what you bring but not what you take.
And I’m not fighting for a online version as I have already said, but the way you position yourself in front of TDF is a dividing one and I don’t find it safe neither for the ecosystem nor for TDF.