I first got involved in Freenet when it was 0.2. At the time it was using cutting edge technologies and an contributing was an opportunity to learn valuable skills. Contributing was fun and that was the driving factor.
If Freenet was to start fresh, it should do whatever it takes to regain the coolness factor. That means embracing new tools and technologies even if there is no strict technological advantage in doing so. For better or worse Java will never be hip with the open-source crowd, and personally, after 10 hours of looking at Java code for my day job the last thing I want is to look at more Java code in my free time. Some exotic new language like Scala or Go or whatever the $COOL_LANGUAGE_DU_JOUR is would be a different story. Yes this can lead to fragmentation as various contributors veer off each into their own direction; it's the job of the leader to keep things coherent and aligned with the project vision. It's very easy to underestimate how difficult the job of the leader is. Lastly, I'd like to point out that mobile is the future - not that I like that a single bit. zab/topiltzin On Thu, Oct 15, 2015 at 7:48 PM, Dan Roberts <ademan...@gmail.com> wrote: > Hi Everyone, > Regarding fundraising, perhaps it's time to reconsider Patreon, > Gratipay, and/or Bountysource? Personally, I think Patreon may be > promising. Afaict it has the largest volume of funding. Somehow the public > has found money to support lots of silly entertainment projects on a > recurring basis (not to denigrate those projects). With the right pitch, by > appealing to privacy concerns and freedom of expression, I think Freenet > has a chance of capturing funding through that platform. Funding software > seems to be a difficult proposition to users in general, but it can be > done. > > I doubt these would be sufficient to pay for development but they could > keep the lights on. Obviously these suggestions are just suggestions, but > from my quick perusal of the archives, it didn't look like Patreon or > Gratipay have received serious consideration, and bountysource appeared to > be more or less ruled out (but bountysource has changed enough to warrant > reconsideration too?). > > If there's interest in any of these options, but lack of time, perhaps I > could contribute in that capacity by writing first passes of the requisite > campaigns, since I doubt I'll be up-to-speed on the code base any time > soon. > > Cheers, > Dan > > On Thu, Oct 15, 2015 at 8:41 AM, Matthew Toseland <mj...@cam.ac.uk> wrote: > > > On 15/10/15 00:53, Hunter Poe wrote: > > > Hi, there > > > > > > > > > > > > I have been a user of Freenet for several years now, and am at this > > point > > > still a pretty junior develop, but finally feel my capabilities have > > > advanced to the point where I would feel comfortable starting to do > some > > > work with Freenet and contributing my, albeit limited, skills. > > > > > > As consequence of this I have been following the mailing list a little > > > more closely the past week or two and it seems to me that one of the > big > > > issues is as Ian pointed out Freenet is rather aged, and so are many of > > the > > > development methodologies, tools, and libraries, and it appears in > > > consequence of that, as well as several other hurdles, have made it > > > difficult for developers to join in the work. > > > > > > This has resulted in a state where as Ian stated, we are basically > > running > > > in maintenance mode with a backlog of bugs, and trying to keep things > > > mostly working. Which at least in my limited experience is often one of > > the > > > less exciting tasks in a developers life. In addition because Freenet > has > > > been able to stand so long on its own (15 years is quite the lifetime > for > > > an application) but has resulted in numerous patches, and as Brookes > > points > > > out in the “Mythical Man Month” that when we fix a bug we end up just > > > introducing more bugs that are subtler. > > > > > > It seems to me that the best way to revitalize Freenet would be to > > > re-architect and rebuild Freenet, starting with documenting how Freenet > > is > > > actually working according to the code. I have found in my rather > limited > > > experience that often times when I am forced to verbalize or articulate > > > what my code is doing can sometimes bring epiphanies that help me make > > > major breakthroughs (source: > > > http://story.fund/post/114720918282/debugging-teddy-bea > > > <http://story.fund/post/114720918282/debugging-teddy-bear>r). The > > Freenet > > > 2.0 as it were could include a modernized build system, if we are > > concerned > > > about pulling down insecure dependencies we could look at creating our > > own > > > Freenet specific libraries that although this would cause us to > reinvent > > > the wheel in some cases it could also help us reevaluate the need for > the > > > specific component reducing software bloat, and give us the guarantee > of > > > security. We could also move to a more compartmentalized and separated > > > model for Freenet, separating the deamon, and clients, changing the way > > we > > > handle plugins. As well as standardizing testing and development > > > procedures. > > > > > > An expanded and more concise documentation and a modernization of > build > > > tools could lower the bar for entry for new developers which would in > > turn > > > cascade into more devs contributing. > > > > > > Ultimately we may need to make sacrifices in philosophical purity, > and > > > some compromises on how we want to handle certain aspects of our > > > development or methodology in order to ensure the continued survival of > > > Freenet, because regardless of how secure Freenet is, or how well the > > > source code has been vetted, or how much we trust the repositories we > are > > > pulling from. If no one is running it because it has become to kludgy > or > > > unwieldy to use or run, we are failing at our fundamental mission of > > > providing secure, anonymous, censorship resistant communication. > > > > > > > > > Like I said I am still a fairly inexperienced and junior developer and > > > could be quite off base, but these are just my thoughts. I think the > > other > > > option we could do is just send the entire code base and administration > > and > > > everything else over to the NSA and the FBI and ask them to start > > > maintaining them, I’m sure they would totally dig that. ;) > > > > > > > > > Sincerely, > > > > > > A concerned citizen opposed to a surveillance state. > > It is perfectly possible to resolve problems without rewriting from > > scratch. Sometimes we need to rewrite a subsystem. Documentation does > > not automatically come with a new design, and many problems can be > > solved by incremental refactoring. > > > > One big problem at the moment is lack of review capacity: Rewrite a > > whole subsystem and it may take a year to get merged because the release > > manager doesn't have time to review it. This happened with my rewrite of > > the client layer last year. This is an area where paid staff could be > > really helpful (although obviously that shouldn't be their sole role). > > > > As for the rest, IMHO a lot of it is simply because Freenet is an open > > source project, which hasn't reached the critical mass - and in fact > > never will - that Linux, Apache, Bitcoin, LibreOffice and Firefox have > > reached. In most of these cases there are major corporations > > contributing full-time developers. That will never be the case for > > Freenet. As for the rest, the internet hype and fundraising machine > > (Kickstarter, the wider dot com bubble, and the press) is largely around > > start-ups - profitable businesses. Doing something as a non-profit means > > we need to be good at fund-raising - either on the micro- level, or on > > the funding application level. > > > > > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl