I do not disagree, Raphael. However I believe in making one step after another. First step is building up a core community. (Maybe it is there I just to blind to see it) If we have that we found a community organisation And stabilized our current situation, we can make the next step. We should stick to the idea we discussed at FOSDEM. For me it is important that we have some devs and some people from user base. That it is purely community focused, without any commerce involvement.
After we have that up and running we can check for a seperate commercial partner / unit. In this step I would heavily involve the Apache Foundation because they have great experience in dealing with business contracts. I have not come by to grade a charta that our community organisation needs. :( Maybe we can do that together? Am 21. Mai 2017 11:33:08 MESZ schrieb Raphael Bircher <rbircherapa...@gmail.com>: >Hi Peter > >Am .05.2017, 08:34 Uhr, schrieb Peter Kovacs <peter.kov...@posteo.de>: > >> There are enough offices around. >We have enough office suites who run all into the same direction, yes. >But >I think there is room for much more different office solution. Spend >some >time and read the feature request on Bugzilla. You will soon realize >that >many feature request bite each other. You can do one or the other, but >not >both. Office suites to day are nasty compromises. If you have specific > >versions for specific user groups, you could solve so many problems. > >> There is no point in starting from the scratch without any plan or >> vision. >I think, I have arguments for this. >> >> Imho looking for Companies & Investors is the route Libre is moving. >> I don't think doing the same is smart. >> I would rather prefer the opposite direction and focus on community >> building. >And you want to do this only with volunteers? I say forget it. If AOO >runs >well, we have about 80 mails on the dev Mailing list per day. A pure >Volunteer simply can't keep up with this load and still develop. An >other >problem is that you will get volunteers. But as soon they doing great >work, they receive a Job offer from companies, and you will never see >them >again. No we need the companies. This is part of community building. We > >can maybe hold this version with non professional, but not improve it. > >Believe me we tryed it many times in the past. The native port of Mac >OS X >was the last real non company driven bigger improvement in OOo. And it > >would not be there, if not SUN jumped in with two devs to finish it. > >> And that is something we can do without any programmer skills. >> We can claim that we are not bound today to anyone. The structure of > >> Apache makes sure of that, I think this is something we differ a lot > >> from TDF and we should utilize. >> Also I think we should try to do a bit of old school Open Source. No > >> market focus for devs, rather go for the tech thingy. >> I think we have to much competition on our minds. >> >> We have something that is a challenge to master. Especially our bugs. >> I think there are developers out there that are fed up with the way >open >> source works today. >> Had a colleague talked on Friday, who told me exactly that. I stay >with >> him in touch now. Who knows maybe he joins someday. (No promises) >> >> I think if you take a look at today's capability of c++ it is an >awesome >> language. >> Our problem is not the language but we use different ones. >> I am personally impressed by other languages too. >> But the more different languages I use the more I am convinced that >the >> language used does not matter. The concept, architecture and tooling > >> does. >> We need more helpers that simplify work, development wise. >> I also suggest to not trying to fix one bug, but by solving a bug and > >> uplift our code. >> >> All the best >> Peter >> >> >> Am 21. Mai 2017 05:48:00 MESZ schrieb Patricia Shanahan ><p...@acm.org>: >>> On 5/20/2017 2:11 PM, Dave Fisher wrote: >>> ... >>>> We have way too many users to abandon the 4.x branch completely. We >>>> do need to handle security issues. >>>> >>>> If we want start a rewrite for a 5.x then we will need to map the >>>> functionality particularly in Calc. We will also need to pick a >more >>>> modern language compared to C++. We now have an XML schema which >can >>>> help us generate code. We did this for Java in Apache POI. The ODF >>>> Toolkit is also still in the Incubator and it could be of use. >>>> >>>> I think we should all think about it a little and then have a >series >>>> of video conferences reporting back to the community with a >synopsis >>>> step by step. >>> >>> I can see a case for creating a new project to build a modern office >>> suite from scratch, if there are enough interested people to make it >>> viable. >>> >>> I strongly disagree with calling it "OpenOffice" or assigning it an >>> OpenOffice version number, for the following reasons: >>> >>> 1. Doing so would create an expectation of compatibility that would >>> limit the options for the new suite. >>> >>> 2. Depending on how quickly the new suite is developed, and, after >>> release, its download rate relative to OpenOffice, we may want to >>> produce an actual OpenOffice 5.x. Using "OpenOffice 5.x" for the new >>> suite would limit the actual OpenOffice to 4.y, no matter how large >y >>> gets, or how long demand for OpenOffice continues. >>> >>> 3. If you look at what I wrote above, using "OpenOffice" for the new >>> suite makes it very difficult to write clearly about the differences >>> between it and the current OpenOffice line. >>> >>> I suggest that the people interested in writing new office suite >should >>> pick a project name and either create an incubator podling or, if >there >>> are enough members involved, create a new top level project. >>> >>> >--------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
