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.
The idea that a nonprofit can compete with a commercial company sounds strange to me. They are about different things. It feels to me like saying that doctors without borders can compete with private health clinics, or that a food bank can compete with a restaurant.
Nonprofit Linux distributions also use kernel code that commercial Linux distributors write, but I didn’t hear mentions of problems with gratis binaries in this context.
To me it would feel wrong to base an open source business model on what I would call artificial scarcity.
Did anyone assume TDF would be the major source of funding for Collabora?
Probably the budget from some years ago that had 800.000 € in tenders that were likely to be awarded to very few companies created some confusion…
I would love to see TDF working with schools and universities on LibreOffice Online. Just like the desktop version, they could be on the consumer/user end, as well as on the contributor end.
The same for other nonprofits. Imagine we had an international organization, e.g. from the area of crisis management, doing something good for society and mankind, which uses LibreOffice Online and contributes to it. That would be a service to society, and a fantastic story to tell.
It’s true that the community, or different parts thereof, has been asking for funding developers. But we are an organization which runs within a budget. Our current state of “glut” of reserves masks that a little, but employment is a many-year affair, both for us in terms of community expectation and reliance, and also for the people who get employed. I’ve been on the executive board of one (and a half) NGOs with a relatively tight budget plus a few employees, and I remember that increasing permanent staffing (as opposed to a limited-term project) is a major decision; and it is never considered or discussed without the “prospective annual budget without” and “prospective annual budget with”. In our case, I remember that our annual income is not dramatically different now than it was, say, last year or a few years back; and - we have hired @jclark and @michaelweghorn recently (focusing on RTL/CTL/CJK and accessibility respectively). Additional hires can only come by reducing other expenditure, and the main “soft” expenditure we have is our budget for contracting work out (so far, via tenders) and funding various projects. So it’s not just the question of whether it’s a good idea to spend money on hiring developers, but whether it’s sufficiently beneficial as to take away the budget we currently use differently.
Some believe, that because we’ve had trouble with tendering and because of the Collabora/Allotropis purchase or merger, we can’t contract work out. That is certainly not the case; but those who believe it to be true see our budget as having a huge “increase reserves” item, which they may want to get rid of, as a foundation is expected to spend its donations, not hoard them. And this is how I see the large slate of developer positions being proposed.
We do know you were pleased that your member of staff, contractor and business partner present in the board discarded the previous finished proposal to replace it with one that illegitimately limited what developers could do to satisfy your desires.
Maybe @EyalRozenberg is not considering that other funding mechanisms are available for projects that will support the long term viability of the investment on new developers?
Your company, your subsidiary and one of your former contractors have benefited from these funding, eg:
It is very odd to see that while trying to block TDF from contributing and promoting LibreOffice OnLine, which allowed you to promote your own brand, you used in 2023 the LibreOffice OnLine logo to get funding for Collabora Online.
You killed LibreOffice Online in 2020 without warning while the board and the marketing team was still working on the marketing plan you wanted in exchange of allowing the community to have a usable LibreOffice Online so why did you decide to benefit from that logo to get funds in 2023?
Anyway, that was just an example of some funding mechanisms that could add to the funds available also to TDF to move forward with features, improvements and multi-platform developments.
Politics is something that has been introduced in the board by yourself, your business partner and contractor so if you plan to stop that also in public discussions then it would be great.
You made your point several times and all the times it seems like you do not recognise how problematic it is for you to state that TDF, a non for profit foundation under German laws, should limit its mission and goals so that they do not interfere with what you see as your own interests.
Finally we have a board where the politics and the toxic environment brought in by former directors is not present anymore. It would be great if we could keep it that way so that other organisations can see that there is a level playing field for everyone to contribute with business models that do not violate laws and regulations.
But if you’re looking for feedback from the French community: we’re very skeptical about TDF’s ability to manage duplicate projects with reasonable success with 4 developers . Collabora has a development lead of many years, with many developers; is it realistic to compete with it?
Many believe it’s too late to reactivate Lool in 2025.
We want fewer bugs and mature features in existing products, not a duplicate project that will remain in beta forever. Collabora is free software and won’t disappear next month; there will always be time to develop our version if the licensing model doesn’t evolve ethically as TDF expects.
The environnement of Collabora is almost important, could you manage interaction with docker, kubernetes or other clusters, wopi integration ? You probably need a dedicated specialist to achieve that.
We are interested by these general enhancements :
Especially everything related to data insertion (JSON and RSS processing, calls to external OpenData APIs, pivot tables)
Integration with remote services (Nextcloud and others, AI is a plus)
Help pages that help you (significant progress, however)
Translated documentation (handled mainly by communities ?)
Tests on key features; it’s unacceptable to see versions with broken mail merge.
Easier contribution, UNO API documentation, IDL
Documented configuration files
Special attention to display, speed of processing large documents and tables without crashes during copy and paste.
A mobile app with a little more functionality; some people work on tablets.
Knowledge sharing with local communities .
Some templates and other file goodies.
OOxml enhanced compatibility
A roadmap !
(and I want to be able to replace line breaks with end of lines, sorry M Kagansky)
Also the LibreOffice P2P projects could be an interesting third way .